<article>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#article10_03_13_1611248</id>
	<title>Toyota Acceleration and Embedded System Bugs</title>
	<author>Soulskill</author>
	<datestamp>1268501040000</datestamp>
	<htmltext>An anonymous reader writes <i>"David Cummings, a programmer who worked on the <a href="http://en.wikipedia.org/wiki/Mars\_Pathfinder">Mars Pathfinder</a> project, has written an interesting editorial in the L.A. Times encouraging Toyota to <a href="http://www.latimes.com/news/opinion/opinionla/la-oew-cummings12-2010mar12,0,2595172.story">drop claims of software infallibility</a> in their recent acceleration problems.  He argues that embedded systems developers must program more defensively, and that companies should stop relying on software for safety. Quoting: 'If Toyota has indeed tested its software as thoroughly as it says without finding any bugs, my response is simple: Keep trying. Find new ways to instrument the software, and come up with more creative tests. The odds are that there are still bugs in the code, which may or may not be related to unintended acceleration. Until these bugs are identified, how can you be certain they are not related to sudden acceleration?'"</i></htmltext>
<tokenext>An anonymous reader writes " David Cummings , a programmer who worked on the Mars Pathfinder project , has written an interesting editorial in the L.A. Times encouraging Toyota to drop claims of software infallibility in their recent acceleration problems .
He argues that embedded systems developers must program more defensively , and that companies should stop relying on software for safety .
Quoting : 'If Toyota has indeed tested its software as thoroughly as it says without finding any bugs , my response is simple : Keep trying .
Find new ways to instrument the software , and come up with more creative tests .
The odds are that there are still bugs in the code , which may or may not be related to unintended acceleration .
Until these bugs are identified , how can you be certain they are not related to sudden acceleration ?
' "</tokentext>
<sentencetext>An anonymous reader writes "David Cummings, a programmer who worked on the Mars Pathfinder project, has written an interesting editorial in the L.A. Times encouraging Toyota to drop claims of software infallibility in their recent acceleration problems.
He argues that embedded systems developers must program more defensively, and that companies should stop relying on software for safety.
Quoting: 'If Toyota has indeed tested its software as thoroughly as it says without finding any bugs, my response is simple: Keep trying.
Find new ways to instrument the software, and come up with more creative tests.
The odds are that there are still bugs in the code, which may or may not be related to unintended acceleration.
Until these bugs are identified, how can you be certain they are not related to sudden acceleration?
'"</sentencetext>
</article>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470406</id>
	<title>Re:Logic of Testing</title>
	<author>BroncoInCalifornia</author>
	<datestamp>1268596920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>"If our testing does not find any bugs, then our software doesn't have any bugs."<br> <br>
I am trying to reconstruct what is going on at Toyota. <br> <br>
Toyota management is telling the world what is in the above quoted sentence.  There is a good chance they believe what they are saying.  <br> <br>
Are they hearing this from engineering.  If so they are hearing it from the incompetent engineers.  Are these engineers merely courtiers? Are they just telling management what they want to hear.  Is management not listening to the engineers who have a clue?<br> <br>
Inquiring minds want to know.</htmltext>
<tokenext>" If our testing does not find any bugs , then our software does n't have any bugs .
" I am trying to reconstruct what is going on at Toyota .
Toyota management is telling the world what is in the above quoted sentence .
There is a good chance they believe what they are saying .
Are they hearing this from engineering .
If so they are hearing it from the incompetent engineers .
Are these engineers merely courtiers ?
Are they just telling management what they want to hear .
Is management not listening to the engineers who have a clue ?
Inquiring minds want to know .</tokentext>
<sentencetext>"If our testing does not find any bugs, then our software doesn't have any bugs.
" 
I am trying to reconstruct what is going on at Toyota.
Toyota management is telling the world what is in the above quoted sentence.
There is a good chance they believe what they are saying.
Are they hearing this from engineering.
If so they are hearing it from the incompetent engineers.
Are these engineers merely courtiers?
Are they just telling management what they want to hear.
Is management not listening to the engineers who have a clue?
Inquiring minds want to know.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465622</id>
	<title>PR mess</title>
	<author>cuby</author>
	<datestamp>1268510940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Despite the obvious problems with Toyota cars, one thing is shure. There is a lot of people in the US profiting and betting in the fall of the main concurrent for US disgraced auto makers. They (Toyota) are being targeted by a negative campaign.<br>
I cannot believe that only Toyota has some sort of serious problem in their cars. Greediness and bugs are not a their exclusive. The main problem consists in being one of the most advanced producers.<br>
As software complexity surges I'm afraid this problem will multiply elsewhere.</htmltext>
<tokenext>Despite the obvious problems with Toyota cars , one thing is shure .
There is a lot of people in the US profiting and betting in the fall of the main concurrent for US disgraced auto makers .
They ( Toyota ) are being targeted by a negative campaign .
I can not believe that only Toyota has some sort of serious problem in their cars .
Greediness and bugs are not a their exclusive .
The main problem consists in being one of the most advanced producers .
As software complexity surges I 'm afraid this problem will multiply elsewhere .</tokentext>
<sentencetext>Despite the obvious problems with Toyota cars, one thing is shure.
There is a lot of people in the US profiting and betting in the fall of the main concurrent for US disgraced auto makers.
They (Toyota) are being targeted by a negative campaign.
I cannot believe that only Toyota has some sort of serious problem in their cars.
Greediness and bugs are not a their exclusive.
The main problem consists in being one of the most advanced producers.
As software complexity surges I'm afraid this problem will multiply elsewhere.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465794</id>
	<title>Re:From the days of "winmodems"</title>
	<author>Anonymous</author>
	<datestamp>1268512320000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>3</modscore>
	<htmltext><blockquote><div><p>I've said time and time again, "Never replace hardware with software" because<br>something dedicated to the task will always work better, or be less failure<br>prone (more often than not).</p></div></blockquote><p>On the flip side, the USN replaced complicated and heavy hardware analog computing systems for [SSBN] missile guidance systems with software running on a digital computer, and MTBF went through the roof and maintenance man hours and MTTR through the floor.  The same thing happened when they replaced the analog torpedo fire controls with digital ones.  The same thing happened again when the hovering system controls were upgraded to digital.<br>
&nbsp; <br>Now, before you claim that is a limited set of examples, I invite you to consider the millions of incident free flight hours accumulated by fly-by-wire aircraft.  Or the replacement of DIP switches in PC's with software configuration.  Etc... Etc...</p></div>
	</htmltext>
<tokenext>I 've said time and time again , " Never replace hardware with software " becausesomething dedicated to the task will always work better , or be less failureprone ( more often than not ) .On the flip side , the USN replaced complicated and heavy hardware analog computing systems for [ SSBN ] missile guidance systems with software running on a digital computer , and MTBF went through the roof and maintenance man hours and MTTR through the floor .
The same thing happened when they replaced the analog torpedo fire controls with digital ones .
The same thing happened again when the hovering system controls were upgraded to digital .
  Now , before you claim that is a limited set of examples , I invite you to consider the millions of incident free flight hours accumulated by fly-by-wire aircraft .
Or the replacement of DIP switches in PC 's with software configuration .
Etc... Etc.. .</tokentext>
<sentencetext>I've said time and time again, "Never replace hardware with software" becausesomething dedicated to the task will always work better, or be less failureprone (more often than not).On the flip side, the USN replaced complicated and heavy hardware analog computing systems for [SSBN] missile guidance systems with software running on a digital computer, and MTBF went through the roof and maintenance man hours and MTTR through the floor.
The same thing happened when they replaced the analog torpedo fire controls with digital ones.
The same thing happened again when the hovering system controls were upgraded to digital.
  Now, before you claim that is a limited set of examples, I invite you to consider the millions of incident free flight hours accumulated by fly-by-wire aircraft.
Or the replacement of DIP switches in PC's with software configuration.
Etc... Etc...
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467750</id>
	<title>Re:Logic of Testing</title>
	<author>sjames</author>
	<datestamp>1268483160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No, Cummings is saying that either way, there's probably still bugs in your code. He says that as part of a team that went to extraordinary efforts to avoid any bugs in code (well beyond the level of effort any commercial entity ever would) and they had some anyway. Non trivial software with no bugs would be quite extraordinary and so requires extraordinary proof. Software having bugs is probably one of the safest bets in the history of gambling.</p><p>Software can exist in two states, containing a mixture of known and unknown bugs or containing only unknown bugs.</p></htmltext>
<tokenext>No , Cummings is saying that either way , there 's probably still bugs in your code .
He says that as part of a team that went to extraordinary efforts to avoid any bugs in code ( well beyond the level of effort any commercial entity ever would ) and they had some anyway .
Non trivial software with no bugs would be quite extraordinary and so requires extraordinary proof .
Software having bugs is probably one of the safest bets in the history of gambling.Software can exist in two states , containing a mixture of known and unknown bugs or containing only unknown bugs .</tokentext>
<sentencetext>No, Cummings is saying that either way, there's probably still bugs in your code.
He says that as part of a team that went to extraordinary efforts to avoid any bugs in code (well beyond the level of effort any commercial entity ever would) and they had some anyway.
Non trivial software with no bugs would be quite extraordinary and so requires extraordinary proof.
Software having bugs is probably one of the safest bets in the history of gambling.Software can exist in two states, containing a mixture of known and unknown bugs or containing only unknown bugs.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465214</id>
	<title>Re:Help me benefit from media hype</title>
	<author>simp</author>
	<datestamp>1268507640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>careful with that line of reasoning. The gear shift has no mechanical linkage to the actual gearbox. So when you shift to neutral you just send an electronic command to the gearbox computer to change to N. And the sometimes the gearbox will ignore that and NOT switch to neutral. This was originally done by design to protect the engine and gearbox under specific circumstances (full load and high rpms).</p></htmltext>
<tokenext>careful with that line of reasoning .
The gear shift has no mechanical linkage to the actual gearbox .
So when you shift to neutral you just send an electronic command to the gearbox computer to change to N. And the sometimes the gearbox will ignore that and NOT switch to neutral .
This was originally done by design to protect the engine and gearbox under specific circumstances ( full load and high rpms ) .</tokentext>
<sentencetext>careful with that line of reasoning.
The gear shift has no mechanical linkage to the actual gearbox.
So when you shift to neutral you just send an electronic command to the gearbox computer to change to N. And the sometimes the gearbox will ignore that and NOT switch to neutral.
This was originally done by design to protect the engine and gearbox under specific circumstances (full load and high rpms).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465096</id>
	<title>prove a negative?</title>
	<author>Anonymous</author>
	<datestamp>1268506920000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>Isn't this like proving God doesn't exist?</p><p>They can test and test and not get a result that said this is the bug, so they assume that it doesn't exist.</p></htmltext>
<tokenext>Is n't this like proving God does n't exist ? They can test and test and not get a result that said this is the bug , so they assume that it does n't exist .</tokentext>
<sentencetext>Isn't this like proving God doesn't exist?They can test and test and not get a result that said this is the bug, so they assume that it doesn't exist.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465088</id>
	<title>Re:Logic of Testing</title>
	<author>Anonymous</author>
	<datestamp>1268506860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Every sufficiently complex piece of software has at least one bug. Every sufficiently complex piece of software can be reduced by at least one line. It follows that every sufficiently complex piece of software can be reduced to a single line that doesn't work.</p></htmltext>
<tokenext>Every sufficiently complex piece of software has at least one bug .
Every sufficiently complex piece of software can be reduced by at least one line .
It follows that every sufficiently complex piece of software can be reduced to a single line that does n't work .</tokentext>
<sentencetext>Every sufficiently complex piece of software has at least one bug.
Every sufficiently complex piece of software can be reduced by at least one line.
It follows that every sufficiently complex piece of software can be reduced to a single line that doesn't work.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468624</id>
	<title>Re:Help me benefit from media hype</title>
	<author>Anonymous</author>
	<datestamp>1268490060000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Even with zero vacuum, it is physically possible (though clearly much more difficult) to apply full braking force. You need to really, really stand on the pedal, but there is no limiting factor other than your leg strength.</p><p>Also, there is no car that I know of that has a shift interlock that prevents the transmission from shifting into neutral under any conditions (other than the brake interlock that prevents shifting out of park, but if you're in park already you obviously don't have much to worry about). Modern cars generally use rev limiters to protect the engine from overspeed conditions, not transmission interlocks. Some may prevent you from shifting into reverse when you're at speed, but that won't affect you shifting into neutral.</p><p>Your only decent point is the pushbutton shutdown procedure, which most drivers are unfamiliar with. Some customer education would go a long way towards making this issue irrelevant, though.</p></htmltext>
<tokenext>Even with zero vacuum , it is physically possible ( though clearly much more difficult ) to apply full braking force .
You need to really , really stand on the pedal , but there is no limiting factor other than your leg strength.Also , there is no car that I know of that has a shift interlock that prevents the transmission from shifting into neutral under any conditions ( other than the brake interlock that prevents shifting out of park , but if you 're in park already you obviously do n't have much to worry about ) .
Modern cars generally use rev limiters to protect the engine from overspeed conditions , not transmission interlocks .
Some may prevent you from shifting into reverse when you 're at speed , but that wo n't affect you shifting into neutral.Your only decent point is the pushbutton shutdown procedure , which most drivers are unfamiliar with .
Some customer education would go a long way towards making this issue irrelevant , though .</tokentext>
<sentencetext>Even with zero vacuum, it is physically possible (though clearly much more difficult) to apply full braking force.
You need to really, really stand on the pedal, but there is no limiting factor other than your leg strength.Also, there is no car that I know of that has a shift interlock that prevents the transmission from shifting into neutral under any conditions (other than the brake interlock that prevents shifting out of park, but if you're in park already you obviously don't have much to worry about).
Modern cars generally use rev limiters to protect the engine from overspeed conditions, not transmission interlocks.
Some may prevent you from shifting into reverse when you're at speed, but that won't affect you shifting into neutral.Your only decent point is the pushbutton shutdown procedure, which most drivers are unfamiliar with.
Some customer education would go a long way towards making this issue irrelevant, though.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466934</id>
	<title>Open Source the damn code -- so that I can test it</title>
	<author>Btrot69</author>
	<datestamp>1268476980000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>2</modscore>
	<htmltext><p>I'm a former professional "software tester from hell" (currently unemployed) -- and I drive a 2007 Camry Hybrid.<br>Officially, my car does not have a problem -- other than the floor mats -- which are now in my trunk and were never a real problem anyways.<br>Months before all of this publicity, I complained to my dealer about what seemed like a "sticky throttle" during routine maintenance.<br>The engine continues to run fast for 3-5 seconds after letting up on the gas.<br>The dealer actually charged me for the extra inspection, but did not find a problem.</p><p>So obviously -- I have some concerns.<br>I doubt that it is a software bug.  It didn't start happening until the car was 2 years old.<br>But who knows ?<br>Some of those embedded computers have probably been running since the day the Hybrid battery pack was connected in the factory.<br>Any software running that long could have become unstable.</p><p>But without source code, I am powerless to do anything about it.<br>I have to rely on the word of Toyota's software QA people -- even though I know the current state of the art of software testing is a JOKE !</p><p>If Toyota open sourced the code -- I'd have a lot more confidence -- that with a lot more eyes on it -- the software really was OK.<br>(and if they offered a reward for finding a problem -- I'd be even more confident)</p><p>Now for a quick rant as to WHY the current state of software testing is a joke, and why I have little confidence in ANY corporate software QA.<br>I write this as a former CSTE -- the QAI's "Certified Software Test (Engineer/Expert)".<br>I also should say that I love software testing because it is the one part of software development where creativity and intuition still play significant role.<br>And -- it is one area where techniques and standards are still being developed at a significant pace.</p><p>Most software development today is 98\% boilerplate and copies of stuff somebody else did.<br>Engineers translate functional specifications into code based on established design patterns.<br>There are some basic calculations to ensure good response times and scalability.</p><p>Software testers typically create test plans from the same set of functional specs that the engineers use.<br>They simply validate that everything that is supposed to happen, happens.<br>Then they might run some performance tests -- but only if management budgeted for a test environment for suitable for performance testing.</p><p>Then they stop.</p><p>Inevitably -- bugs appear in areas that no one ever expected.<br>Those are fixed later -- and regression tests are added to the test plan.</p><p>But -- almost NO ONE EVER LOOKS FOR THOSE "UNEXPECTED" BUGS -- before software is put into production.</p><p>Why ?<br>Because engineers hate the unexpected and don't typically know how to deal with it.<br>Micro-managed companies following strict Six Sigma processes (like Toyota) don't know how to create a time and resource budget for a "hunt for the unexpected".</p><p>The QAI (Quality Assurance Institute) doesn't help either.<br>They are run by a bunch of engineers obsessed with a desire to precisely measure and quantify every aspect of software testing.<br>Their techniques are useful, and largely valid -- but if they don't know HOW to quantify something -- they IGNORE it.</p><p>Just ask any CSTE  -- "How do you test for race conditions" ?<br>There is no established technique for this, so the QAI simply IGNORES the issue.<br>There is no mention of race conditions in the CSTE's CBOK (Certified Body of Knowledge).<br>I used to work for one the the world's top software QA "gurus" and I once asked him how we test for race conditions -- the answer was --<br>"we don't, because we don't know how to do it".</p><p>Despite this -- intermittent race condition bugs account for a huge portion of real-world bugs !<br>As programmers make more use of multi-core CPUs and GPUS -- race condition bugs are getting to be more and more common.</p><p>And yet -- testing for race conditions and testing for "the unexpected" IS actually possible -- it just</p></htmltext>
<tokenext>I 'm a former professional " software tester from hell " ( currently unemployed ) -- and I drive a 2007 Camry Hybrid.Officially , my car does not have a problem -- other than the floor mats -- which are now in my trunk and were never a real problem anyways.Months before all of this publicity , I complained to my dealer about what seemed like a " sticky throttle " during routine maintenance.The engine continues to run fast for 3-5 seconds after letting up on the gas.The dealer actually charged me for the extra inspection , but did not find a problem.So obviously -- I have some concerns.I doubt that it is a software bug .
It did n't start happening until the car was 2 years old.But who knows ? Some of those embedded computers have probably been running since the day the Hybrid battery pack was connected in the factory.Any software running that long could have become unstable.But without source code , I am powerless to do anything about it.I have to rely on the word of Toyota 's software QA people -- even though I know the current state of the art of software testing is a JOKE ! If Toyota open sourced the code -- I 'd have a lot more confidence -- that with a lot more eyes on it -- the software really was OK. ( and if they offered a reward for finding a problem -- I 'd be even more confident ) Now for a quick rant as to WHY the current state of software testing is a joke , and why I have little confidence in ANY corporate software QA.I write this as a former CSTE -- the QAI 's " Certified Software Test ( Engineer/Expert ) " .I also should say that I love software testing because it is the one part of software development where creativity and intuition still play significant role.And -- it is one area where techniques and standards are still being developed at a significant pace.Most software development today is 98 \ % boilerplate and copies of stuff somebody else did.Engineers translate functional specifications into code based on established design patterns.There are some basic calculations to ensure good response times and scalability.Software testers typically create test plans from the same set of functional specs that the engineers use.They simply validate that everything that is supposed to happen , happens.Then they might run some performance tests -- but only if management budgeted for a test environment for suitable for performance testing.Then they stop.Inevitably -- bugs appear in areas that no one ever expected.Those are fixed later -- and regression tests are added to the test plan.But -- almost NO ONE EVER LOOKS FOR THOSE " UNEXPECTED " BUGS -- before software is put into production.Why ? Because engineers hate the unexpected and do n't typically know how to deal with it.Micro-managed companies following strict Six Sigma processes ( like Toyota ) do n't know how to create a time and resource budget for a " hunt for the unexpected " .The QAI ( Quality Assurance Institute ) does n't help either.They are run by a bunch of engineers obsessed with a desire to precisely measure and quantify every aspect of software testing.Their techniques are useful , and largely valid -- but if they do n't know HOW to quantify something -- they IGNORE it.Just ask any CSTE -- " How do you test for race conditions " ? There is no established technique for this , so the QAI simply IGNORES the issue.There is no mention of race conditions in the CSTE 's CBOK ( Certified Body of Knowledge ) .I used to work for one the the world 's top software QA " gurus " and I once asked him how we test for race conditions -- the answer was -- " we do n't , because we do n't know how to do it " .Despite this -- intermittent race condition bugs account for a huge portion of real-world bugs ! As programmers make more use of multi-core CPUs and GPUS -- race condition bugs are getting to be more and more common.And yet -- testing for race conditions and testing for " the unexpected " IS actually possible -- it just</tokentext>
<sentencetext>I'm a former professional "software tester from hell" (currently unemployed) -- and I drive a 2007 Camry Hybrid.Officially, my car does not have a problem -- other than the floor mats -- which are now in my trunk and were never a real problem anyways.Months before all of this publicity, I complained to my dealer about what seemed like a "sticky throttle" during routine maintenance.The engine continues to run fast for 3-5 seconds after letting up on the gas.The dealer actually charged me for the extra inspection, but did not find a problem.So obviously -- I have some concerns.I doubt that it is a software bug.
It didn't start happening until the car was 2 years old.But who knows ?Some of those embedded computers have probably been running since the day the Hybrid battery pack was connected in the factory.Any software running that long could have become unstable.But without source code, I am powerless to do anything about it.I have to rely on the word of Toyota's software QA people -- even though I know the current state of the art of software testing is a JOKE !If Toyota open sourced the code -- I'd have a lot more confidence -- that with a lot more eyes on it -- the software really was OK.(and if they offered a reward for finding a problem -- I'd be even more confident)Now for a quick rant as to WHY the current state of software testing is a joke, and why I have little confidence in ANY corporate software QA.I write this as a former CSTE -- the QAI's "Certified Software Test (Engineer/Expert)".I also should say that I love software testing because it is the one part of software development where creativity and intuition still play significant role.And -- it is one area where techniques and standards are still being developed at a significant pace.Most software development today is 98\% boilerplate and copies of stuff somebody else did.Engineers translate functional specifications into code based on established design patterns.There are some basic calculations to ensure good response times and scalability.Software testers typically create test plans from the same set of functional specs that the engineers use.They simply validate that everything that is supposed to happen, happens.Then they might run some performance tests -- but only if management budgeted for a test environment for suitable for performance testing.Then they stop.Inevitably -- bugs appear in areas that no one ever expected.Those are fixed later -- and regression tests are added to the test plan.But -- almost NO ONE EVER LOOKS FOR THOSE "UNEXPECTED" BUGS -- before software is put into production.Why ?Because engineers hate the unexpected and don't typically know how to deal with it.Micro-managed companies following strict Six Sigma processes (like Toyota) don't know how to create a time and resource budget for a "hunt for the unexpected".The QAI (Quality Assurance Institute) doesn't help either.They are run by a bunch of engineers obsessed with a desire to precisely measure and quantify every aspect of software testing.Their techniques are useful, and largely valid -- but if they don't know HOW to quantify something -- they IGNORE it.Just ask any CSTE  -- "How do you test for race conditions" ?There is no established technique for this, so the QAI simply IGNORES the issue.There is no mention of race conditions in the CSTE's CBOK (Certified Body of Knowledge).I used to work for one the the world's top software QA "gurus" and I once asked him how we test for race conditions -- the answer was --"we don't, because we don't know how to do it".Despite this -- intermittent race condition bugs account for a huge portion of real-world bugs !As programmers make more use of multi-core CPUs and GPUS -- race condition bugs are getting to be more and more common.And yet -- testing for race conditions and testing for "the unexpected" IS actually possible -- it just</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465572</id>
	<title>Re:Help me benefit from media hype</title>
	<author>sideshow</author>
	<datestamp>1268510460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In SoCal, a bunch of models have 0\% interest on 60 month loans.  I'm holding out for this deal to extend to 4Runners so hopefully this hype goes on a bit longer.</p></htmltext>
<tokenext>In SoCal , a bunch of models have 0 \ % interest on 60 month loans .
I 'm holding out for this deal to extend to 4Runners so hopefully this hype goes on a bit longer .</tokentext>
<sentencetext>In SoCal, a bunch of models have 0\% interest on 60 month loans.
I'm holding out for this deal to extend to 4Runners so hopefully this hype goes on a bit longer.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31496558</id>
	<title>Re:Toyota:</title>
	<author>Anonymous</author>
	<datestamp>1268757900000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>so software can fail. Who did not know? But hardware can fail too you know<nobr> <wbr></nobr>...</p><p>Isn't all this about getting non US cars out of the US?</p></htmltext>
<tokenext>so software can fail .
Who did not know ?
But hardware can fail too you know ...Is n't all this about getting non US cars out of the US ?</tokentext>
<sentencetext>so software can fail.
Who did not know?
But hardware can fail too you know ...Isn't all this about getting non US cars out of the US?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466048</id>
	<title>Re:Logic of Testing</title>
	<author>mc6809e</author>
	<datestamp>1268513820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>So they speculate that code they wrote had an interrupt routine that was not bracketed with PUSHF/POPF instructions!!! Which is like Assembly 101.</p></div></blockquote><p>You're not reading that correctly. They didn't have and interrupt routine. They had a simple process. The problem was that the interrupt handler <i>of the operating system</i> wasn't saving the state of the carry bit. No one should have to block interrupts just to do an addition in a process that has no shared state.</p></div>
	</htmltext>
<tokenext>So they speculate that code they wrote had an interrupt routine that was not bracketed with PUSHF/POPF instructions ! ! !
Which is like Assembly 101.You 're not reading that correctly .
They did n't have and interrupt routine .
They had a simple process .
The problem was that the interrupt handler of the operating system was n't saving the state of the carry bit .
No one should have to block interrupts just to do an addition in a process that has no shared state .</tokentext>
<sentencetext>So they speculate that code they wrote had an interrupt routine that was not bracketed with PUSHF/POPF instructions!!!
Which is like Assembly 101.You're not reading that correctly.
They didn't have and interrupt routine.
They had a simple process.
The problem was that the interrupt handler of the operating system wasn't saving the state of the carry bit.
No one should have to block interrupts just to do an addition in a process that has no shared state.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465294</id>
	<title>We need full access to the data recorders</title>
	<author>mspohr</author>
	<datestamp>1268508240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It would be a big help to everyone researching this problem if Toyota would give full access to the contents of the data recorders in their cars.  They are playing games and denying access to all of the information that is collected before a crash.  They supposedly only have one computer in the US that is capable of reading the data recorders.  They are giving accident investigators reports with many columns of data blank.  This is nonsense.<p>
If everyone had access to all of the data on their own cars, this problem could be solved much faster (... I seem to remember something that someone once said that "with many eyes all bugs are shallow"...)</p></htmltext>
<tokenext>It would be a big help to everyone researching this problem if Toyota would give full access to the contents of the data recorders in their cars .
They are playing games and denying access to all of the information that is collected before a crash .
They supposedly only have one computer in the US that is capable of reading the data recorders .
They are giving accident investigators reports with many columns of data blank .
This is nonsense .
If everyone had access to all of the data on their own cars , this problem could be solved much faster ( ... I seem to remember something that someone once said that " with many eyes all bugs are shallow " ... )</tokentext>
<sentencetext>It would be a big help to everyone researching this problem if Toyota would give full access to the contents of the data recorders in their cars.
They are playing games and denying access to all of the information that is collected before a crash.
They supposedly only have one computer in the US that is capable of reading the data recorders.
They are giving accident investigators reports with many columns of data blank.
This is nonsense.
If everyone had access to all of the data on their own cars, this problem could be solved much faster (... I seem to remember something that someone once said that "with many eyes all bugs are shallow"...)</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464976</id>
	<title>Obama's solution</title>
	<author>ebonum</author>
	<datestamp>1268506020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It seems he wants more software.  This time to check for both pedals being depressed at the same time.  One more thing to break.</p><p>The less these embedded systems have to do, the better.</p></htmltext>
<tokenext>It seems he wants more software .
This time to check for both pedals being depressed at the same time .
One more thing to break.The less these embedded systems have to do , the better .</tokentext>
<sentencetext>It seems he wants more software.
This time to check for both pedals being depressed at the same time.
One more thing to break.The less these embedded systems have to do, the better.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467610</id>
	<title>Re:Obama's solution</title>
	<author>John Hasler</author>
	<datestamp>1268482020000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It could be done with a bit of electronics involving no computers (or better yet a mechanical linkage).  Easy enough to shove in a valve forcing the engine to idle when the brake is floored regardless of what the computer is calling for.</p></htmltext>
<tokenext>It could be done with a bit of electronics involving no computers ( or better yet a mechanical linkage ) .
Easy enough to shove in a valve forcing the engine to idle when the brake is floored regardless of what the computer is calling for .</tokentext>
<sentencetext>It could be done with a bit of electronics involving no computers (or better yet a mechanical linkage).
Easy enough to shove in a valve forcing the engine to idle when the brake is floored regardless of what the computer is calling for.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464976</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465434</id>
	<title>Re:Logic of Testing</title>
	<author>mysidia</author>
	<datestamp>1268509380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
The second statement follows from a different logical proposition.
</p><p>
The proposition is: all software has bugs, you just have to look hard enough.
</p><p>
And as far as we know, it is a true proposition, and the 2nd conclusion above follows from it.
</p><p>
What's not certain is that the acceleration issues come from (those) bugs,  rather  than a defect.
</p><p>
If the code burnt to the ROM/PROMs  don't exactly match the code they developed and tested, there could still be a "software" issue in the final product.
</p><p>
An issue that can only be detected by analyzing and attempting to verify/validate actual units known to have the issue.
</p></htmltext>
<tokenext>The second statement follows from a different logical proposition .
The proposition is : all software has bugs , you just have to look hard enough .
And as far as we know , it is a true proposition , and the 2nd conclusion above follows from it .
What 's not certain is that the acceleration issues come from ( those ) bugs , rather than a defect .
If the code burnt to the ROM/PROMs do n't exactly match the code they developed and tested , there could still be a " software " issue in the final product .
An issue that can only be detected by analyzing and attempting to verify/validate actual units known to have the issue .</tokentext>
<sentencetext>
The second statement follows from a different logical proposition.
The proposition is: all software has bugs, you just have to look hard enough.
And as far as we know, it is a true proposition, and the 2nd conclusion above follows from it.
What's not certain is that the acceleration issues come from (those) bugs,  rather  than a defect.
If the code burnt to the ROM/PROMs  don't exactly match the code they developed and tested, there could still be a "software" issue in the final product.
An issue that can only be detected by analyzing and attempting to verify/validate actual units known to have the issue.
</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464916</id>
	<title>The horror scenario for Toyota</title>
	<author>Anonymous</author>
	<datestamp>1268505540000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Notice that they always emphasise that 'there is no evidence that embedded software contains flaws'. Actually, Cummings notes it as well.</p><p>Remember also the statement of president Toyoda, mentioning that focus has been on speed more than quality.</p><p>There is a theoretical possibility that software development has exceeded the bounds of where you can have total overview of the code at all times (as in military and life critical applications). For example, if you develop 50 different software components controlling each of 50 components in car 1, it is very attractive to reuse 45 of those in car 2 and only rewrite the software for the 5 components that have changed. There is no need to test a module that has worked in all your previous cars, right?</p><p>And when you plug these together at the shipping stage and discover that it works 100\% of the time (rounded up to the nearest thousand tests), you are set to go.</p><p>If the problem WAS in software, Toyota would have to either 1) invest a lot very quickly in bug testing which may or may not be successful, 2) rebuild the software from the ground up, 3) scrap all the cars. In the meantime they would have to absorb the costs of A) providing full refunds for the purchase to all customers, or B) providing rental cars to every owner of a Toyota for the months it takes to do these things.</p><p>Both of those options are unimaginably costly.</p><p>Therefore, if you so much as start going down the path that the problems COULD lie in the embedded software, it's pretty much total game over for Toyota.</p></htmltext>
<tokenext>Notice that they always emphasise that 'there is no evidence that embedded software contains flaws' .
Actually , Cummings notes it as well.Remember also the statement of president Toyoda , mentioning that focus has been on speed more than quality.There is a theoretical possibility that software development has exceeded the bounds of where you can have total overview of the code at all times ( as in military and life critical applications ) .
For example , if you develop 50 different software components controlling each of 50 components in car 1 , it is very attractive to reuse 45 of those in car 2 and only rewrite the software for the 5 components that have changed .
There is no need to test a module that has worked in all your previous cars , right ? And when you plug these together at the shipping stage and discover that it works 100 \ % of the time ( rounded up to the nearest thousand tests ) , you are set to go.If the problem WAS in software , Toyota would have to either 1 ) invest a lot very quickly in bug testing which may or may not be successful , 2 ) rebuild the software from the ground up , 3 ) scrap all the cars .
In the meantime they would have to absorb the costs of A ) providing full refunds for the purchase to all customers , or B ) providing rental cars to every owner of a Toyota for the months it takes to do these things.Both of those options are unimaginably costly.Therefore , if you so much as start going down the path that the problems COULD lie in the embedded software , it 's pretty much total game over for Toyota .</tokentext>
<sentencetext>Notice that they always emphasise that 'there is no evidence that embedded software contains flaws'.
Actually, Cummings notes it as well.Remember also the statement of president Toyoda, mentioning that focus has been on speed more than quality.There is a theoretical possibility that software development has exceeded the bounds of where you can have total overview of the code at all times (as in military and life critical applications).
For example, if you develop 50 different software components controlling each of 50 components in car 1, it is very attractive to reuse 45 of those in car 2 and only rewrite the software for the 5 components that have changed.
There is no need to test a module that has worked in all your previous cars, right?And when you plug these together at the shipping stage and discover that it works 100\% of the time (rounded up to the nearest thousand tests), you are set to go.If the problem WAS in software, Toyota would have to either 1) invest a lot very quickly in bug testing which may or may not be successful, 2) rebuild the software from the ground up, 3) scrap all the cars.
In the meantime they would have to absorb the costs of A) providing full refunds for the purchase to all customers, or B) providing rental cars to every owner of a Toyota for the months it takes to do these things.Both of those options are unimaginably costly.Therefore, if you so much as start going down the path that the problems COULD lie in the embedded software, it's pretty much total game over for Toyota.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465744</id>
	<title>Re:Logic of Testing</title>
	<author>Alanonfire</author>
	<datestamp>1268511780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The way I interpreted what he said is this.
<br> <br>
"Just because you don't see any bugs, doesn't mean there are, and in the case where human life is at stake you should assume there are bugs and attempt to find them whether they exist or not.  But don't rule out software bugs just because you don't see them or feel you've tested 'enough'."
<br> <br>
In general people think because they do something a lot, they think its enough.  Take drinking water for instance, "well, I drank a lot of water, but I'm still dehydrated."
<br> <br>
I think this is what he's alluding to.  But again I might be wrong and we may not actually exist, this could all just be a hiccup in the cosmos.</htmltext>
<tokenext>The way I interpreted what he said is this .
" Just because you do n't see any bugs , does n't mean there are , and in the case where human life is at stake you should assume there are bugs and attempt to find them whether they exist or not .
But do n't rule out software bugs just because you do n't see them or feel you 've tested 'enough' .
" In general people think because they do something a lot , they think its enough .
Take drinking water for instance , " well , I drank a lot of water , but I 'm still dehydrated .
" I think this is what he 's alluding to .
But again I might be wrong and we may not actually exist , this could all just be a hiccup in the cosmos .</tokentext>
<sentencetext>The way I interpreted what he said is this.
"Just because you don't see any bugs, doesn't mean there are, and in the case where human life is at stake you should assume there are bugs and attempt to find them whether they exist or not.
But don't rule out software bugs just because you don't see them or feel you've tested 'enough'.
"
 
In general people think because they do something a lot, they think its enough.
Take drinking water for instance, "well, I drank a lot of water, but I'm still dehydrated.
"
 
I think this is what he's alluding to.
But again I might be wrong and we may not actually exist, this could all just be a hiccup in the cosmos.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465256</id>
	<title>Re:Exactly</title>
	<author>The End Of Days</author>
	<datestamp>1268507940000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Denier! How dare you question the truth.</p><p>And off topic, at that.  You, sir, disgust me.  Our lord Al Gore will consume your soul.</p></htmltext>
<tokenext>Denier !
How dare you question the truth.And off topic , at that .
You , sir , disgust me .
Our lord Al Gore will consume your soul .</tokentext>
<sentencetext>Denier!
How dare you question the truth.And off topic, at that.
You, sir, disgust me.
Our lord Al Gore will consume your soul.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464924</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466982</id>
	<title>Re:Speaking as an embedded programmer here...</title>
	<author>Anonymous</author>
	<datestamp>1268477340000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p>Also speaking as a embedded programmer, with 18+ years work on avionics, industrial robotics, pneudralic-control systems, and the like, the SAFE assumption is to point at software.  Your points about flakey/glitchy hardware conditions are well put--they are unfortunately far too common in far too many systems (which is another rant for another time, about piss poor design)--however it is the JOB OF THE SOFTWARE to sanely and 'correctly' control those systems.  That means the \_must\_ be ARCHITECTED AND WRITTEN to handle all of those conditions, even the "impossible" corner-cases.  Period.  No exceptions, no excuses.</p><p>Please note:  I'm making a distinction between the software programmers who made TECHNICAL DESIGN DECISIONS, and the person(s) who made POLICY DESIGN DECISIONS.  From my general perusal of the news reports and statements made by Toyota in the aftermath of all of this, there are \_clearly\_ multiple problems with their POLICY DESIGN.  If someone hits the brakes, it should override the accelerator functions.  Period--no exceptions.  Audi has always done this by default, Toyota is "implementing this as an additional safety feature"... Funny how they didn't "implement" it prior to this.  But there also are likely multiple implementation issues with the TECHNICAL DESIGN of the software as well.  30 Million lines of code?  Yeah, there's going to be some garbage in there... I'll lay $50 on that.</p><p>My point?  That despite any hardware failures, hardware design flaws, and the like, software development is the last bastion of control.  (Should it be?  Maybe not--hence the decades-long argument for avoiding fly-by-wire.)  To maintain that control requires good planning, good execution, and good testing through the entire software process.  Toyota clearly failed at one of these, and likely in others.  (I'm not even going to touch on the pending lawsuit concerning internal documentation swiped by their ex-lawyer, where it is alleged they made false statements, hid evidence, etc.)  For Toyota to make absurdist statements in the press, and then act surprised, is B.S.  They deserve to go through the flames on this.</p></htmltext>
<tokenext>Also speaking as a embedded programmer , with 18 + years work on avionics , industrial robotics , pneudralic-control systems , and the like , the SAFE assumption is to point at software .
Your points about flakey/glitchy hardware conditions are well put--they are unfortunately far too common in far too many systems ( which is another rant for another time , about piss poor design ) --however it is the JOB OF THE SOFTWARE to sanely and 'correctly ' control those systems .
That means the \ _must \ _ be ARCHITECTED AND WRITTEN to handle all of those conditions , even the " impossible " corner-cases .
Period. No exceptions , no excuses.Please note : I 'm making a distinction between the software programmers who made TECHNICAL DESIGN DECISIONS , and the person ( s ) who made POLICY DESIGN DECISIONS .
From my general perusal of the news reports and statements made by Toyota in the aftermath of all of this , there are \ _clearly \ _ multiple problems with their POLICY DESIGN .
If someone hits the brakes , it should override the accelerator functions .
Period--no exceptions .
Audi has always done this by default , Toyota is " implementing this as an additional safety feature " ... Funny how they did n't " implement " it prior to this .
But there also are likely multiple implementation issues with the TECHNICAL DESIGN of the software as well .
30 Million lines of code ?
Yeah , there 's going to be some garbage in there... I 'll lay $ 50 on that.My point ?
That despite any hardware failures , hardware design flaws , and the like , software development is the last bastion of control .
( Should it be ?
Maybe not--hence the decades-long argument for avoiding fly-by-wire .
) To maintain that control requires good planning , good execution , and good testing through the entire software process .
Toyota clearly failed at one of these , and likely in others .
( I 'm not even going to touch on the pending lawsuit concerning internal documentation swiped by their ex-lawyer , where it is alleged they made false statements , hid evidence , etc .
) For Toyota to make absurdist statements in the press , and then act surprised , is B.S .
They deserve to go through the flames on this .</tokentext>
<sentencetext>Also speaking as a embedded programmer, with 18+ years work on avionics, industrial robotics, pneudralic-control systems, and the like, the SAFE assumption is to point at software.
Your points about flakey/glitchy hardware conditions are well put--they are unfortunately far too common in far too many systems (which is another rant for another time, about piss poor design)--however it is the JOB OF THE SOFTWARE to sanely and 'correctly' control those systems.
That means the \_must\_ be ARCHITECTED AND WRITTEN to handle all of those conditions, even the "impossible" corner-cases.
Period.  No exceptions, no excuses.Please note:  I'm making a distinction between the software programmers who made TECHNICAL DESIGN DECISIONS, and the person(s) who made POLICY DESIGN DECISIONS.
From my general perusal of the news reports and statements made by Toyota in the aftermath of all of this, there are \_clearly\_ multiple problems with their POLICY DESIGN.
If someone hits the brakes, it should override the accelerator functions.
Period--no exceptions.
Audi has always done this by default, Toyota is "implementing this as an additional safety feature"... Funny how they didn't "implement" it prior to this.
But there also are likely multiple implementation issues with the TECHNICAL DESIGN of the software as well.
30 Million lines of code?
Yeah, there's going to be some garbage in there... I'll lay $50 on that.My point?
That despite any hardware failures, hardware design flaws, and the like, software development is the last bastion of control.
(Should it be?
Maybe not--hence the decades-long argument for avoiding fly-by-wire.
)  To maintain that control requires good planning, good execution, and good testing through the entire software process.
Toyota clearly failed at one of these, and likely in others.
(I'm not even going to touch on the pending lawsuit concerning internal documentation swiped by their ex-lawyer, where it is alleged they made false statements, hid evidence, etc.
)  For Toyota to make absurdist statements in the press, and then act surprised, is B.S.
They deserve to go through the flames on this.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466836</id>
	<title>It is possible, and is done, but hard/expensive</title>
	<author>Anonymous</author>
	<datestamp>1268476200000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I do industrial automation for a living, and machine guarding/safety is a major component of the job.  There are now, in the last few years, software based safety products that are provably just as safe as a hardware only safety products.  The key is that it's not just about rigorous testing, it's about correct design.  If you want category 4 protection, you need to be sure that:</p><ol><li>No single component failure can leave the system in an unsafe state</li><li>The component failure is detected</li><li>The system cannot be restarted without correcting the failure</li></ol><p>Software becomes another component.  Therefore you need to have redundancy in your software.  Government regulators that certify these safety systems as compliant want to see you prove that a single component (i.e. unit of software) can't malfunction and leave the system in an unsafe state.  What a lot of companies do is they have two independent processors each monitoring the inputs to the system in parallel, and each generating the required outputs.  The processors are typically sourced from different companies, and the circuit boards are designed by different teams.  The software running on each processor is written by a different team.  If both processors agree on the outputs, the system drives those outputs, and if not, all power is dropped to everything and the system can't be restarted (may need to be replaced, etc.).</p><p>Those of us in the industry were skeptical of software based safety at first, but given the above facts and a decent amount of regulatory oversight, I'm satisfied that it will live up to the design criteria.  That doesn't mean an error can't happen, but it makes the probability low enough that we can live with it.</p><p>The latest thing is safety systems running their I/O across networks like DeviceNet and even Ethernet/IP (the IP stands for Industrial Protocol, not Internet Protocol).  Again, I was at first skeptical, but they use a protocol layering on top of the network using timestamps and redundant processors on both ends with reasonable failure modes that the system is provably safe, within reasonable limits.</p><p>So you can make safe embedded systems, but without being able to inspect the design and see that it lives up to these guidelines, Toyota can't ever *prove* that the system is safe.</p></htmltext>
<tokenext>I do industrial automation for a living , and machine guarding/safety is a major component of the job .
There are now , in the last few years , software based safety products that are provably just as safe as a hardware only safety products .
The key is that it 's not just about rigorous testing , it 's about correct design .
If you want category 4 protection , you need to be sure that : No single component failure can leave the system in an unsafe stateThe component failure is detectedThe system can not be restarted without correcting the failureSoftware becomes another component .
Therefore you need to have redundancy in your software .
Government regulators that certify these safety systems as compliant want to see you prove that a single component ( i.e .
unit of software ) ca n't malfunction and leave the system in an unsafe state .
What a lot of companies do is they have two independent processors each monitoring the inputs to the system in parallel , and each generating the required outputs .
The processors are typically sourced from different companies , and the circuit boards are designed by different teams .
The software running on each processor is written by a different team .
If both processors agree on the outputs , the system drives those outputs , and if not , all power is dropped to everything and the system ca n't be restarted ( may need to be replaced , etc .
) .Those of us in the industry were skeptical of software based safety at first , but given the above facts and a decent amount of regulatory oversight , I 'm satisfied that it will live up to the design criteria .
That does n't mean an error ca n't happen , but it makes the probability low enough that we can live with it.The latest thing is safety systems running their I/O across networks like DeviceNet and even Ethernet/IP ( the IP stands for Industrial Protocol , not Internet Protocol ) .
Again , I was at first skeptical , but they use a protocol layering on top of the network using timestamps and redundant processors on both ends with reasonable failure modes that the system is provably safe , within reasonable limits.So you can make safe embedded systems , but without being able to inspect the design and see that it lives up to these guidelines , Toyota ca n't ever * prove * that the system is safe .</tokentext>
<sentencetext>I do industrial automation for a living, and machine guarding/safety is a major component of the job.
There are now, in the last few years, software based safety products that are provably just as safe as a hardware only safety products.
The key is that it's not just about rigorous testing, it's about correct design.
If you want category 4 protection, you need to be sure that:No single component failure can leave the system in an unsafe stateThe component failure is detectedThe system cannot be restarted without correcting the failureSoftware becomes another component.
Therefore you need to have redundancy in your software.
Government regulators that certify these safety systems as compliant want to see you prove that a single component (i.e.
unit of software) can't malfunction and leave the system in an unsafe state.
What a lot of companies do is they have two independent processors each monitoring the inputs to the system in parallel, and each generating the required outputs.
The processors are typically sourced from different companies, and the circuit boards are designed by different teams.
The software running on each processor is written by a different team.
If both processors agree on the outputs, the system drives those outputs, and if not, all power is dropped to everything and the system can't be restarted (may need to be replaced, etc.
).Those of us in the industry were skeptical of software based safety at first, but given the above facts and a decent amount of regulatory oversight, I'm satisfied that it will live up to the design criteria.
That doesn't mean an error can't happen, but it makes the probability low enough that we can live with it.The latest thing is safety systems running their I/O across networks like DeviceNet and even Ethernet/IP (the IP stands for Industrial Protocol, not Internet Protocol).
Again, I was at first skeptical, but they use a protocol layering on top of the network using timestamps and redundant processors on both ends with reasonable failure modes that the system is provably safe, within reasonable limits.So you can make safe embedded systems, but without being able to inspect the design and see that it lives up to these guidelines, Toyota can't ever *prove* that the system is safe.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470664</id>
	<title>I'd bet the problem is...</title>
	<author>alewar</author>
	<datestamp>1268558760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>a race condition!</htmltext>
<tokenext>a race condition !</tokentext>
<sentencetext>a race condition!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466228</id>
	<title>Re:Help me benefit from media hype</title>
	<author>calidoscope</author>
	<datestamp>1268471640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Some of these vehicles don't have keys: just a radio remote. The emergency shutdown procedure is to hold a button down for three seconds (another design defect). </p></div><p>I would use a stronger term, it was an incredibly stupid design decision. I wouldn't be opposed to a federal regulation specifying that there is some method of shutting off an engine within one second - really easy to do with a traditional ignition switch.</p></div>
	</htmltext>
<tokenext>Some of these vehicles do n't have keys : just a radio remote .
The emergency shutdown procedure is to hold a button down for three seconds ( another design defect ) .
I would use a stronger term , it was an incredibly stupid design decision .
I would n't be opposed to a federal regulation specifying that there is some method of shutting off an engine within one second - really easy to do with a traditional ignition switch .</tokentext>
<sentencetext>Some of these vehicles don't have keys: just a radio remote.
The emergency shutdown procedure is to hold a button down for three seconds (another design defect).
I would use a stronger term, it was an incredibly stupid design decision.
I wouldn't be opposed to a federal regulation specifying that there is some method of shutting off an engine within one second - really easy to do with a traditional ignition switch.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465236</id>
	<title>Pedal was stuck physically to the floor.</title>
	<author>andydread</author>
	<datestamp>1268507820000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>If you look at the latest 2 incidents the accelerator pedal was stuck to the floor.  The one man even said he felt something funny has he pressed the pedal down to pass a car and it was stuck to the floor.  It did not return.  He said he even tried to pull it back to its original position.  So how in the world it this an electronic problem?  How does electronics cause a mechanical pedal to be stuck to the floor?  Someone? Anyone?</htmltext>
<tokenext>If you look at the latest 2 incidents the accelerator pedal was stuck to the floor .
The one man even said he felt something funny has he pressed the pedal down to pass a car and it was stuck to the floor .
It did not return .
He said he even tried to pull it back to its original position .
So how in the world it this an electronic problem ?
How does electronics cause a mechanical pedal to be stuck to the floor ?
Someone ? Anyone ?</tokentext>
<sentencetext>If you look at the latest 2 incidents the accelerator pedal was stuck to the floor.
The one man even said he felt something funny has he pressed the pedal down to pass a car and it was stuck to the floor.
It did not return.
He said he even tried to pull it back to its original position.
So how in the world it this an electronic problem?
How does electronics cause a mechanical pedal to be stuck to the floor?
Someone? Anyone?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466522</id>
	<title>experience vs. theory</title>
	<author>recharged95</author>
	<datestamp>1268473680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>You can't test enough. It buys you <i>time</i>. Test is more important than the development, especially in hard real-time systems.
<br>
<br>
Unfortunately, Toyota doesn't have time (<i>time is money</i>) as well as its priority was cash over safety, period.
<br>
<br>
It is funny that the armchair quarterbacking comes from the organization that <b>consistently</b> has bugs
concerning english to metric unit conversions.</htmltext>
<tokenext>You ca n't test enough .
It buys you time .
Test is more important than the development , especially in hard real-time systems .
Unfortunately , Toyota does n't have time ( time is money ) as well as its priority was cash over safety , period .
It is funny that the armchair quarterbacking comes from the organization that consistently has bugs concerning english to metric unit conversions .</tokentext>
<sentencetext>You can't test enough.
It buys you time.
Test is more important than the development, especially in hard real-time systems.
Unfortunately, Toyota doesn't have time (time is money) as well as its priority was cash over safety, period.
It is funny that the armchair quarterbacking comes from the organization that consistently has bugs
concerning english to metric unit conversions.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468138</id>
	<title>Re:From the days of "winmodems"</title>
	<author>Anonymous</author>
	<datestamp>1268486040000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Correct functioning of the system is required.</p><p>How many torpedo and nuclear cruise missile launches off those "upgraded" SSBNs have we had, that we may verify the correct functioning of the new computerized system?</p><p>If it was tested with "dummy" torpedoes and missiles, how closely did the dummies replicate the live ones?</p><p>Customers (in this case, serving military personnel) always hate it when engineers respond to trouble reports by saying, "It worked perfectly in our laboratory simulations."</p></htmltext>
<tokenext>Correct functioning of the system is required.How many torpedo and nuclear cruise missile launches off those " upgraded " SSBNs have we had , that we may verify the correct functioning of the new computerized system ? If it was tested with " dummy " torpedoes and missiles , how closely did the dummies replicate the live ones ? Customers ( in this case , serving military personnel ) always hate it when engineers respond to trouble reports by saying , " It worked perfectly in our laboratory simulations .
"</tokentext>
<sentencetext>Correct functioning of the system is required.How many torpedo and nuclear cruise missile launches off those "upgraded" SSBNs have we had, that we may verify the correct functioning of the new computerized system?If it was tested with "dummy" torpedoes and missiles, how closely did the dummies replicate the live ones?Customers (in this case, serving military personnel) always hate it when engineers respond to trouble reports by saying, "It worked perfectly in our laboratory simulations.
"</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466616</id>
	<title>Re:Toyota:</title>
	<author>Anonymous</author>
	<datestamp>1268474400000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Always going forward.</p></div><p>Even if you don't want to.</p></div>
	</htmltext>
<tokenext>Always going forward.Even if you do n't want to .</tokentext>
<sentencetext>Always going forward.Even if you don't want to.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467680</id>
	<title>Re:A Most Unusual Bug Indeed</title>
	<author>Anonymous</author>
	<datestamp>1268482560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Maybe it just means baby boomers are spoiled and unamerican assholes and only buy the "cool" cars they see on television. Meaning more buy foreign products like Toyota, then they call their kids "losers" because the boomers spent up the wealth created by their parents and all the jobs are now overseas.

</p><p>While boomers may not give a shit about other people, drive recklessly, try to blame accidents they cause on other people, and like to make frivolous lawsuits, I doubt this problem is made up. Software does have bugs you know, and there are a lot of incompetent MCSEs out there posing as real programmers.</p></htmltext>
<tokenext>Maybe it just means baby boomers are spoiled and unamerican assholes and only buy the " cool " cars they see on television .
Meaning more buy foreign products like Toyota , then they call their kids " losers " because the boomers spent up the wealth created by their parents and all the jobs are now overseas .
While boomers may not give a shit about other people , drive recklessly , try to blame accidents they cause on other people , and like to make frivolous lawsuits , I doubt this problem is made up .
Software does have bugs you know , and there are a lot of incompetent MCSEs out there posing as real programmers .</tokentext>
<sentencetext>Maybe it just means baby boomers are spoiled and unamerican assholes and only buy the "cool" cars they see on television.
Meaning more buy foreign products like Toyota, then they call their kids "losers" because the boomers spent up the wealth created by their parents and all the jobs are now overseas.
While boomers may not give a shit about other people, drive recklessly, try to blame accidents they cause on other people, and like to make frivolous lawsuits, I doubt this problem is made up.
Software does have bugs you know, and there are a lot of incompetent MCSEs out there posing as real programmers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466956</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469242</id>
	<title>Happens in the US only?</title>
	<author>multi io</author>
	<datestamp>1268495880000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The last thing I heard was that these Toyota problems happen in the US only, or at least have devastating consequences in the US only. There are reports of more than 50 deaths that are supposed to have been caused by these "uncontrollable acceleration" issues in the US, while the combined death toll of these problems in all other countries is zero. Now, I'm generally not a supporter of conspiracy theories or speculative explanations that suggest things like some mild mass psychosis (culturally induced, irrational fear of evil engines going berserk, maybe?), but if the above numbers are correct, they're far beyond the realm of mere statistical fluctuations.</htmltext>
<tokenext>The last thing I heard was that these Toyota problems happen in the US only , or at least have devastating consequences in the US only .
There are reports of more than 50 deaths that are supposed to have been caused by these " uncontrollable acceleration " issues in the US , while the combined death toll of these problems in all other countries is zero .
Now , I 'm generally not a supporter of conspiracy theories or speculative explanations that suggest things like some mild mass psychosis ( culturally induced , irrational fear of evil engines going berserk , maybe ?
) , but if the above numbers are correct , they 're far beyond the realm of mere statistical fluctuations .</tokentext>
<sentencetext>The last thing I heard was that these Toyota problems happen in the US only, or at least have devastating consequences in the US only.
There are reports of more than 50 deaths that are supposed to have been caused by these "uncontrollable acceleration" issues in the US, while the combined death toll of these problems in all other countries is zero.
Now, I'm generally not a supporter of conspiracy theories or speculative explanations that suggest things like some mild mass psychosis (culturally induced, irrational fear of evil engines going berserk, maybe?
), but if the above numbers are correct, they're far beyond the realm of mere statistical fluctuations.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31488020</id>
	<title>Re:Toyota:</title>
	<author>onemorechip</author>
	<datestamp>1268648580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Chevy had the Nova. Toyota should name one of their models the Nopara.</p></htmltext>
<tokenext>Chevy had the Nova .
Toyota should name one of their models the Nopara .</tokentext>
<sentencetext>Chevy had the Nova.
Toyota should name one of their models the Nopara.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470644</id>
	<title>Re:A Most Unusual Bug Indeed</title>
	<author>Sycraft-fu</author>
	<datestamp>1268557980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The brakes in the cars in question are not only power assisted, but are also anti-lock. They have an extremely high amount of braking force, as do more or less all brakes these days.</p></htmltext>
<tokenext>The brakes in the cars in question are not only power assisted , but are also anti-lock .
They have an extremely high amount of braking force , as do more or less all brakes these days .</tokentext>
<sentencetext>The brakes in the cars in question are not only power assisted, but are also anti-lock.
They have an extremely high amount of braking force, as do more or less all brakes these days.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469448</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467020</id>
	<title>Re:Help me benefit from media hype</title>
	<author>Radio\_active\_cgb</author>
	<datestamp>1268477580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I saw a video this morning from Edmunds (via cnet) that showed what happens in a Prius when you shift to neutral (and reverse). When shifting to neutral (with the gas pedal floored), the engine is disengaged and idled and the car started slowing. Shifting to reverse does the same thing and the car beeps at you. For these to work, you have to hold the shifter for a second or two.</p><p><a href="http://news.cnet.com/8301-13924\_3-10468020-64.html?part=rss&amp;subj=news&amp;tag=2547-1\_3-0-20" title="cnet.com" rel="nofollow">http://news.cnet.com/8301-13924\_3-10468020-64.html?part=rss&amp;subj=news&amp;tag=2547-1\_3-0-20</a> [cnet.com]</p></htmltext>
<tokenext>I saw a video this morning from Edmunds ( via cnet ) that showed what happens in a Prius when you shift to neutral ( and reverse ) .
When shifting to neutral ( with the gas pedal floored ) , the engine is disengaged and idled and the car started slowing .
Shifting to reverse does the same thing and the car beeps at you .
For these to work , you have to hold the shifter for a second or two.http : //news.cnet.com/8301-13924 \ _3-10468020-64.html ? part = rss&amp;subj = news&amp;tag = 2547-1 \ _3-0-20 [ cnet.com ]</tokentext>
<sentencetext>I saw a video this morning from Edmunds (via cnet) that showed what happens in a Prius when you shift to neutral (and reverse).
When shifting to neutral (with the gas pedal floored), the engine is disengaged and idled and the car started slowing.
Shifting to reverse does the same thing and the car beeps at you.
For these to work, you have to hold the shifter for a second or two.http://news.cnet.com/8301-13924\_3-10468020-64.html?part=rss&amp;subj=news&amp;tag=2547-1\_3-0-20 [cnet.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465086</id>
	<title>Metric unit</title>
	<author>Sepiraph</author>
	<datestamp>1268506860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Did Toyota forget to convert imperial to metric unit like those Mars Pathfinder?</htmltext>
<tokenext>Did Toyota forget to convert imperial to metric unit like those Mars Pathfinder ?</tokentext>
<sentencetext>Did Toyota forget to convert imperial to metric unit like those Mars Pathfinder?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465506</id>
	<title>Re:Exactly</title>
	<author>Anonymous</author>
	<datestamp>1268509920000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>But there are umpteen different models and implementations.  I suppose they could all be wrong, but it would be more than a simple coding error if so.</p></htmltext>
<tokenext>But there are umpteen different models and implementations .
I suppose they could all be wrong , but it would be more than a simple coding error if so .</tokentext>
<sentencetext>But there are umpteen different models and implementations.
I suppose they could all be wrong, but it would be more than a simple coding error if so.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464924</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026</id>
	<title>From the days of "winmodems"</title>
	<author>A\_Non\_Moose</author>
	<datestamp>1268506380000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>I've said time and time again, "Never replace hardware with software" because<br>something dedicated to the task will always work better, or be less failure<br>prone (more often than not).</p><p>Would Toyota be having these problems with an accelerator cable vs electronic?</p><p>99\% sure the answer is "no"...heck the solution is add some grease, make sure<br>it isn't pinched/looped too tightly and/or add tension to the pedal side.</p><p>Or, replace the damn cable with a new one...a 20 to 30 minute task.<br>(less than 10min on a motorcycle)</p><p>Oh, well, what do I know?  I'm just a CS major with real world experience, pay<br>no attention to the man behind the keyboard!!!</p></htmltext>
<tokenext>I 've said time and time again , " Never replace hardware with software " becausesomething dedicated to the task will always work better , or be less failureprone ( more often than not ) .Would Toyota be having these problems with an accelerator cable vs electronic ? 99 \ % sure the answer is " no " ...heck the solution is add some grease , make sureit is n't pinched/looped too tightly and/or add tension to the pedal side.Or , replace the damn cable with a new one...a 20 to 30 minute task .
( less than 10min on a motorcycle ) Oh , well , what do I know ?
I 'm just a CS major with real world experience , payno attention to the man behind the keyboard ! !
!</tokentext>
<sentencetext>I've said time and time again, "Never replace hardware with software" becausesomething dedicated to the task will always work better, or be less failureprone (more often than not).Would Toyota be having these problems with an accelerator cable vs electronic?99\% sure the answer is "no"...heck the solution is add some grease, make sureit isn't pinched/looped too tightly and/or add tension to the pedal side.Or, replace the damn cable with a new one...a 20 to 30 minute task.
(less than 10min on a motorcycle)Oh, well, what do I know?
I'm just a CS major with real world experience, payno attention to the man behind the keyboard!!
!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465292</id>
	<title>Re:Are the brakes totally drive-by-wire as well?</title>
	<author>The End Of Days</author>
	<datestamp>1268508240000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>You're lucky this hasn't happened to you, that's the silly mistake all the people who have wrecked keep making.</p></htmltext>
<tokenext>You 're lucky this has n't happened to you , that 's the silly mistake all the people who have wrecked keep making .</tokentext>
<sentencetext>You're lucky this hasn't happened to you, that's the silly mistake all the people who have wrecked keep making.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465062</id>
	<title>Re:Toyota:</title>
	<author>TheLink</author>
	<datestamp>1268506740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>The car in front is a Toyota. And guess why<nobr> <wbr></nobr>;).</htmltext>
<tokenext>The car in front is a Toyota .
And guess why ; ) .</tokentext>
<sentencetext>The car in front is a Toyota.
And guess why ;).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464938</id>
	<title>There is only so much you can do..</title>
	<author>Anonymous</author>
	<datestamp>1268505720000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Well you can always assume that your real time code is buggy and write checks to ensure exact conditions before a critical assignment or operation. But given the limited amount of CPU there arent too many checks you can build into firmware.</p></htmltext>
<tokenext>Well you can always assume that your real time code is buggy and write checks to ensure exact conditions before a critical assignment or operation .
But given the limited amount of CPU there arent too many checks you can build into firmware .</tokentext>
<sentencetext>Well you can always assume that your real time code is buggy and write checks to ensure exact conditions before a critical assignment or operation.
But given the limited amount of CPU there arent too many checks you can build into firmware.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465016</id>
	<title>Smaller Systems Solution?</title>
	<author>Manip</author>
	<datestamp>1268506320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Didn't we already "solve" this problem in the airline industry by breaking down larger more complex software into separate physical components that can be more easily verified? Can we do the same with cars?</p><p>Just split one computer into half a dozen much smaller, simpler, little units and set the valid IO conditions for them, then have the components around them sanity check their output.</p></htmltext>
<tokenext>Did n't we already " solve " this problem in the airline industry by breaking down larger more complex software into separate physical components that can be more easily verified ?
Can we do the same with cars ? Just split one computer into half a dozen much smaller , simpler , little units and set the valid IO conditions for them , then have the components around them sanity check their output .</tokentext>
<sentencetext>Didn't we already "solve" this problem in the airline industry by breaking down larger more complex software into separate physical components that can be more easily verified?
Can we do the same with cars?Just split one computer into half a dozen much smaller, simpler, little units and set the valid IO conditions for them, then have the components around them sanity check their output.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468444</id>
	<title>Program more defensively?</title>
	<author>LennyP</author>
	<datestamp>1268488500000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"He argues that embedded systems developers must program more defensively, and that companies should stop relying on software for safety"</p><p>
I've been doing embedded systems development since about 1981 at companies such as Intel, Etec, Tait, and contracted for many, many others.  None of the companies I've worked for relied solely on software for safety; we all knew better.  Whether opening a door, sending a distress signal, or having a robot move there has always been a physical "wall" behind the software to prevent mishaps that could led to bodily harm or mission critical failures.

It is patently unfair to claim a generic problem with embedded system developers; especially true considering the extent embedded system are involved in our lives -- from thermostats to microwave ovens, from the bios in our PC to our TV, the list goes on and on.  Besides, as to the Toyota problem, we have no idea as to the cause and the reams of data we have are not reliable.</p></htmltext>
<tokenext>" He argues that embedded systems developers must program more defensively , and that companies should stop relying on software for safety " I 've been doing embedded systems development since about 1981 at companies such as Intel , Etec , Tait , and contracted for many , many others .
None of the companies I 've worked for relied solely on software for safety ; we all knew better .
Whether opening a door , sending a distress signal , or having a robot move there has always been a physical " wall " behind the software to prevent mishaps that could led to bodily harm or mission critical failures .
It is patently unfair to claim a generic problem with embedded system developers ; especially true considering the extent embedded system are involved in our lives -- from thermostats to microwave ovens , from the bios in our PC to our TV , the list goes on and on .
Besides , as to the Toyota problem , we have no idea as to the cause and the reams of data we have are not reliable .</tokentext>
<sentencetext>"He argues that embedded systems developers must program more defensively, and that companies should stop relying on software for safety"
I've been doing embedded systems development since about 1981 at companies such as Intel, Etec, Tait, and contracted for many, many others.
None of the companies I've worked for relied solely on software for safety; we all knew better.
Whether opening a door, sending a distress signal, or having a robot move there has always been a physical "wall" behind the software to prevent mishaps that could led to bodily harm or mission critical failures.
It is patently unfair to claim a generic problem with embedded system developers; especially true considering the extent embedded system are involved in our lives -- from thermostats to microwave ovens, from the bios in our PC to our TV, the list goes on and on.
Besides, as to the Toyota problem, we have no idea as to the cause and the reams of data we have are not reliable.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918</id>
	<title>Help me benefit from media hype</title>
	<author>Kohath</author>
	<datestamp>1268505540000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'm in the market for a car and everyone is picking on Toyota now.</p><p>I don't believe in stupid media hype.  I don't believe cars rewire themselves.  And I know how to hit the breaks, shift into neutral, and/or turn off the key when I want the car to go slower (so far, hitting the breaks has always proven adequate).</p><p>Are there any really good deals on Toyotas available?</p></htmltext>
<tokenext>I 'm in the market for a car and everyone is picking on Toyota now.I do n't believe in stupid media hype .
I do n't believe cars rewire themselves .
And I know how to hit the breaks , shift into neutral , and/or turn off the key when I want the car to go slower ( so far , hitting the breaks has always proven adequate ) .Are there any really good deals on Toyotas available ?</tokentext>
<sentencetext>I'm in the market for a car and everyone is picking on Toyota now.I don't believe in stupid media hype.
I don't believe cars rewire themselves.
And I know how to hit the breaks, shift into neutral, and/or turn off the key when I want the car to go slower (so far, hitting the breaks has always proven adequate).Are there any really good deals on Toyotas available?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465000</id>
	<title>Failsafe software</title>
	<author>Anonymous</author>
	<datestamp>1268506140000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>All practically sized software has bugs, but that doesn't mean it has to be dangerous. Mechanical devices fail too and therefore the engineers add failsafe-mechanisms. If something breaks, something else must absorb the problem. Consistency checks and redundancy are indispensable even when the code is perfect, because hardware is never infallible.</p></htmltext>
<tokenext>All practically sized software has bugs , but that does n't mean it has to be dangerous .
Mechanical devices fail too and therefore the engineers add failsafe-mechanisms .
If something breaks , something else must absorb the problem .
Consistency checks and redundancy are indispensable even when the code is perfect , because hardware is never infallible .</tokentext>
<sentencetext>All practically sized software has bugs, but that doesn't mean it has to be dangerous.
Mechanical devices fail too and therefore the engineers add failsafe-mechanisms.
If something breaks, something else must absorb the problem.
Consistency checks and redundancy are indispensable even when the code is perfect, because hardware is never infallible.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465150</id>
	<title>Sol'n: fly by half-wire</title>
	<author>robert bitchin'</author>
	<datestamp>1268507220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Most throttle systems I've worked with employed two cables to control the throttle in a push-pull arrangement. If setup in a single-wire arrangement then only one wire is used to pull the throttle open and a spring is used to ensure it closes when the tension is removed. In some motorcycles where the operators have a literal grip on the throttle then, if the spring is not strong enough to close the throttle (or one of the cables jams), the operator can always physically force its return by turning the throttle back manually. Car operators using pedal-based accelerators, unless they are barefoot, cannot wrap their toes around the pedal to pull it back into position.
<br>
<br>
My solution blends the two strategies: retain the pedal position sensor that captures the operators intention while retaining use of a 'return' cable.  The ECU can remain in control of advancing the throttle to retain their interest in fuel economy measures while removing its control over retarding it. Pushing the pedal down merely provides enough physical free play for the ECU to work with while retaining any veto control if it gets out of hand.
<br>
<br>
The final part would encourage the adoption of accelerator pedals that users slip their feet into rather than just on top of. This would provide the same ability to positively influence the pedal return rather than expect the spring to do so.</htmltext>
<tokenext>Most throttle systems I 've worked with employed two cables to control the throttle in a push-pull arrangement .
If setup in a single-wire arrangement then only one wire is used to pull the throttle open and a spring is used to ensure it closes when the tension is removed .
In some motorcycles where the operators have a literal grip on the throttle then , if the spring is not strong enough to close the throttle ( or one of the cables jams ) , the operator can always physically force its return by turning the throttle back manually .
Car operators using pedal-based accelerators , unless they are barefoot , can not wrap their toes around the pedal to pull it back into position .
My solution blends the two strategies : retain the pedal position sensor that captures the operators intention while retaining use of a 'return ' cable .
The ECU can remain in control of advancing the throttle to retain their interest in fuel economy measures while removing its control over retarding it .
Pushing the pedal down merely provides enough physical free play for the ECU to work with while retaining any veto control if it gets out of hand .
The final part would encourage the adoption of accelerator pedals that users slip their feet into rather than just on top of .
This would provide the same ability to positively influence the pedal return rather than expect the spring to do so .</tokentext>
<sentencetext>Most throttle systems I've worked with employed two cables to control the throttle in a push-pull arrangement.
If setup in a single-wire arrangement then only one wire is used to pull the throttle open and a spring is used to ensure it closes when the tension is removed.
In some motorcycles where the operators have a literal grip on the throttle then, if the spring is not strong enough to close the throttle (or one of the cables jams), the operator can always physically force its return by turning the throttle back manually.
Car operators using pedal-based accelerators, unless they are barefoot, cannot wrap their toes around the pedal to pull it back into position.
My solution blends the two strategies: retain the pedal position sensor that captures the operators intention while retaining use of a 'return' cable.
The ECU can remain in control of advancing the throttle to retain their interest in fuel economy measures while removing its control over retarding it.
Pushing the pedal down merely provides enough physical free play for the ECU to work with while retaining any veto control if it gets out of hand.
The final part would encourage the adoption of accelerator pedals that users slip their feet into rather than just on top of.
This would provide the same ability to positively influence the pedal return rather than expect the spring to do so.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464840</id>
	<title>Impossible to test</title>
	<author>Anonymous</author>
	<datestamp>1268504880000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>4</modscore>
	<htmltext>Most software is nearly -impossible- to test under flawless conditions. Especially embedded systems with small amounts of CPU power and memory. <br> <br>

Plus, all this hype around these Toyota acceleration problems is just that, hype.</htmltext>
<tokenext>Most software is nearly -impossible- to test under flawless conditions .
Especially embedded systems with small amounts of CPU power and memory .
Plus , all this hype around these Toyota acceleration problems is just that , hype .</tokentext>
<sentencetext>Most software is nearly -impossible- to test under flawless conditions.
Especially embedded systems with small amounts of CPU power and memory.
Plus, all this hype around these Toyota acceleration problems is just that, hype.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465940</id>
	<title>Story of an elusive bug...</title>
	<author>descubes</author>
	<datestamp>1268513040000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>2</modscore>
	<htmltext><p>Several years ago, I designed the software for a real-time automotive test system called HP  ECUTEST (I think the official name was HP Design Span DS5470, but let's not waste time on HP's cold dead fish naming conventions). It simulated a car from an electric point of view. You connected an electronic control unit (ECU), and it had basically no way to tell it was not in a real car. Think of it as The Matrix for car electronics.</p><p>One of our first customers wanted us to test it with a reliable, proven, tested, tried and true ECU, something that was on the road in cars for several years already. So we did. And I noticed something odd. The ECU worked fine when we "drove" a car normally, but at idle, it would basically slow down, one RPM at a time, until it stopped. However, if I changed the value of the input corresponding to the accelerator pedal, it would reset the idle speed to the default, something like 800rpm.</p><p>Finally, after eliminating the possible bugs on our side, we tell the customer. Their first reaction was "no way". But after a week and a demo of the problem, they finally made a connection. They had this elusive bug of some car customers complaining that their car would sometimes stop when idle. It turns out that in a real car, chassis vibrations generally caused minute changes in the input value for the accelerator. So the ECU would correctly recompute its idle speed. However, if there was no change, like if the pedal was more rigid than usual, the bug would trigger.</p><p>The root cause was a routine that wanted to optimize idle speed to be as low as possible, but for some reason kept cached data if the accelerator had not changed, so it thought the engine was still running smoothly.</p><p>We found such bugs in practically all ECUs we tested for the first time. The most impressive one was in a V8 ECU that was basically a V8 until 1200rpm, then a V7, then a V6, and basically a V2 above 4000 rpm. The customer had hoped we'd find something, because they didn't get all the power they expected from the engine. Obviously. It was hard to find without our system, because the injectors that fired were differnt from cycle to cycle, so more simple instrumentation saw all cylinders running. The root cause here was that the software badly exceeded its real-time envelope... Ouch.</p></htmltext>
<tokenext>Several years ago , I designed the software for a real-time automotive test system called HP ECUTEST ( I think the official name was HP Design Span DS5470 , but let 's not waste time on HP 's cold dead fish naming conventions ) .
It simulated a car from an electric point of view .
You connected an electronic control unit ( ECU ) , and it had basically no way to tell it was not in a real car .
Think of it as The Matrix for car electronics.One of our first customers wanted us to test it with a reliable , proven , tested , tried and true ECU , something that was on the road in cars for several years already .
So we did .
And I noticed something odd .
The ECU worked fine when we " drove " a car normally , but at idle , it would basically slow down , one RPM at a time , until it stopped .
However , if I changed the value of the input corresponding to the accelerator pedal , it would reset the idle speed to the default , something like 800rpm.Finally , after eliminating the possible bugs on our side , we tell the customer .
Their first reaction was " no way " .
But after a week and a demo of the problem , they finally made a connection .
They had this elusive bug of some car customers complaining that their car would sometimes stop when idle .
It turns out that in a real car , chassis vibrations generally caused minute changes in the input value for the accelerator .
So the ECU would correctly recompute its idle speed .
However , if there was no change , like if the pedal was more rigid than usual , the bug would trigger.The root cause was a routine that wanted to optimize idle speed to be as low as possible , but for some reason kept cached data if the accelerator had not changed , so it thought the engine was still running smoothly.We found such bugs in practically all ECUs we tested for the first time .
The most impressive one was in a V8 ECU that was basically a V8 until 1200rpm , then a V7 , then a V6 , and basically a V2 above 4000 rpm .
The customer had hoped we 'd find something , because they did n't get all the power they expected from the engine .
Obviously. It was hard to find without our system , because the injectors that fired were differnt from cycle to cycle , so more simple instrumentation saw all cylinders running .
The root cause here was that the software badly exceeded its real-time envelope... Ouch .</tokentext>
<sentencetext>Several years ago, I designed the software for a real-time automotive test system called HP  ECUTEST (I think the official name was HP Design Span DS5470, but let's not waste time on HP's cold dead fish naming conventions).
It simulated a car from an electric point of view.
You connected an electronic control unit (ECU), and it had basically no way to tell it was not in a real car.
Think of it as The Matrix for car electronics.One of our first customers wanted us to test it with a reliable, proven, tested, tried and true ECU, something that was on the road in cars for several years already.
So we did.
And I noticed something odd.
The ECU worked fine when we "drove" a car normally, but at idle, it would basically slow down, one RPM at a time, until it stopped.
However, if I changed the value of the input corresponding to the accelerator pedal, it would reset the idle speed to the default, something like 800rpm.Finally, after eliminating the possible bugs on our side, we tell the customer.
Their first reaction was "no way".
But after a week and a demo of the problem, they finally made a connection.
They had this elusive bug of some car customers complaining that their car would sometimes stop when idle.
It turns out that in a real car, chassis vibrations generally caused minute changes in the input value for the accelerator.
So the ECU would correctly recompute its idle speed.
However, if there was no change, like if the pedal was more rigid than usual, the bug would trigger.The root cause was a routine that wanted to optimize idle speed to be as low as possible, but for some reason kept cached data if the accelerator had not changed, so it thought the engine was still running smoothly.We found such bugs in practically all ECUs we tested for the first time.
The most impressive one was in a V8 ECU that was basically a V8 until 1200rpm, then a V7, then a V6, and basically a V2 above 4000 rpm.
The customer had hoped we'd find something, because they didn't get all the power they expected from the engine.
Obviously. It was hard to find without our system, because the injectors that fired were differnt from cycle to cycle, so more simple instrumentation saw all cylinders running.
The root cause here was that the software badly exceeded its real-time envelope... Ouch.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466530</id>
	<title>finally, someone is stating the obvious</title>
	<author>cfriedt</author>
	<datestamp>1268473740000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is what I've been saying all along; it could have easily been caused by some lazy programmer who didn't check a return value, overlooked integer overflow, or made an inappropriate type cast.</p><p>On the other hand, I  do agree that there is a large chance that it could be due to 'ground bounce' or other EM noise. However, the electrical &amp; computer systems on automobiles should really be considered one in the same. They are the left and right hands of an entity and need to communicate effectively with each other. If there is electrical interference, then the signal processing system should take that into consideration and filter it out. If there is too much electrical interference, then the electronics should be re-designed!</p></htmltext>
<tokenext>This is what I 've been saying all along ; it could have easily been caused by some lazy programmer who did n't check a return value , overlooked integer overflow , or made an inappropriate type cast.On the other hand , I do agree that there is a large chance that it could be due to 'ground bounce ' or other EM noise .
However , the electrical &amp; computer systems on automobiles should really be considered one in the same .
They are the left and right hands of an entity and need to communicate effectively with each other .
If there is electrical interference , then the signal processing system should take that into consideration and filter it out .
If there is too much electrical interference , then the electronics should be re-designed !</tokentext>
<sentencetext>This is what I've been saying all along; it could have easily been caused by some lazy programmer who didn't check a return value, overlooked integer overflow, or made an inappropriate type cast.On the other hand, I  do agree that there is a large chance that it could be due to 'ground bounce' or other EM noise.
However, the electrical &amp; computer systems on automobiles should really be considered one in the same.
They are the left and right hands of an entity and need to communicate effectively with each other.
If there is electrical interference, then the signal processing system should take that into consideration and filter it out.
If there is too much electrical interference, then the electronics should be re-designed!</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465520</id>
	<title>Re:Toyota:</title>
	<author>bytesex</author>
	<datestamp>1268510040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Still can't find reverse.</p></htmltext>
<tokenext>Still ca n't find reverse .</tokentext>
<sentencetext>Still can't find reverse.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470760</id>
	<title>Re:From the days of "winmodems"</title>
	<author>Anonymous</author>
	<datestamp>1268560860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Hardware has bugs too.<br>I test MicroProcessor design rtl for a living.<br>How about a Cache writing zeros to memory instead of the actual data?<br>All due to buffers controls being mis-timed for a transaction 1000 clocks earlier.<br>Seen literally 1000's of bugs this bad and worse (like dead-lock and live-lock).<br>Last CPU and memory subsytem had over 5000 bugs from start to finish.</p></htmltext>
<tokenext>Hardware has bugs too.I test MicroProcessor design rtl for a living.How about a Cache writing zeros to memory instead of the actual data ? All due to buffers controls being mis-timed for a transaction 1000 clocks earlier.Seen literally 1000 's of bugs this bad and worse ( like dead-lock and live-lock ) .Last CPU and memory subsytem had over 5000 bugs from start to finish .</tokentext>
<sentencetext>Hardware has bugs too.I test MicroProcessor design rtl for a living.How about a Cache writing zeros to memory instead of the actual data?All due to buffers controls being mis-timed for a transaction 1000 clocks earlier.Seen literally 1000's of bugs this bad and worse (like dead-lock and live-lock).Last CPU and memory subsytem had over 5000 bugs from start to finish.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465794</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</id>
	<title>Logic of Testing</title>
	<author>Anonymous</author>
	<datestamp>1268505480000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext><p>David Cummings does seem to know what he's talking about, but as it is written, there is some strange logic in the article.</p><blockquote><div><p>If Toyota has indeed tested its software as thoroughly as it says without finding any bugs, my response is simple: Keep trying.</p></div></blockquote><p>Testing cannot prove the absence of bugs, only their presence. There are two things that do <b>not</b> follow from this:</p><ul>
<li>If you don't find any bugs, then your software doesn't have any.</li><li>If you don't find any bugs, then there must be some left in your software.</li></ul><p>It sounds to me as if Toyota is saying the former, while Cummings says the latter. Neither is a correct conclusion.</p></div>
	</htmltext>
<tokenext>David Cummings does seem to know what he 's talking about , but as it is written , there is some strange logic in the article.If Toyota has indeed tested its software as thoroughly as it says without finding any bugs , my response is simple : Keep trying.Testing can not prove the absence of bugs , only their presence .
There are two things that do not follow from this : If you do n't find any bugs , then your software does n't have any.If you do n't find any bugs , then there must be some left in your software.It sounds to me as if Toyota is saying the former , while Cummings says the latter .
Neither is a correct conclusion .</tokentext>
<sentencetext>David Cummings does seem to know what he's talking about, but as it is written, there is some strange logic in the article.If Toyota has indeed tested its software as thoroughly as it says without finding any bugs, my response is simple: Keep trying.Testing cannot prove the absence of bugs, only their presence.
There are two things that do not follow from this:
If you don't find any bugs, then your software doesn't have any.If you don't find any bugs, then there must be some left in your software.It sounds to me as if Toyota is saying the former, while Cummings says the latter.
Neither is a correct conclusion.
	</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31472142</id>
	<title>Mechanical Systems Fail</title>
	<author>not-my-real-name</author>
	<datestamp>1268582460000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Years ago, I had a Datsun B210.  There probably wasn't even software in the car radio.  I lived in the Seattle area at the time.  It's fairly humid there and at certain time a little ice would form in the carburetor and cause the throttle to stick open.  The first time it happened to me was a bit of a shock.  I stepped on the clutch and the RPMs jumped.  I then hit the brakes, and turned off the engine and costed to the side of the highway.</p><p>The next time it happened I discovered that kicking the accelerator pedal would break the ice and let things work normally.  Not too long after that, "Oxygenated Fuel" was introduced and the problem disappeared.</p></htmltext>
<tokenext>Years ago , I had a Datsun B210 .
There probably was n't even software in the car radio .
I lived in the Seattle area at the time .
It 's fairly humid there and at certain time a little ice would form in the carburetor and cause the throttle to stick open .
The first time it happened to me was a bit of a shock .
I stepped on the clutch and the RPMs jumped .
I then hit the brakes , and turned off the engine and costed to the side of the highway.The next time it happened I discovered that kicking the accelerator pedal would break the ice and let things work normally .
Not too long after that , " Oxygenated Fuel " was introduced and the problem disappeared .</tokentext>
<sentencetext>Years ago, I had a Datsun B210.
There probably wasn't even software in the car radio.
I lived in the Seattle area at the time.
It's fairly humid there and at certain time a little ice would form in the carburetor and cause the throttle to stick open.
The first time it happened to me was a bit of a shock.
I stepped on the clutch and the RPMs jumped.
I then hit the brakes, and turned off the engine and costed to the side of the highway.The next time it happened I discovered that kicking the accelerator pedal would break the ice and let things work normally.
Not too long after that, "Oxygenated Fuel" was introduced and the problem disappeared.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466814</id>
	<title>Re:Help me benefit from media hype</title>
	<author>Anonymous</author>
	<datestamp>1268475960000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>&gt;&gt; And I know how to hit the brakes...</p><p>&gt; With the engine past the redline there is very little vacuum to operate the<br>&gt; power brakes. Without power assist the brakes may not be able to overcome the<br>&gt; engine (this is, IMHO, a fundamental design defect).<br>Fortunately, this is just a severe lack of understanding of Bernoulli's principle. With air traveling at high velocity through the intake pipe, any pipe connected to the intake pipe will be pumped mostly empty by dynamic (under)pressure. In the case of an almost closed throttle, the static vacuum keeps the power brakes powered. There is no obvious design defect here.</p><p>Some anonymous cow^Wphysicist.</p><p>
&nbsp; &nbsp;</p></htmltext>
<tokenext>&gt; &gt; And I know how to hit the brakes... &gt; With the engine past the redline there is very little vacuum to operate the &gt; power brakes .
Without power assist the brakes may not be able to overcome the &gt; engine ( this is , IMHO , a fundamental design defect ) .Fortunately , this is just a severe lack of understanding of Bernoulli 's principle .
With air traveling at high velocity through the intake pipe , any pipe connected to the intake pipe will be pumped mostly empty by dynamic ( under ) pressure .
In the case of an almost closed throttle , the static vacuum keeps the power brakes powered .
There is no obvious design defect here.Some anonymous cow ^ Wphysicist .
   </tokentext>
<sentencetext>&gt;&gt; And I know how to hit the brakes...&gt; With the engine past the redline there is very little vacuum to operate the&gt; power brakes.
Without power assist the brakes may not be able to overcome the&gt; engine (this is, IMHO, a fundamental design defect).Fortunately, this is just a severe lack of understanding of Bernoulli's principle.
With air traveling at high velocity through the intake pipe, any pipe connected to the intake pipe will be pumped mostly empty by dynamic (under)pressure.
In the case of an almost closed throttle, the static vacuum keeps the power brakes powered.
There is no obvious design defect here.Some anonymous cow^Wphysicist.
   </sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469362</id>
	<title>Re:Help me benefit from media hype</title>
	<author>Mspangler</author>
	<datestamp>1268496840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>"Some of these vehicles don't have keys: just a radio remote. The emergency shutdown procedure is to hold a button down for three seconds (another design defect)."</p><p>What makes this ironic is that motorcycles are required to have kill switches on the handlebar in case the mechanical clutch or throttle cables break. Evidently the time has come for a Big Red Button that shuts down the engine/motor, Now. No argument. I don't care what the computer thinks I want, shut it down right effing now.</p><p>I drove a Prius on a business trip once. The user interface is odd enough that it was a bear to figure out, especially after the long plane ride. I remember the funny little joystick to shift, I remember a Park, forward, and reverse. I don't remember if there was a neutral. The "key" wasn't really  a key either.</p><p>Keep your finger on a dashboard button for three seconds while dodging traffic at 90 MPH?  Not easy to do.</p><p>I wonder what Nissan is doing with their electric car?  It better come with a positive shutdown of some sort, and the shut down had better not be an input pin into the engine control computer either.</p></htmltext>
<tokenext>" Some of these vehicles do n't have keys : just a radio remote .
The emergency shutdown procedure is to hold a button down for three seconds ( another design defect ) .
" What makes this ironic is that motorcycles are required to have kill switches on the handlebar in case the mechanical clutch or throttle cables break .
Evidently the time has come for a Big Red Button that shuts down the engine/motor , Now .
No argument .
I do n't care what the computer thinks I want , shut it down right effing now.I drove a Prius on a business trip once .
The user interface is odd enough that it was a bear to figure out , especially after the long plane ride .
I remember the funny little joystick to shift , I remember a Park , forward , and reverse .
I do n't remember if there was a neutral .
The " key " was n't really a key either.Keep your finger on a dashboard button for three seconds while dodging traffic at 90 MPH ?
Not easy to do.I wonder what Nissan is doing with their electric car ?
It better come with a positive shutdown of some sort , and the shut down had better not be an input pin into the engine control computer either .</tokentext>
<sentencetext>"Some of these vehicles don't have keys: just a radio remote.
The emergency shutdown procedure is to hold a button down for three seconds (another design defect).
"What makes this ironic is that motorcycles are required to have kill switches on the handlebar in case the mechanical clutch or throttle cables break.
Evidently the time has come for a Big Red Button that shuts down the engine/motor, Now.
No argument.
I don't care what the computer thinks I want, shut it down right effing now.I drove a Prius on a business trip once.
The user interface is odd enough that it was a bear to figure out, especially after the long plane ride.
I remember the funny little joystick to shift, I remember a Park, forward, and reverse.
I don't remember if there was a neutral.
The "key" wasn't really  a key either.Keep your finger on a dashboard button for three seconds while dodging traffic at 90 MPH?
Not easy to do.I wonder what Nissan is doing with their electric car?
It better come with a positive shutdown of some sort, and the shut down had better not be an input pin into the engine control computer either.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31473334</id>
	<title>touch-sensitive dashboard is the problem</title>
	<author>minstrelmike</author>
	<datestamp>1268593380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I'll bet the touch-sensitive dashboard is the problem. Click and Clack said it could cost $800-$2000 to fix one messed up by a teacher putting a refrigerator magnet on it. What other sorts of random inputs will occur from dust, sweaty hands, or spit? I'll bet they haven't tested for that at all.</htmltext>
<tokenext>I 'll bet the touch-sensitive dashboard is the problem .
Click and Clack said it could cost $ 800- $ 2000 to fix one messed up by a teacher putting a refrigerator magnet on it .
What other sorts of random inputs will occur from dust , sweaty hands , or spit ?
I 'll bet they have n't tested for that at all .</tokentext>
<sentencetext>I'll bet the touch-sensitive dashboard is the problem.
Click and Clack said it could cost $800-$2000 to fix one messed up by a teacher putting a refrigerator magnet on it.
What other sorts of random inputs will occur from dust, sweaty hands, or spit?
I'll bet they haven't tested for that at all.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465210</id>
	<title>both feet</title>
	<author>Anonymous</author>
	<datestamp>1268507640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>My mother drives using both feet, as in one foot on the brake and the other on the gas. She has always driven this way. Does anyone know if this is common or unsafe?</p></htmltext>
<tokenext>My mother drives using both feet , as in one foot on the brake and the other on the gas .
She has always driven this way .
Does anyone know if this is common or unsafe ?</tokentext>
<sentencetext>My mother drives using both feet, as in one foot on the brake and the other on the gas.
She has always driven this way.
Does anyone know if this is common or unsafe?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465070</id>
	<title>Re:Toyota:</title>
	<author>Afforess</author>
	<datestamp>1268506800000</datestamp>
	<modclass>Funny</modclass>
	<modscore>2</modscore>
	<htmltext>"The race for quality has no finish line- so technically, it's more like a death march."
<br> <br>
Not my quote, so I'll give them props: <a href="http://www.despair.com/quality.html" title="despair.com">http://www.despair.com/quality.html</a> [despair.com]</div>
	</htmltext>
<tokenext>" The race for quality has no finish line- so technically , it 's more like a death march .
" Not my quote , so I 'll give them props : http : //www.despair.com/quality.html [ despair.com ]</tokentext>
<sentencetext>"The race for quality has no finish line- so technically, it's more like a death march.
"
 
Not my quote, so I'll give them props: http://www.despair.com/quality.html [despair.com]
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470430</id>
	<title>Toyota stands behind their products!</title>
	<author>symbolset</author>
	<datestamp>1268597340000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>And that's good, because it's not so safe to stand in front of them.
</p><p>/Not mine.  Shamelessly stolen.  Love my Camry.  Don't sue me.  Please?</p></htmltext>
<tokenext>And that 's good , because it 's not so safe to stand in front of them .
/Not mine .
Shamelessly stolen .
Love my Camry .
Do n't sue me .
Please ?</tokentext>
<sentencetext>And that's good, because it's not so safe to stand in front of them.
/Not mine.
Shamelessly stolen.
Love my Camry.
Don't sue me.
Please?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465116</id>
	<title>Embedded Bugs can be a BITCH to find</title>
	<author>Anonymous</author>
	<datestamp>1268507040000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>1</modscore>
	<htmltext><p>So I work on a robotics team on all of the firmware which interfaces the main computer with the actuators and sensors it needs to move.  It drove me crazy because I had a bug that I couldn't replicate outside the robot.</p><p>If you were driving the robot around under normal operating circumstances, suddenly, the motor driver board would stop working.  I had a simple state machine on the motor board which would update the motors one by one, but I had a bug which I hadn't noticed because it seemed innocuous at the time:</p><p>I updated the state machine immediately *after* I initiated an action which would eventually start interrupt code.  Now, what ended up happening was that message about new speeds coming from the main board were also interrupts, and so there was this very odd cascading failure, where the motor board would initiate the action, the message from the main board would come in, we would jump into the message receive interrupt, and then immediately we would jump into the motor control routine.  Since the state machine hadn't been updated yet, we would then execute the wrong part of the state machine, which would cause an error.  The motor control routine would initiate a "stop" command and then go into an error state.  Because this was a time-critical operation, I didn't care if we had failed to send a single packet, so I ignored the error, and jumped to the next motor.  Unfortunately, the "stop" command would finish right as I tried to reset the state machine, which would put it in a different error state.  And then when I tried to communicate with the next motor, I would do the same thing, over, and over, and over.</p><p>The whole system would lock up, but by itself, all the code was completely reasonable.  If you took that segment of code out of the system to verify that it worked, it would work 100\% of the time.  Put it into the system, and it generally took something like 10 to 20 minutes to suddenly die.</p></htmltext>
<tokenext>So I work on a robotics team on all of the firmware which interfaces the main computer with the actuators and sensors it needs to move .
It drove me crazy because I had a bug that I could n't replicate outside the robot.If you were driving the robot around under normal operating circumstances , suddenly , the motor driver board would stop working .
I had a simple state machine on the motor board which would update the motors one by one , but I had a bug which I had n't noticed because it seemed innocuous at the time : I updated the state machine immediately * after * I initiated an action which would eventually start interrupt code .
Now , what ended up happening was that message about new speeds coming from the main board were also interrupts , and so there was this very odd cascading failure , where the motor board would initiate the action , the message from the main board would come in , we would jump into the message receive interrupt , and then immediately we would jump into the motor control routine .
Since the state machine had n't been updated yet , we would then execute the wrong part of the state machine , which would cause an error .
The motor control routine would initiate a " stop " command and then go into an error state .
Because this was a time-critical operation , I did n't care if we had failed to send a single packet , so I ignored the error , and jumped to the next motor .
Unfortunately , the " stop " command would finish right as I tried to reset the state machine , which would put it in a different error state .
And then when I tried to communicate with the next motor , I would do the same thing , over , and over , and over.The whole system would lock up , but by itself , all the code was completely reasonable .
If you took that segment of code out of the system to verify that it worked , it would work 100 \ % of the time .
Put it into the system , and it generally took something like 10 to 20 minutes to suddenly die .</tokentext>
<sentencetext>So I work on a robotics team on all of the firmware which interfaces the main computer with the actuators and sensors it needs to move.
It drove me crazy because I had a bug that I couldn't replicate outside the robot.If you were driving the robot around under normal operating circumstances, suddenly, the motor driver board would stop working.
I had a simple state machine on the motor board which would update the motors one by one, but I had a bug which I hadn't noticed because it seemed innocuous at the time:I updated the state machine immediately *after* I initiated an action which would eventually start interrupt code.
Now, what ended up happening was that message about new speeds coming from the main board were also interrupts, and so there was this very odd cascading failure, where the motor board would initiate the action, the message from the main board would come in, we would jump into the message receive interrupt, and then immediately we would jump into the motor control routine.
Since the state machine hadn't been updated yet, we would then execute the wrong part of the state machine, which would cause an error.
The motor control routine would initiate a "stop" command and then go into an error state.
Because this was a time-critical operation, I didn't care if we had failed to send a single packet, so I ignored the error, and jumped to the next motor.
Unfortunately, the "stop" command would finish right as I tried to reset the state machine, which would put it in a different error state.
And then when I tried to communicate with the next motor, I would do the same thing, over, and over, and over.The whole system would lock up, but by itself, all the code was completely reasonable.
If you took that segment of code out of the system to verify that it worked, it would work 100\% of the time.
Put it into the system, and it generally took something like 10 to 20 minutes to suddenly die.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465346</id>
	<title>Feedback control?</title>
	<author>Grieviant</author>
	<datestamp>1268508840000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Surely the fault couldn't be something as simple as the speed or acceleration sensor becoming saturated?  This could throw off even a properly designed, stable feedback loop because the basic analysis doesn't consider nonlinearities.  I'm assuming that it is in fact a proper digital feedback system done in hardware (in which case the only software involved is a digital filter responding to periodic interrupt requests), not some wishy-washy software routine that can't be analyzed for stability.</htmltext>
<tokenext>Surely the fault could n't be something as simple as the speed or acceleration sensor becoming saturated ?
This could throw off even a properly designed , stable feedback loop because the basic analysis does n't consider nonlinearities .
I 'm assuming that it is in fact a proper digital feedback system done in hardware ( in which case the only software involved is a digital filter responding to periodic interrupt requests ) , not some wishy-washy software routine that ca n't be analyzed for stability .</tokentext>
<sentencetext>Surely the fault couldn't be something as simple as the speed or acceleration sensor becoming saturated?
This could throw off even a properly designed, stable feedback loop because the basic analysis doesn't consider nonlinearities.
I'm assuming that it is in fact a proper digital feedback system done in hardware (in which case the only software involved is a digital filter responding to periodic interrupt requests), not some wishy-washy software routine that can't be analyzed for stability.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465200</id>
	<title>Re:Logic of Testing</title>
	<author>bughunter</author>
	<datestamp>1268507520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p> <i>If you don't find any bugs, then there must be some left in your software.</i></p> </div><p>No, Cummings is not saying that.</p><p>Cummings is saying "There are always bugs.  Therefore, if you don't find any, then you're not looking hard enough."</p><p>My SQA days for NASA manned space subcontractors taught me that no software is bug-free, unless it's trivially simple ("Hello World!").  The best you can hope for is to remove the critical ones.  And the more you do to try and secure the software, make it safer and more error-tolerant, the more bugs you introduce.  So you can never be 100\% positive that there's not another critical bug hiding somewhere, even when you think you've found the "last one."</p><p>Especially when you think you've found the last one.</p></div>
	</htmltext>
<tokenext>If you do n't find any bugs , then there must be some left in your software .
No , Cummings is not saying that.Cummings is saying " There are always bugs .
Therefore , if you do n't find any , then you 're not looking hard enough .
" My SQA days for NASA manned space subcontractors taught me that no software is bug-free , unless it 's trivially simple ( " Hello World ! " ) .
The best you can hope for is to remove the critical ones .
And the more you do to try and secure the software , make it safer and more error-tolerant , the more bugs you introduce .
So you can never be 100 \ % positive that there 's not another critical bug hiding somewhere , even when you think you 've found the " last one .
" Especially when you think you 've found the last one .</tokentext>
<sentencetext> If you don't find any bugs, then there must be some left in your software.
No, Cummings is not saying that.Cummings is saying "There are always bugs.
Therefore, if you don't find any, then you're not looking hard enough.
"My SQA days for NASA manned space subcontractors taught me that no software is bug-free, unless it's trivially simple ("Hello World!").
The best you can hope for is to remove the critical ones.
And the more you do to try and secure the software, make it safer and more error-tolerant, the more bugs you introduce.
So you can never be 100\% positive that there's not another critical bug hiding somewhere, even when you think you've found the "last one.
"Especially when you think you've found the last one.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024</id>
	<title>Are the brakes totally drive-by-wire as well?</title>
	<author>onionman</author>
	<datestamp>1268506380000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Pardon my laziness for not investigating this myself, but doesn't the Prius have a mechanical (hydraulic) link to the brakes that engages when the pedal is pushed down far enough?  I realize that the first portion of the braking is done electronically (for the regenerative braking system), but in an emergency wouldn't a full application of the brakes slow down the vehicle?</p></htmltext>
<tokenext>Pardon my laziness for not investigating this myself , but does n't the Prius have a mechanical ( hydraulic ) link to the brakes that engages when the pedal is pushed down far enough ?
I realize that the first portion of the braking is done electronically ( for the regenerative braking system ) , but in an emergency would n't a full application of the brakes slow down the vehicle ?</tokentext>
<sentencetext>Pardon my laziness for not investigating this myself, but doesn't the Prius have a mechanical (hydraulic) link to the brakes that engages when the pedal is pushed down far enough?
I realize that the first portion of the braking is done electronically (for the regenerative braking system), but in an emergency wouldn't a full application of the brakes slow down the vehicle?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464878</id>
	<title>Re:Impossible to test</title>
	<author>Anonymous</author>
	<datestamp>1268505180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>Most software is nearly -impossible- to test under flawless conditions. Especially embedded systems with small amounts of CPU power and memory.</p><p>Plus, all this hype around these Toyota acceleration problems is just that, hype.</p></div><p>Its not just software.  This is an embedded system, the software is highly dependent on the hardware involved.  When I say hardware, I mean the entire system of boards, wires, and connectors in the vehicle.  Embedded systems have a tight couple of software and hardware unlike your average computer application.  A slight error in the hardware systems would also send the software in some unknown behavior if not tested correctly/fully.  Its a fairly difficult feat to ensure complete software/hardware compliance in an embedded system.</p></div>
	</htmltext>
<tokenext>Most software is nearly -impossible- to test under flawless conditions .
Especially embedded systems with small amounts of CPU power and memory.Plus , all this hype around these Toyota acceleration problems is just that , hype.Its not just software .
This is an embedded system , the software is highly dependent on the hardware involved .
When I say hardware , I mean the entire system of boards , wires , and connectors in the vehicle .
Embedded systems have a tight couple of software and hardware unlike your average computer application .
A slight error in the hardware systems would also send the software in some unknown behavior if not tested correctly/fully .
Its a fairly difficult feat to ensure complete software/hardware compliance in an embedded system .</tokentext>
<sentencetext>Most software is nearly -impossible- to test under flawless conditions.
Especially embedded systems with small amounts of CPU power and memory.Plus, all this hype around these Toyota acceleration problems is just that, hype.Its not just software.
This is an embedded system, the software is highly dependent on the hardware involved.
When I say hardware, I mean the entire system of boards, wires, and connectors in the vehicle.
Embedded systems have a tight couple of software and hardware unlike your average computer application.
A slight error in the hardware systems would also send the software in some unknown behavior if not tested correctly/fully.
Its a fairly difficult feat to ensure complete software/hardware compliance in an embedded system.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464840</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465060</id>
	<title>God damn legal system</title>
	<author>oldhack</author>
	<datestamp>1268506740000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>1</modscore>
	<htmltext>On a side note, our legal system forces us all to lie.</htmltext>
<tokenext>On a side note , our legal system forces us all to lie .</tokentext>
<sentencetext>On a side note, our legal system forces us all to lie.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466134</id>
	<title>Re:Help me benefit from media hype</title>
	<author>snowgirl</author>
	<datestamp>1268471160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p><div class="quote"><p>&gt; And I know how to hit the brakes...</p><p>With the engine past the redline there is very little vacuum to operate the power brakes.  Without power assist the brakes may not be able to overcome the engine (this is, IMHO, a fundamental design defect).</p></div><p>The police officer who helped stop the guy in California remarked on camera that he definitely knew that the brakes were being applied/had been applied enough to heat them up to the point that he could smell them.</p></div>
	</htmltext>
<tokenext>&gt; And I know how to hit the brakes...With the engine past the redline there is very little vacuum to operate the power brakes .
Without power assist the brakes may not be able to overcome the engine ( this is , IMHO , a fundamental design defect ) .The police officer who helped stop the guy in California remarked on camera that he definitely knew that the brakes were being applied/had been applied enough to heat them up to the point that he could smell them .</tokentext>
<sentencetext>&gt; And I know how to hit the brakes...With the engine past the redline there is very little vacuum to operate the power brakes.
Without power assist the brakes may not be able to overcome the engine (this is, IMHO, a fundamental design defect).The police officer who helped stop the guy in California remarked on camera that he definitely knew that the brakes were being applied/had been applied enough to heat them up to the point that he could smell them.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466080</id>
	<title>Fundamental Flaw</title>
	<author>Anonymous</author>
	<datestamp>1268470800000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>The fundamental flaw here, is that if the brake pedal and throttle pedal are both pressed at the same time the ECU isn't not ignoring the input from the throttle pedal.   This I suspect would be expensive for Toyota to fix (otherwise they would have done so already and not tried to "fix" this flaw by carpet mats and throttle "shims".).</p><p>Ford fly-by-wire systems ignore the throttle input when the brake is depressed and Toyota is even changing their systems to match for 2012.   Seems like to me they are dancing around the issue of back-fixing this in older models, most likely due to cost (though one would think it could be done in software but perhaps not and requires changing some part of the engine management system out).</p></htmltext>
<tokenext>The fundamental flaw here , is that if the brake pedal and throttle pedal are both pressed at the same time the ECU is n't not ignoring the input from the throttle pedal .
This I suspect would be expensive for Toyota to fix ( otherwise they would have done so already and not tried to " fix " this flaw by carpet mats and throttle " shims " .
) .Ford fly-by-wire systems ignore the throttle input when the brake is depressed and Toyota is even changing their systems to match for 2012 .
Seems like to me they are dancing around the issue of back-fixing this in older models , most likely due to cost ( though one would think it could be done in software but perhaps not and requires changing some part of the engine management system out ) .</tokentext>
<sentencetext>The fundamental flaw here, is that if the brake pedal and throttle pedal are both pressed at the same time the ECU isn't not ignoring the input from the throttle pedal.
This I suspect would be expensive for Toyota to fix (otherwise they would have done so already and not tried to "fix" this flaw by carpet mats and throttle "shims".
).Ford fly-by-wire systems ignore the throttle input when the brake is depressed and Toyota is even changing their systems to match for 2012.
Seems like to me they are dancing around the issue of back-fixing this in older models, most likely due to cost (though one would think it could be done in software but perhaps not and requires changing some part of the engine management system out).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467644</id>
	<title>Re:Are the brakes totally drive-by-wire as well?</title>
	<author>John Hasler</author>
	<datestamp>1268482260000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>&gt;<nobr> <wbr></nobr>...doesn't the Prius have a mechanical (hydraulic) link to the brakes that<br>&gt; engages when the pedal is pushed down far enough?</p><p>Yes, it does.  The problem is that the vehicles have power brakes which rely on vacuum.  The engine generates no vacuum when the throttle is wide open.  The brakes do work without the power assist but are then too wimpy to overcome the engine.</p></htmltext>
<tokenext>&gt; ...does n't the Prius have a mechanical ( hydraulic ) link to the brakes that &gt; engages when the pedal is pushed down far enough ? Yes , it does .
The problem is that the vehicles have power brakes which rely on vacuum .
The engine generates no vacuum when the throttle is wide open .
The brakes do work without the power assist but are then too wimpy to overcome the engine .</tokentext>
<sentencetext>&gt; ...doesn't the Prius have a mechanical (hydraulic) link to the brakes that&gt; engages when the pedal is pushed down far enough?Yes, it does.
The problem is that the vehicles have power brakes which rely on vacuum.
The engine generates no vacuum when the throttle is wide open.
The brakes do work without the power assist but are then too wimpy to overcome the engine.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466576</id>
	<title>Sometimes difficult bugs require a different view</title>
	<author>GWBasic</author>
	<datestamp>1268474160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In my first internship, I worked with a QA team for a telephony hardware company.  One of the tasks that we <em>started,</em> (and I stress <em>started</em>,) was a "Continuous Hours of Operation" test where we would run tests that were supposed to keep running for weeks or months in order to find bugs.</p><p>The first thing I did, to get comfortable with the APIs and testing hardware, was to write a simple program that picked up the phone, played some music, and then hung up.  After about 5 minutes, my program kept crashing.  Assuming that I was doing something wrong, (because I didn't know the API,) I asked for help.</p><p> <em>It turns out my silly "pick up the phone and play music over and over again" test found a bug that had been eluding major engineers for a few years.</em> </p><p>Perhaps all Toyota needs to do is take some of their simple unit tests and keep running them over and over without rebooting the firmware.  Then they might reproduce the issue within a few days.</p></htmltext>
<tokenext>In my first internship , I worked with a QA team for a telephony hardware company .
One of the tasks that we started , ( and I stress started , ) was a " Continuous Hours of Operation " test where we would run tests that were supposed to keep running for weeks or months in order to find bugs.The first thing I did , to get comfortable with the APIs and testing hardware , was to write a simple program that picked up the phone , played some music , and then hung up .
After about 5 minutes , my program kept crashing .
Assuming that I was doing something wrong , ( because I did n't know the API , ) I asked for help .
It turns out my silly " pick up the phone and play music over and over again " test found a bug that had been eluding major engineers for a few years .
Perhaps all Toyota needs to do is take some of their simple unit tests and keep running them over and over without rebooting the firmware .
Then they might reproduce the issue within a few days .</tokentext>
<sentencetext>In my first internship, I worked with a QA team for a telephony hardware company.
One of the tasks that we started, (and I stress started,) was a "Continuous Hours of Operation" test where we would run tests that were supposed to keep running for weeks or months in order to find bugs.The first thing I did, to get comfortable with the APIs and testing hardware, was to write a simple program that picked up the phone, played some music, and then hung up.
After about 5 minutes, my program kept crashing.
Assuming that I was doing something wrong, (because I didn't know the API,) I asked for help.
It turns out my silly "pick up the phone and play music over and over again" test found a bug that had been eluding major engineers for a few years.
Perhaps all Toyota needs to do is take some of their simple unit tests and keep running them over and over without rebooting the firmware.
Then they might reproduce the issue within a few days.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469656</id>
	<title>So, what evidence is there?</title>
	<author>russotto</author>
	<datestamp>1268500140000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What evidence is there that it is a software bug?  I mean, sure, a lot of us are computer programmers so we know how unreliable the software can be... but a lot can go wrong in mechanical systems as well.  And so far, I haven't seen a bit of evidence which points to a software fault over a mechanical fault.  (and some, like the pedal being physically stuck, which points the other way)</p><p>As for the addition bug found in the Pathfinder... I ran into a similar bug once.  A simple addition was returning the wrong answer, in the middle of a decryption routine, which would then fail.  It was, as was the Pathfinder bug, interrupt related.  But, in this case, it was the CPU itself which would screw up the add (as confirmed by the manufacturer's errata sheet); hardware, not software.  Sure, software's unreliable.  But it's not the only thing which is.</p></htmltext>
<tokenext>What evidence is there that it is a software bug ?
I mean , sure , a lot of us are computer programmers so we know how unreliable the software can be... but a lot can go wrong in mechanical systems as well .
And so far , I have n't seen a bit of evidence which points to a software fault over a mechanical fault .
( and some , like the pedal being physically stuck , which points the other way ) As for the addition bug found in the Pathfinder... I ran into a similar bug once .
A simple addition was returning the wrong answer , in the middle of a decryption routine , which would then fail .
It was , as was the Pathfinder bug , interrupt related .
But , in this case , it was the CPU itself which would screw up the add ( as confirmed by the manufacturer 's errata sheet ) ; hardware , not software .
Sure , software 's unreliable .
But it 's not the only thing which is .</tokentext>
<sentencetext>What evidence is there that it is a software bug?
I mean, sure, a lot of us are computer programmers so we know how unreliable the software can be... but a lot can go wrong in mechanical systems as well.
And so far, I haven't seen a bit of evidence which points to a software fault over a mechanical fault.
(and some, like the pedal being physically stuck, which points the other way)As for the addition bug found in the Pathfinder... I ran into a similar bug once.
A simple addition was returning the wrong answer, in the middle of a decryption routine, which would then fail.
It was, as was the Pathfinder bug, interrupt related.
But, in this case, it was the CPU itself which would screw up the add (as confirmed by the manufacturer's errata sheet); hardware, not software.
Sure, software's unreliable.
But it's not the only thing which is.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466290</id>
	<title>Re:Help me benefit from media hype</title>
	<author>DaTrueDave</author>
	<datestamp>1268472120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>With the engine past the redline there is very little vacuum to operate the power brakes. Without power assist the brakes may not be able to overcome the engine (this is, IMHO, a fundamental design defect).</p></div><p>Are you sure about this?  I've messed around with a lot of different cars and have never had a problem braking while flooring the accelerator.

</p><p>Hmmm, Car and Driver calls BS on this, too:  <a href="http://www.caranddriver.com/features/09q4/how\_to\_deal\_with\_unintended\_acceleration-tech\_dept" title="caranddriver.com" rel="nofollow">http://www.caranddriver.com/features/09q4/how\_to\_deal\_with\_unintended\_acceleration-tech\_dept</a> [caranddriver.com]</p></div>
	</htmltext>
<tokenext>With the engine past the redline there is very little vacuum to operate the power brakes .
Without power assist the brakes may not be able to overcome the engine ( this is , IMHO , a fundamental design defect ) .Are you sure about this ?
I 've messed around with a lot of different cars and have never had a problem braking while flooring the accelerator .
Hmmm , Car and Driver calls BS on this , too : http : //www.caranddriver.com/features/09q4/how \ _to \ _deal \ _with \ _unintended \ _acceleration-tech \ _dept [ caranddriver.com ]</tokentext>
<sentencetext>With the engine past the redline there is very little vacuum to operate the power brakes.
Without power assist the brakes may not be able to overcome the engine (this is, IMHO, a fundamental design defect).Are you sure about this?
I've messed around with a lot of different cars and have never had a problem braking while flooring the accelerator.
Hmmm, Car and Driver calls BS on this, too:  http://www.caranddriver.com/features/09q4/how\_to\_deal\_with\_unintended\_acceleration-tech\_dept [caranddriver.com]
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470684</id>
	<title>Therac-25</title>
	<author>Anonymous</author>
	<datestamp>1268559180000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>http://courses.cs.vt.edu/cs3604/lib/Therac\_25/Therac\_1.html</p></htmltext>
<tokenext>http : //courses.cs.vt.edu/cs3604/lib/Therac \ _25/Therac \ _1.html</tokentext>
<sentencetext>http://courses.cs.vt.edu/cs3604/lib/Therac\_25/Therac\_1.html</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469482</id>
	<title>Mechanical fuel-line kill switch?</title>
	<author>Anonymous</author>
	<datestamp>1268498220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Can't we just put a mechanical fuel-line kill switch somewhere in the car? Like a covered button in the dash panel or glove box? No fuel, no go, right?<br> <br>But anyways, reading from the statistics, there's been some 50 out-of-control Toyotas for how many millions on the road? It sounds like the expense of installing them would not be worth of. But the PR effects or re-assuring the public might make it worth it.</htmltext>
<tokenext>Ca n't we just put a mechanical fuel-line kill switch somewhere in the car ?
Like a covered button in the dash panel or glove box ?
No fuel , no go , right ?
But anyways , reading from the statistics , there 's been some 50 out-of-control Toyotas for how many millions on the road ?
It sounds like the expense of installing them would not be worth of .
But the PR effects or re-assuring the public might make it worth it .</tokentext>
<sentencetext>Can't we just put a mechanical fuel-line kill switch somewhere in the car?
Like a covered button in the dash panel or glove box?
No fuel, no go, right?
But anyways, reading from the statistics, there's been some 50 out-of-control Toyotas for how many millions on the road?
It sounds like the expense of installing them would not be worth of.
But the PR effects or re-assuring the public might make it worth it.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465588</id>
	<title>Re:Impossible to test</title>
	<author>Z00L00K</author>
	<datestamp>1268510640000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>In exceptional conditions I would certainly include what the driver is wearing.</p><p>Synthetic material causing ESD sparks is something that can't be ignored.</p><p>And be aware that the trigger may be in a box that resides on the CAN bus, but is for something completely different. Like power windows or central locking. Cars are so complex these days that you can never be sure what's wrong - and the workshops have been degraded to code readers and component replacers.</p></htmltext>
<tokenext>In exceptional conditions I would certainly include what the driver is wearing.Synthetic material causing ESD sparks is something that ca n't be ignored.And be aware that the trigger may be in a box that resides on the CAN bus , but is for something completely different .
Like power windows or central locking .
Cars are so complex these days that you can never be sure what 's wrong - and the workshops have been degraded to code readers and component replacers .</tokentext>
<sentencetext>In exceptional conditions I would certainly include what the driver is wearing.Synthetic material causing ESD sparks is something that can't be ignored.And be aware that the trigger may be in a box that resides on the CAN bus, but is for something completely different.
Like power windows or central locking.
Cars are so complex these days that you can never be sure what's wrong - and the workshops have been degraded to code readers and component replacers.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464872</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465466</id>
	<title>Re:From the days of "winmodems"</title>
	<author>Anonymous</author>
	<datestamp>1268509740000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Electronic ignition is more reliable than a distributor.  Hence your opinion is false.</p></htmltext>
<tokenext>Electronic ignition is more reliable than a distributor .
Hence your opinion is false .</tokentext>
<sentencetext>Electronic ignition is more reliable than a distributor.
Hence your opinion is false.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465866</id>
	<title>Re:Help me benefit from media hype</title>
	<author>SeaFox</author>
	<datestamp>1268512680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>How about simply having a rule that the throttle run in "idle" position if the brake pedal is depressed regardless of he position of the gas pedal? That way even if the pedal was "stuck down" according to the engine it would ignore it from the driver having their foot planted on the brake trying to slow the car down.</p><p>Is there a real world situation were someone would be pushing the brake pedal down while simultaneously needing the throttle open legitimately?</p></htmltext>
<tokenext>How about simply having a rule that the throttle run in " idle " position if the brake pedal is depressed regardless of he position of the gas pedal ?
That way even if the pedal was " stuck down " according to the engine it would ignore it from the driver having their foot planted on the brake trying to slow the car down.Is there a real world situation were someone would be pushing the brake pedal down while simultaneously needing the throttle open legitimately ?</tokentext>
<sentencetext>How about simply having a rule that the throttle run in "idle" position if the brake pedal is depressed regardless of he position of the gas pedal?
That way even if the pedal was "stuck down" according to the engine it would ignore it from the driver having their foot planted on the brake trying to slow the car down.Is there a real world situation were someone would be pushing the brake pedal down while simultaneously needing the throttle open legitimately?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466542</id>
	<title>Software has already killed people</title>
	<author>Mike\_EE\_U\_of\_I</author>
	<datestamp>1268473860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>The author wrote near the end of his piece  "It is probably only a matter of time before a software error results in injury or death, if it has not happened already (there are some who say it has)."</p><p>
&nbsp; &nbsp; I thought this wasn't even remotely in question.  The Therac 25 radiation overdose killed some people for sure (see <a href="http://en.wikipedia.org/wiki/Therac-25" title="wikipedia.org" rel="nofollow">http://en.wikipedia.org/wiki/Therac-25</a> [wikipedia.org])</p></htmltext>
<tokenext>The author wrote near the end of his piece " It is probably only a matter of time before a software error results in injury or death , if it has not happened already ( there are some who say it has ) .
"     I thought this was n't even remotely in question .
The Therac 25 radiation overdose killed some people for sure ( see http : //en.wikipedia.org/wiki/Therac-25 [ wikipedia.org ] )</tokentext>
<sentencetext>The author wrote near the end of his piece  "It is probably only a matter of time before a software error results in injury or death, if it has not happened already (there are some who say it has).
"
    I thought this wasn't even remotely in question.
The Therac 25 radiation overdose killed some people for sure (see http://en.wikipedia.org/wiki/Therac-25 [wikipedia.org])</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465442</id>
	<title>Anonymous Coward</title>
	<author>Anonymous</author>
	<datestamp>1268509440000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If you cannot point to a bug then, maybe, you should not say there is a bug.  Maybe you can talk Toyota into releasing the code to open source peer review.</p></htmltext>
<tokenext>If you can not point to a bug then , maybe , you should not say there is a bug .
Maybe you can talk Toyota into releasing the code to open source peer review .</tokentext>
<sentencetext>If you cannot point to a bug then, maybe, you should not say there is a bug.
Maybe you can talk Toyota into releasing the code to open source peer review.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465742</id>
	<title>Re:Help me benefit from media hype</title>
	<author>Kohath</author>
	<datestamp>1268511780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I'll buy one of these "defective" cars from you.  Just give me a 50\% discount because of the "defects".</p></htmltext>
<tokenext>I 'll buy one of these " defective " cars from you .
Just give me a 50 \ % discount because of the " defects " .</tokentext>
<sentencetext>I'll buy one of these "defective" cars from you.
Just give me a 50\% discount because of the "defects".</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470000</id>
	<title>Re:Toyota:</title>
	<author>gringer</author>
	<datestamp>1268504760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>More appropriately for Toyota and despair.com: <a href="http://despair.com/toyota.html" title="despair.com">http://despair.com/toyota.html</a> [despair.com]</p><p>Toyota &mdash; once you drive one, you'll never stop.</p></htmltext>
<tokenext>More appropriately for Toyota and despair.com : http : //despair.com/toyota.html [ despair.com ] Toyota    once you drive one , you 'll never stop .</tokentext>
<sentencetext>More appropriately for Toyota and despair.com: http://despair.com/toyota.html [despair.com]Toyota — once you drive one, you'll never stop.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465070</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466020</id>
	<title>Put the throttle cable back.</title>
	<author>Anonymous</author>
	<datestamp>1268513640000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Put the throttle cable back. Why fix something that was not broken to begin with.  With a throttle cable if it broke then the car stopped. How many reports of cars accelerating themselves with a throttle cable have you heard of?</p><p>Sounds like to me a little bit of over engineering something.</p></htmltext>
<tokenext>Put the throttle cable back .
Why fix something that was not broken to begin with .
With a throttle cable if it broke then the car stopped .
How many reports of cars accelerating themselves with a throttle cable have you heard of ? Sounds like to me a little bit of over engineering something .</tokentext>
<sentencetext>Put the throttle cable back.
Why fix something that was not broken to begin with.
With a throttle cable if it broke then the car stopped.
How many reports of cars accelerating themselves with a throttle cable have you heard of?Sounds like to me a little bit of over engineering something.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469638</id>
	<title>Re:Toyota:</title>
	<author>IsNoGood</author>
	<datestamp>1268499960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Main Problem that all looks to ignore is that Toyota is using a ECU that is close sources and have never given anybody the rights to read it,

In US and EUR most ECU use the J1939 protocol that well documented and supported,

I believe if Toyota opend its ECU's we find the issues and it will help guys like me.</htmltext>
<tokenext>Main Problem that all looks to ignore is that Toyota is using a ECU that is close sources and have never given anybody the rights to read it , In US and EUR most ECU use the J1939 protocol that well documented and supported , I believe if Toyota opend its ECU 's we find the issues and it will help guys like me .</tokentext>
<sentencetext>Main Problem that all looks to ignore is that Toyota is using a ECU that is close sources and have never given anybody the rights to read it,

In US and EUR most ECU use the J1939 protocol that well documented and supported,

I believe if Toyota opend its ECU's we find the issues and it will help guys like me.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31471658</id>
	<title>Songs in the key of *DUH*</title>
	<author>wwphx</author>
	<datestamp>1268575860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I've been contending for ages that car makers, now that they're essentially doing fly-by-wire, need to hire aviation engineers to make their systems triple-redundant.  A car may not be "fall out of the sky if the computer fails", but slamming in to a bridge abutment at 90 MPH is just as deadly to the driver.
<br> <br>
I had a 2000ish Isuzu Rodeo.  It had drive-by-wire throttle.  One day the Get Serviced Now light came on and the acceleration dropped to a pitiful number.  It ran fine, still had good top speed, just no acceleration.  Took it to the dealer and found out that the throttle sensor went bad, and if the computer did what it was told by the sensor, it would have trashed the tranny.  So the computer locked the tranny in to 3rd gear and told me to hie me hence to a dealer.  This is the sort of failure path that this sort of electronic control system needs.</htmltext>
<tokenext>I 've been contending for ages that car makers , now that they 're essentially doing fly-by-wire , need to hire aviation engineers to make their systems triple-redundant .
A car may not be " fall out of the sky if the computer fails " , but slamming in to a bridge abutment at 90 MPH is just as deadly to the driver .
I had a 2000ish Isuzu Rodeo .
It had drive-by-wire throttle .
One day the Get Serviced Now light came on and the acceleration dropped to a pitiful number .
It ran fine , still had good top speed , just no acceleration .
Took it to the dealer and found out that the throttle sensor went bad , and if the computer did what it was told by the sensor , it would have trashed the tranny .
So the computer locked the tranny in to 3rd gear and told me to hie me hence to a dealer .
This is the sort of failure path that this sort of electronic control system needs .</tokentext>
<sentencetext>I've been contending for ages that car makers, now that they're essentially doing fly-by-wire, need to hire aviation engineers to make their systems triple-redundant.
A car may not be "fall out of the sky if the computer fails", but slamming in to a bridge abutment at 90 MPH is just as deadly to the driver.
I had a 2000ish Isuzu Rodeo.
It had drive-by-wire throttle.
One day the Get Serviced Now light came on and the acceleration dropped to a pitiful number.
It ran fine, still had good top speed, just no acceleration.
Took it to the dealer and found out that the throttle sensor went bad, and if the computer did what it was told by the sensor, it would have trashed the tranny.
So the computer locked the tranny in to 3rd gear and told me to hie me hence to a dealer.
This is the sort of failure path that this sort of electronic control system needs.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467806</id>
	<title>Re:Toyota:</title>
	<author>Junior J. Junior III</author>
	<datestamp>1268483520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I Can't Stop Driving My Toyota!</p></htmltext>
<tokenext>I Ca n't Stop Driving My Toyota !</tokentext>
<sentencetext>I Can't Stop Driving My Toyota!</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467200</id>
	<title>/dev/console</title>
	<author>KB3NZQ</author>
	<datestamp>1268479080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>/dev/console
read each line of code as it is getting executed and isolate the line that causes the sudden acceleration</htmltext>
<tokenext>/dev/console read each line of code as it is getting executed and isolate the line that causes the sudden acceleration</tokentext>
<sentencetext>/dev/console
read each line of code as it is getting executed and isolate the line that causes the sudden acceleration</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465726</id>
	<title>Star Trekking</title>
	<author>Anonymous</author>
	<datestamp>1268511660000</datestamp>
	<modclass>Funny</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>Always going forward.</p></div></blockquote><p>... because we can't find reverse.</p></div>
	</htmltext>
<tokenext>Always going forward.... because we ca n't find reverse .</tokentext>
<sentencetext>Always going forward.... because we can't find reverse.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465158</id>
	<title>Re:Toyota:</title>
	<author>Anonymous</author>
	<datestamp>1268507280000</datestamp>
	<modclass>Troll</modclass>
	<modscore>-1</modscore>
	<htmltext><p>At least 3 mod points will be wasted on this post.</p><p>Dumbasses.</p></htmltext>
<tokenext>At least 3 mod points will be wasted on this post.Dumbasses .</tokentext>
<sentencetext>At least 3 mod points will be wasted on this post.Dumbasses.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465148</id>
	<title>fault without fault warning in computer?</title>
	<author>cenobyte40k</author>
	<datestamp>1268507220000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Is it just me or did everyone else miss the one where a guy introduced a fault into the Toyota system that caused sudden acceleration without producing an error code? I admit he had to introduce the fault artificially but if you can do that and have no fault come up on the computer how can you say that your system works 100\% of the time?</htmltext>
<tokenext>Is it just me or did everyone else miss the one where a guy introduced a fault into the Toyota system that caused sudden acceleration without producing an error code ?
I admit he had to introduce the fault artificially but if you can do that and have no fault come up on the computer how can you say that your system works 100 \ % of the time ?</tokentext>
<sentencetext>Is it just me or did everyone else miss the one where a guy introduced a fault into the Toyota system that caused sudden acceleration without producing an error code?
I admit he had to introduce the fault artificially but if you can do that and have no fault come up on the computer how can you say that your system works 100\% of the time?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467536</id>
	<title>I found the problem</title>
	<author>wallyh</author>
	<datestamp>1268481660000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>I found the problem.  Seems to be some bad code in the cruise control module:

DateTime randomTime = Random(time);
if (randomTime  currentTime &amp;&amp; carDriver == "ugly american")
{
	speed = 160;
	while (true)
	{
		if (carDriver.presses(break))
		{
			speed += 5;
		}
	}
}</htmltext>
<tokenext>I found the problem .
Seems to be some bad code in the cruise control module : DateTime randomTime = Random ( time ) ; if ( randomTime currentTime &amp;&amp; carDriver = = " ugly american " ) { speed = 160 ; while ( true ) { if ( carDriver.presses ( break ) ) { speed + = 5 ; } } }</tokentext>
<sentencetext>I found the problem.
Seems to be some bad code in the cruise control module:

DateTime randomTime = Random(time);
if (randomTime  currentTime &amp;&amp; carDriver == "ugly american")
{
	speed = 160;
	while (true)
	{
		if (carDriver.presses(break))
		{
			speed += 5;
		}
	}
}</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467618</id>
	<title>Re:Speaking as an embedded programmer here...</title>
	<author>Mateorabi</author>
	<datestamp>1268482080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It's still the software's fault then.  It should take these failure modes into account and react in a safe manner when people's lives are on the line.  (Granted you can always come up with some wacky way <i>everything</i> could go wrong simultaneously, but a safe design will make that immensely improbable.)</htmltext>
<tokenext>It 's still the software 's fault then .
It should take these failure modes into account and react in a safe manner when people 's lives are on the line .
( Granted you can always come up with some wacky way everything could go wrong simultaneously , but a safe design will make that immensely improbable .
)</tokentext>
<sentencetext>It's still the software's fault then.
It should take these failure modes into account and react in a safe manner when people's lives are on the line.
(Granted you can always come up with some wacky way everything could go wrong simultaneously, but a safe design will make that immensely improbable.
)</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564</id>
	<title>Speaking as an embedded programmer here...</title>
	<author>Anonymous</author>
	<datestamp>1268510400000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>3</modscore>
	<htmltext><p>... why does everyone assume it is a software bug?  I agree that it very well could be an undiscovered software bug.  But there are so many more sources of erroneous behavior in an embedded system that *even* *if* the software were flawless (ummm... just go with me a minute...<nobr> <wbr></nobr>:) an automotive environment can cause all manner of strange glitches.  I work with robots, lots of DC motors causing commutation noise on the power supply, long (several inch) distances between units that must talk to each other and therefore may have a different opinion as to ground reference voltage... many things can get wacky.  Even flawless code needs a watchdog timer to get you out of weird states that power glitches that put you into.  Power supply spikes can cause the program counter to jump to very odd places, with odd, corrupted stuff in RAM. Ground level shifting can cause communication glitches. CAN bus is *extremely* robust, so bad data should not get through... but what does get through? Does the system as a whole get into a weird state if packets drop?</p></htmltext>
<tokenext>... why does everyone assume it is a software bug ?
I agree that it very well could be an undiscovered software bug .
But there are so many more sources of erroneous behavior in an embedded system that * even * * if * the software were flawless ( ummm... just go with me a minute... : ) an automotive environment can cause all manner of strange glitches .
I work with robots , lots of DC motors causing commutation noise on the power supply , long ( several inch ) distances between units that must talk to each other and therefore may have a different opinion as to ground reference voltage... many things can get wacky .
Even flawless code needs a watchdog timer to get you out of weird states that power glitches that put you into .
Power supply spikes can cause the program counter to jump to very odd places , with odd , corrupted stuff in RAM .
Ground level shifting can cause communication glitches .
CAN bus is * extremely * robust , so bad data should not get through... but what does get through ?
Does the system as a whole get into a weird state if packets drop ?</tokentext>
<sentencetext>... why does everyone assume it is a software bug?
I agree that it very well could be an undiscovered software bug.
But there are so many more sources of erroneous behavior in an embedded system that *even* *if* the software were flawless (ummm... just go with me a minute... :) an automotive environment can cause all manner of strange glitches.
I work with robots, lots of DC motors causing commutation noise on the power supply, long (several inch) distances between units that must talk to each other and therefore may have a different opinion as to ground reference voltage... many things can get wacky.
Even flawless code needs a watchdog timer to get you out of weird states that power glitches that put you into.
Power supply spikes can cause the program counter to jump to very odd places, with odd, corrupted stuff in RAM.
Ground level shifting can cause communication glitches.
CAN bus is *extremely* robust, so bad data should not get through... but what does get through?
Does the system as a whole get into a weird state if packets drop?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464924</id>
	<title>Exactly</title>
	<author>Reality Master 101</author>
	<datestamp>1268505600000</datestamp>
	<modclass>Offtopic</modclass>
	<modscore>-1</modscore>
	<htmltext><p>I have to say, it's this specific reason that makes me wary of anthropogenic climate change. A lot of the evidence is based on computer models, and anyone who has programmed computers knows how difficult it is to get anything computer related right. The most shocking thing about "climategate" to me wasn't the content of the emails, it was the fact that the computer models used were NOT openly available to all, and were not published with the research papers. And when you combine that with the insane complexity of the climate and the limitations of our computers, I can't help but feel that computer models are a blunt, crude tool at best, and at worst a tool of misinformation (even if the wielders have "good intentions").</p><p>I'm willing to accept that human activity is causing significant climate change, but don't use computer models to prove it to me. By all means, use computer models to gather clues about what to test. But computer models are manufactured evidence that can be made to say anything. Anyone using computer models to argue that seismic shifts in human culture are needed should be taken out and flogged until their real agenda is admitted. No one with any clue about computers would argue that they are infallible oracles of truth (or even infallible controllers of accelerator pedals).</p></htmltext>
<tokenext>I have to say , it 's this specific reason that makes me wary of anthropogenic climate change .
A lot of the evidence is based on computer models , and anyone who has programmed computers knows how difficult it is to get anything computer related right .
The most shocking thing about " climategate " to me was n't the content of the emails , it was the fact that the computer models used were NOT openly available to all , and were not published with the research papers .
And when you combine that with the insane complexity of the climate and the limitations of our computers , I ca n't help but feel that computer models are a blunt , crude tool at best , and at worst a tool of misinformation ( even if the wielders have " good intentions " ) .I 'm willing to accept that human activity is causing significant climate change , but do n't use computer models to prove it to me .
By all means , use computer models to gather clues about what to test .
But computer models are manufactured evidence that can be made to say anything .
Anyone using computer models to argue that seismic shifts in human culture are needed should be taken out and flogged until their real agenda is admitted .
No one with any clue about computers would argue that they are infallible oracles of truth ( or even infallible controllers of accelerator pedals ) .</tokentext>
<sentencetext>I have to say, it's this specific reason that makes me wary of anthropogenic climate change.
A lot of the evidence is based on computer models, and anyone who has programmed computers knows how difficult it is to get anything computer related right.
The most shocking thing about "climategate" to me wasn't the content of the emails, it was the fact that the computer models used were NOT openly available to all, and were not published with the research papers.
And when you combine that with the insane complexity of the climate and the limitations of our computers, I can't help but feel that computer models are a blunt, crude tool at best, and at worst a tool of misinformation (even if the wielders have "good intentions").I'm willing to accept that human activity is causing significant climate change, but don't use computer models to prove it to me.
By all means, use computer models to gather clues about what to test.
But computer models are manufactured evidence that can be made to say anything.
Anyone using computer models to argue that seismic shifts in human culture are needed should be taken out and flogged until their real agenda is admitted.
No one with any clue about computers would argue that they are infallible oracles of truth (or even infallible controllers of accelerator pedals).</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466930</id>
	<title>One Line of Code</title>
	<author>markbark</author>
	<datestamp>1268476980000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Is it just me or could this be corrected with one line of code?</p><p>if brake\_input &gt; 0 then accelerator\_output=0</p></htmltext>
<tokenext>Is it just me or could this be corrected with one line of code ? if brake \ _input &gt; 0 then accelerator \ _output = 0</tokentext>
<sentencetext>Is it just me or could this be corrected with one line of code?if brake\_input &gt; 0 then accelerator\_output=0</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31471236</id>
	<title>NASA's production advice</title>
	<author>OldJuke</author>
	<datestamp>1268568960000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Let's all follow NASA's design methods. The 2011 model cars will be available sometime after the year 2050, that is if the project isn't scrapped around 2040.</htmltext>
<tokenext>Let 's all follow NASA 's design methods .
The 2011 model cars will be available sometime after the year 2050 , that is if the project is n't scrapped around 2040 .</tokentext>
<sentencetext>Let's all follow NASA's design methods.
The 2011 model cars will be available sometime after the year 2050, that is if the project isn't scrapped around 2040.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465464</id>
	<title>Modern software vs. old bit-bumming</title>
	<author>isdnip</author>
	<datestamp>1268509680000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>What does the Toyota source code look like?</p><p>Back in the 1960s, when the space capsules were being designed, 16k words was a lot.  So programmers wrote tight code, optimized down to every instruction.  It wasn't perfect but it was fairly easy to examine.</p><p>Nowadays memory is cheap.  And we have programming techniques that take advantage of it.  Object-oriented code, for instance.  This speeds up some kinds of programming but it puts more effective distance between the source code and the executable.  And the mere act of using an OS API, as noted in the original story, makes the application vulnerable to subtle bugs in the OS.</p><p>It's laughable that Toyota could have thoroughly debugged code that was written using modern, large-memory techniques.</p><p>Still, it's unfair to single out Toyota.  There's too much drive-by-wire in a lot of cars.</p></htmltext>
<tokenext>What does the Toyota source code look like ? Back in the 1960s , when the space capsules were being designed , 16k words was a lot .
So programmers wrote tight code , optimized down to every instruction .
It was n't perfect but it was fairly easy to examine.Nowadays memory is cheap .
And we have programming techniques that take advantage of it .
Object-oriented code , for instance .
This speeds up some kinds of programming but it puts more effective distance between the source code and the executable .
And the mere act of using an OS API , as noted in the original story , makes the application vulnerable to subtle bugs in the OS.It 's laughable that Toyota could have thoroughly debugged code that was written using modern , large-memory techniques.Still , it 's unfair to single out Toyota .
There 's too much drive-by-wire in a lot of cars .</tokentext>
<sentencetext>What does the Toyota source code look like?Back in the 1960s, when the space capsules were being designed, 16k words was a lot.
So programmers wrote tight code, optimized down to every instruction.
It wasn't perfect but it was fairly easy to examine.Nowadays memory is cheap.
And we have programming techniques that take advantage of it.
Object-oriented code, for instance.
This speeds up some kinds of programming but it puts more effective distance between the source code and the executable.
And the mere act of using an OS API, as noted in the original story, makes the application vulnerable to subtle bugs in the OS.It's laughable that Toyota could have thoroughly debugged code that was written using modern, large-memory techniques.Still, it's unfair to single out Toyota.
There's too much drive-by-wire in a lot of cars.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467936</id>
	<title>Re:Impossible to test</title>
	<author>Anonymous</author>
	<datestamp>1268484600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>If it seems impossible to test, the only way is to read the code very carefully and run things in your mind. I actually solved quite a few bugs this way in my code with a sophisticated threading model.</p></htmltext>
<tokenext>If it seems impossible to test , the only way is to read the code very carefully and run things in your mind .
I actually solved quite a few bugs this way in my code with a sophisticated threading model .</tokentext>
<sentencetext>If it seems impossible to test, the only way is to read the code very carefully and run things in your mind.
I actually solved quite a few bugs this way in my code with a sophisticated threading model.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464872</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465774</id>
	<title>Re:Are the brakes totally drive-by-wire as well?</title>
	<author>flyingfsck</author>
	<datestamp>1268512080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Yup, and the parking brake is a cable system to the rear wheels.</htmltext>
<tokenext>Yup , and the parking brake is a cable system to the rear wheels .</tokentext>
<sentencetext>Yup, and the parking brake is a cable system to the rear wheels.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465586</id>
	<title>Re:Help me benefit from media hype</title>
	<author>Black Gold Alchemist</author>
	<datestamp>1268510580000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Make sure you test drive one. My family went car shopping recently (we have two pre-1990 Toyota Camrys). The problem with the Toyotas is that their new styling is just awful, because the windows are really small. I could not see out of the Corollas and Camrys we sat in (kind of a problem for driving). The dashboard is too tall, the roof too low, and the hood too long. IMO, the new styling is just ugly. Toyota ain't what it use to be. The result of our car shopping expedition was that Hyundai was the winner.<br> <br>

They might be fine for you, but make sure you test drive (or at least sit in one), before you buy.</htmltext>
<tokenext>Make sure you test drive one .
My family went car shopping recently ( we have two pre-1990 Toyota Camrys ) .
The problem with the Toyotas is that their new styling is just awful , because the windows are really small .
I could not see out of the Corollas and Camrys we sat in ( kind of a problem for driving ) .
The dashboard is too tall , the roof too low , and the hood too long .
IMO , the new styling is just ugly .
Toyota ai n't what it use to be .
The result of our car shopping expedition was that Hyundai was the winner .
They might be fine for you , but make sure you test drive ( or at least sit in one ) , before you buy .</tokentext>
<sentencetext>Make sure you test drive one.
My family went car shopping recently (we have two pre-1990 Toyota Camrys).
The problem with the Toyotas is that their new styling is just awful, because the windows are really small.
I could not see out of the Corollas and Camrys we sat in (kind of a problem for driving).
The dashboard is too tall, the roof too low, and the hood too long.
IMO, the new styling is just ugly.
Toyota ain't what it use to be.
The result of our car shopping expedition was that Hyundai was the winner.
They might be fine for you, but make sure you test drive (or at least sit in one), before you buy.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466564</id>
	<title>PR strategy != engineering reality</title>
	<author>presidenteloco</author>
	<datestamp>1268474040000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Whether Toyota should be straightforward with customers about the level of uncertainty<br>or adopt a blustering strategy, kind of depends on how comfortable people (the customers<br>or potential customers) are with uncertainty existing in science and engineering.</p><p>Scientists and engineers are comfortable (some of us) with existing in a world where<br>there is a<nobr> <wbr></nobr>.83 probability of this, and a<nobr> <wbr></nobr>.012 probability of that, and we expect as a matter<br>of course that our theory might have to be revised as more observations come in.</p><p>But I had the experience of working for a non-techie executive, and when he asked how<br>things were going, or I proactively informed him about some issue in the development<br>project, he invariably had the same reaction, no matter whether I was reporting a minor<br>problem (one in a sequence of hundreds of obstacles the engineer has to discover and<br>work around as they go - i.e. a routine temporary unknown or a routine new problem at<br>the forefront of the innovation), or a potential show-stopper.</p><p>Regardless of which of these it was, and I was always careful to put these problem<br>reports/issue reports in perspective when reporting them, it was always:</p><p>"Oh MY GOD!!! We need to shut down this project / subproject<nobr> <wbr></nobr>/workpackage / feature<br>development RIGHT NOW! There is a PROBLEM! We can't afford PROBLEMS!! They<br>are too SCARY!! I don't know what's around the corner! We must backtrack and go another<br>route altogether!!!!</p><p>So eventually I stopped reporting problems/issues to my management, and just went<br>about with the other techies fixing/working around each one. And if asked how it was<br>going, I would resort to impenetrable but vaguely positive generalities. Why?</p><p>So we could get some work done. So that management by irrational fear and lack of<br>insight and perspective would not GUARANTEED ruin the project.</p><p>How dysfunctional is that.</p><p>I imagine Toyota, and its relationship with the general public, is kind of like that.<br>They may be damned for blustering, but they damn sure would be crucified<br>for telling the truth about the level of engineering uncertainties in any developed<br>complex system.</p><p>To get the downlow, you have to be equipped to handle it rationally.</p></htmltext>
<tokenext>Whether Toyota should be straightforward with customers about the level of uncertaintyor adopt a blustering strategy , kind of depends on how comfortable people ( the customersor potential customers ) are with uncertainty existing in science and engineering.Scientists and engineers are comfortable ( some of us ) with existing in a world wherethere is a .83 probability of this , and a .012 probability of that , and we expect as a matterof course that our theory might have to be revised as more observations come in.But I had the experience of working for a non-techie executive , and when he asked howthings were going , or I proactively informed him about some issue in the developmentproject , he invariably had the same reaction , no matter whether I was reporting a minorproblem ( one in a sequence of hundreds of obstacles the engineer has to discover andwork around as they go - i.e .
a routine temporary unknown or a routine new problem atthe forefront of the innovation ) , or a potential show-stopper.Regardless of which of these it was , and I was always careful to put these problemreports/issue reports in perspective when reporting them , it was always : " Oh MY GOD ! ! !
We need to shut down this project / subproject /workpackage / featuredevelopment RIGHT NOW !
There is a PROBLEM !
We ca n't afford PROBLEMS ! !
Theyare too SCARY ! !
I do n't know what 's around the corner !
We must backtrack and go anotherroute altogether ! ! !
! So eventually I stopped reporting problems/issues to my management , and just wentabout with the other techies fixing/working around each one .
And if asked how it wasgoing , I would resort to impenetrable but vaguely positive generalities .
Why ? So we could get some work done .
So that management by irrational fear and lack ofinsight and perspective would not GUARANTEED ruin the project.How dysfunctional is that.I imagine Toyota , and its relationship with the general public , is kind of like that.They may be damned for blustering , but they damn sure would be crucifiedfor telling the truth about the level of engineering uncertainties in any developedcomplex system.To get the downlow , you have to be equipped to handle it rationally .</tokentext>
<sentencetext>Whether Toyota should be straightforward with customers about the level of uncertaintyor adopt a blustering strategy, kind of depends on how comfortable people (the customersor potential customers) are with uncertainty existing in science and engineering.Scientists and engineers are comfortable (some of us) with existing in a world wherethere is a .83 probability of this, and a .012 probability of that, and we expect as a matterof course that our theory might have to be revised as more observations come in.But I had the experience of working for a non-techie executive, and when he asked howthings were going, or I proactively informed him about some issue in the developmentproject, he invariably had the same reaction, no matter whether I was reporting a minorproblem (one in a sequence of hundreds of obstacles the engineer has to discover andwork around as they go - i.e.
a routine temporary unknown or a routine new problem atthe forefront of the innovation), or a potential show-stopper.Regardless of which of these it was, and I was always careful to put these problemreports/issue reports in perspective when reporting them, it was always:"Oh MY GOD!!!
We need to shut down this project / subproject /workpackage / featuredevelopment RIGHT NOW!
There is a PROBLEM!
We can't afford PROBLEMS!!
Theyare too SCARY!!
I don't know what's around the corner!
We must backtrack and go anotherroute altogether!!!
!So eventually I stopped reporting problems/issues to my management, and just wentabout with the other techies fixing/working around each one.
And if asked how it wasgoing, I would resort to impenetrable but vaguely positive generalities.
Why?So we could get some work done.
So that management by irrational fear and lack ofinsight and perspective would not GUARANTEED ruin the project.How dysfunctional is that.I imagine Toyota, and its relationship with the general public, is kind of like that.They may be damned for blustering, but they damn sure would be crucifiedfor telling the truth about the level of engineering uncertainties in any developedcomplex system.To get the downlow, you have to be equipped to handle it rationally.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469448</id>
	<title>Re:A Most Unusual Bug Indeed</title>
	<author>Anonymous</author>
	<datestamp>1268497860000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Elderly people are less likely to be strong enough to stomp a non-power-assisted brake hard enough to fight off a runaway engine, less likely to have fast enough reflexes to maintain control of a runaway car, and more likely to die in the resulting crash.</p></htmltext>
<tokenext>Elderly people are less likely to be strong enough to stomp a non-power-assisted brake hard enough to fight off a runaway engine , less likely to have fast enough reflexes to maintain control of a runaway car , and more likely to die in the resulting crash .</tokentext>
<sentencetext>Elderly people are less likely to be strong enough to stomp a non-power-assisted brake hard enough to fight off a runaway engine, less likely to have fast enough reflexes to maintain control of a runaway car, and more likely to die in the resulting crash.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466956</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465132</id>
	<title>Mechanical or Siftware bug</title>
	<author>hufter</author>
	<datestamp>1268507160000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>This is what I've seen in the news: Toyota says there is a mechanical fault in the accelerator pedal, that may cause it to get physically stuck down. This is extremely rare, but possible. To fix it, they add a little extra piece to the pedal. Sound like a duct-tape solution, but if it works, then okay.
<br>
Did Toyota lie to us, and actually added a patch to the software instead?</htmltext>
<tokenext>This is what I 've seen in the news : Toyota says there is a mechanical fault in the accelerator pedal , that may cause it to get physically stuck down .
This is extremely rare , but possible .
To fix it , they add a little extra piece to the pedal .
Sound like a duct-tape solution , but if it works , then okay .
Did Toyota lie to us , and actually added a patch to the software instead ?</tokentext>
<sentencetext>This is what I've seen in the news: Toyota says there is a mechanical fault in the accelerator pedal, that may cause it to get physically stuck down.
This is extremely rare, but possible.
To fix it, they add a little extra piece to the pedal.
Sound like a duct-tape solution, but if it works, then okay.
Did Toyota lie to us, and actually added a patch to the software instead?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470360</id>
	<title>Re:Help me benefit from media hype</title>
	<author>kasparov</author>
	<datestamp>1268509800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><blockquote><div><p>The computer may not let you do that with the car moving and the engine at high rpm. After all, the engine and/or transmission might be damaged (another design defect).</p></div></blockquote><p>
This is just completely wrong. I drive a 2007 Toyota Prius and I tested it the other day by flooring it and then shifting into neutral. Worked like a champ. The Prius transmission <a href="http://prius.ecrostech.com/original/Understanding/ContinuouslyVariableTransmission.htm" title="ecrostech.com">doesn't have discrete gears</a> [ecrostech.com]. Shifting into neutral will not harm the transmission. Also keep in mind that the engine routinely shuts off and on and that cutting electric power to the drive is also quite simple. I did have to hold the shifter in the neutral position for about a second to get it to do the shift--I assume because they want to make sure the joystick-like shifter wasn't accidentally bumped into the wrong position.</p></div>
	</htmltext>
<tokenext>The computer may not let you do that with the car moving and the engine at high rpm .
After all , the engine and/or transmission might be damaged ( another design defect ) .
This is just completely wrong .
I drive a 2007 Toyota Prius and I tested it the other day by flooring it and then shifting into neutral .
Worked like a champ .
The Prius transmission does n't have discrete gears [ ecrostech.com ] .
Shifting into neutral will not harm the transmission .
Also keep in mind that the engine routinely shuts off and on and that cutting electric power to the drive is also quite simple .
I did have to hold the shifter in the neutral position for about a second to get it to do the shift--I assume because they want to make sure the joystick-like shifter was n't accidentally bumped into the wrong position .</tokentext>
<sentencetext>The computer may not let you do that with the car moving and the engine at high rpm.
After all, the engine and/or transmission might be damaged (another design defect).
This is just completely wrong.
I drive a 2007 Toyota Prius and I tested it the other day by flooring it and then shifting into neutral.
Worked like a champ.
The Prius transmission doesn't have discrete gears [ecrostech.com].
Shifting into neutral will not harm the transmission.
Also keep in mind that the engine routinely shuts off and on and that cutting electric power to the drive is also quite simple.
I did have to hold the shifter in the neutral position for about a second to get it to do the shift--I assume because they want to make sure the joystick-like shifter wasn't accidentally bumped into the wrong position.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31471442</id>
	<title>Shades of Gray</title>
	<author>JohnReid</author>
	<datestamp>1268572860000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>When control system problems are viewed as either hardware or software in nature then the source of the problem can be very difficult to isolate. Instead, the systems a whole needs to be looked at objectively as to what could be the source of the problem.
<p>
So far all I've heard is probes into stuck gas pedals and software review. Of course, if the problem is not a stuck gas pedal then the assumption is the hardware is fine. If the software is tested thoroughly, then it too must be fine and the problem doesn't exist. Yet, something is happening.
</p><p>
Having been involved in the hardware and software investigation of very intermittent problems, it's not surprising to see these discussions. This happens when the vendor doesn't really want to find the problem, but rather put the blame elsewhere.
</p><p>
There are other sources of problems, and they can be difficult to replicate and even harder to fix. The two most common areas I've experienced have been timing and interference. Timing issues can be anything from handling of interrupts out of sync with clocks or other code. Interference can affect sensors or logic levels from external RF energy, electrostatic discharge, or noise from in-circuit inverters. Interference is the toughest because the source that happens in the field doesn't always exist in the lab.
</p><p>
The possibility of interference as a source of the problem is also a hard pill to swallow for some engineers because they tend to trust shielding  that is either insufficient or not properly installed, thus making it more of an antenna and transformer of energy rather than protecting the equipment from that energy. Elimination of the source of the energy at the hardware is one method of solving the problem, but it doesn't hurt to have the proper software rules in place to insure that exception conditions are handled properly (for instance, you shouldn't need to press the brake and accelerator to force the vehicle to slow down. When the assumption is the accelerator is stuck and you only try to press the brake, nothing happens because the accelerator isn't actually stuck... duh).
</p><p>
Instead of testing such narrow parameters for the situation to appease Congress, Federal officials, and Toyota Management, a broader scope should be done. The quickest way would be by Toyota engineers who have knowledge and access tot he internals, but if they cannot be open minded about it then a third party with full access to the designs might be in order.</p></htmltext>
<tokenext>When control system problems are viewed as either hardware or software in nature then the source of the problem can be very difficult to isolate .
Instead , the systems a whole needs to be looked at objectively as to what could be the source of the problem .
So far all I 've heard is probes into stuck gas pedals and software review .
Of course , if the problem is not a stuck gas pedal then the assumption is the hardware is fine .
If the software is tested thoroughly , then it too must be fine and the problem does n't exist .
Yet , something is happening .
Having been involved in the hardware and software investigation of very intermittent problems , it 's not surprising to see these discussions .
This happens when the vendor does n't really want to find the problem , but rather put the blame elsewhere .
There are other sources of problems , and they can be difficult to replicate and even harder to fix .
The two most common areas I 've experienced have been timing and interference .
Timing issues can be anything from handling of interrupts out of sync with clocks or other code .
Interference can affect sensors or logic levels from external RF energy , electrostatic discharge , or noise from in-circuit inverters .
Interference is the toughest because the source that happens in the field does n't always exist in the lab .
The possibility of interference as a source of the problem is also a hard pill to swallow for some engineers because they tend to trust shielding that is either insufficient or not properly installed , thus making it more of an antenna and transformer of energy rather than protecting the equipment from that energy .
Elimination of the source of the energy at the hardware is one method of solving the problem , but it does n't hurt to have the proper software rules in place to insure that exception conditions are handled properly ( for instance , you should n't need to press the brake and accelerator to force the vehicle to slow down .
When the assumption is the accelerator is stuck and you only try to press the brake , nothing happens because the accelerator is n't actually stuck... duh ) . Instead of testing such narrow parameters for the situation to appease Congress , Federal officials , and Toyota Management , a broader scope should be done .
The quickest way would be by Toyota engineers who have knowledge and access tot he internals , but if they can not be open minded about it then a third party with full access to the designs might be in order .</tokentext>
<sentencetext>When control system problems are viewed as either hardware or software in nature then the source of the problem can be very difficult to isolate.
Instead, the systems a whole needs to be looked at objectively as to what could be the source of the problem.
So far all I've heard is probes into stuck gas pedals and software review.
Of course, if the problem is not a stuck gas pedal then the assumption is the hardware is fine.
If the software is tested thoroughly, then it too must be fine and the problem doesn't exist.
Yet, something is happening.
Having been involved in the hardware and software investigation of very intermittent problems, it's not surprising to see these discussions.
This happens when the vendor doesn't really want to find the problem, but rather put the blame elsewhere.
There are other sources of problems, and they can be difficult to replicate and even harder to fix.
The two most common areas I've experienced have been timing and interference.
Timing issues can be anything from handling of interrupts out of sync with clocks or other code.
Interference can affect sensors or logic levels from external RF energy, electrostatic discharge, or noise from in-circuit inverters.
Interference is the toughest because the source that happens in the field doesn't always exist in the lab.
The possibility of interference as a source of the problem is also a hard pill to swallow for some engineers because they tend to trust shielding  that is either insufficient or not properly installed, thus making it more of an antenna and transformer of energy rather than protecting the equipment from that energy.
Elimination of the source of the energy at the hardware is one method of solving the problem, but it doesn't hurt to have the proper software rules in place to insure that exception conditions are handled properly (for instance, you shouldn't need to press the brake and accelerator to force the vehicle to slow down.
When the assumption is the accelerator is stuck and you only try to press the brake, nothing happens because the accelerator isn't actually stuck... duh).

Instead of testing such narrow parameters for the situation to appease Congress, Federal officials, and Toyota Management, a broader scope should be done.
The quickest way would be by Toyota engineers who have knowledge and access tot he internals, but if they cannot be open minded about it then a third party with full access to the designs might be in order.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465054</id>
	<title>Re:Toyota:</title>
	<author>Anonymous</author>
	<datestamp>1268506620000</datestamp>
	<modclass>Flamebait</modclass>
	<modscore>-1</modscore>
	<htmltext><p><div class="quote"><p>Always going forward.</p></div><p>Niggers:  always going backward.**
<br> <br> <br>
**Unless high crime rates and high rates of illegitimate children are your idea of "progress".</p></div>
	</htmltext>
<tokenext>Always going forward.Niggers : always going backward .
* * * * Unless high crime rates and high rates of illegitimate children are your idea of " progress " .</tokentext>
<sentencetext>Always going forward.Niggers:  always going backward.
**
  
**Unless high crime rates and high rates of illegitimate children are your idea of "progress".
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465530</id>
	<title>Humble pie.</title>
	<author>Anonymous</author>
	<datestamp>1268510160000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>There is one efficient and reliable machine out there: The paper weight.<br>There is one bug-free software out there: int main( void ){ return 0;}</p><p>Where's the manual override for that accelerator?</p></htmltext>
<tokenext>There is one efficient and reliable machine out there : The paper weight.There is one bug-free software out there : int main ( void ) { return 0 ; } Where 's the manual override for that accelerator ?</tokentext>
<sentencetext>There is one efficient and reliable machine out there: The paper weight.There is one bug-free software out there: int main( void ){ return 0;}Where's the manual override for that accelerator?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464872</id>
	<title>Re:Impossible to test</title>
	<author>Anonymous</author>
	<datestamp>1268505180000</datestamp>
	<modclass>Insightful</modclass>
	<modscore>4</modscore>
	<htmltext>By and large, it would seem that Toyota should probably be looking for exceptional conditions rather than typical ones. Correct me if I'm wrong, but if a relatively small number of vehicles have actually exhibited the acceleration issue, it would seem like any bugs related to that would be in conditions that may not occur very often during typical driving. Seems to me that "outlier" cases or unusual methods of testing would be the best way to start; testing with typical driving conditions might not show anything.</htmltext>
<tokenext>By and large , it would seem that Toyota should probably be looking for exceptional conditions rather than typical ones .
Correct me if I 'm wrong , but if a relatively small number of vehicles have actually exhibited the acceleration issue , it would seem like any bugs related to that would be in conditions that may not occur very often during typical driving .
Seems to me that " outlier " cases or unusual methods of testing would be the best way to start ; testing with typical driving conditions might not show anything .</tokentext>
<sentencetext>By and large, it would seem that Toyota should probably be looking for exceptional conditions rather than typical ones.
Correct me if I'm wrong, but if a relatively small number of vehicles have actually exhibited the acceleration issue, it would seem like any bugs related to that would be in conditions that may not occur very often during typical driving.
Seems to me that "outlier" cases or unusual methods of testing would be the best way to start; testing with typical driving conditions might not show anything.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464840</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467528</id>
	<title>Fault tolerant S/W is necessarily more complex.</title>
	<author>Anonymous</author>
	<datestamp>1268481600000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Trying to code to handle all possible malfunctions can be exceedingly difficult. (Yes, I do have experience with embedded design and code that deals with H/W problems.)</p><p>First off, it can be difficult to determine which set of inputs are normal or acceptable and which ones represent a possible malfunction. Think about the myriad ways that a system can malfunction from bad sensors, noisy voltage, open or shorted connections, crosstalk on cables and so on. I had a system malfunction because a built in A/D converter malfunctioned and the interrupt it generated was lost, causing the system to suspend in time. If the brake and throttle are both pressed at the same time, is that a sensor problem? One foot on two pedals? Or maybe the driver is getting ready to pull a boat up a ramp. Disable the throttle and he'll roll back into the water. Might drown. But he probably won't have time to dial 911.</p><p>Figuring out all of the situations in which the system can malfunction will require an exceedingly fertile imagination. And most likely 90\% of those malfunctions will never ever happen in the wild. But it is likely that something will malfunction several years down the road and the engineers will scratch their heads and say "gee, didn't see that coming."</p><p>Now add code to deal with all of those possibilities and you have a combinatorial explosion of situations the code has to handle. That makes it less and less likely that the code will gracefully handle all situations and makes more and more likely that unrelated bugs will be introduced.</p></htmltext>
<tokenext>Trying to code to handle all possible malfunctions can be exceedingly difficult .
( Yes , I do have experience with embedded design and code that deals with H/W problems .
) First off , it can be difficult to determine which set of inputs are normal or acceptable and which ones represent a possible malfunction .
Think about the myriad ways that a system can malfunction from bad sensors , noisy voltage , open or shorted connections , crosstalk on cables and so on .
I had a system malfunction because a built in A/D converter malfunctioned and the interrupt it generated was lost , causing the system to suspend in time .
If the brake and throttle are both pressed at the same time , is that a sensor problem ?
One foot on two pedals ?
Or maybe the driver is getting ready to pull a boat up a ramp .
Disable the throttle and he 'll roll back into the water .
Might drown .
But he probably wo n't have time to dial 911.Figuring out all of the situations in which the system can malfunction will require an exceedingly fertile imagination .
And most likely 90 \ % of those malfunctions will never ever happen in the wild .
But it is likely that something will malfunction several years down the road and the engineers will scratch their heads and say " gee , did n't see that coming .
" Now add code to deal with all of those possibilities and you have a combinatorial explosion of situations the code has to handle .
That makes it less and less likely that the code will gracefully handle all situations and makes more and more likely that unrelated bugs will be introduced .</tokentext>
<sentencetext>Trying to code to handle all possible malfunctions can be exceedingly difficult.
(Yes, I do have experience with embedded design and code that deals with H/W problems.
)First off, it can be difficult to determine which set of inputs are normal or acceptable and which ones represent a possible malfunction.
Think about the myriad ways that a system can malfunction from bad sensors, noisy voltage, open or shorted connections, crosstalk on cables and so on.
I had a system malfunction because a built in A/D converter malfunctioned and the interrupt it generated was lost, causing the system to suspend in time.
If the brake and throttle are both pressed at the same time, is that a sensor problem?
One foot on two pedals?
Or maybe the driver is getting ready to pull a boat up a ramp.
Disable the throttle and he'll roll back into the water.
Might drown.
But he probably won't have time to dial 911.Figuring out all of the situations in which the system can malfunction will require an exceedingly fertile imagination.
And most likely 90\% of those malfunctions will never ever happen in the wild.
But it is likely that something will malfunction several years down the road and the engineers will scratch their heads and say "gee, didn't see that coming.
"Now add code to deal with all of those possibilities and you have a combinatorial explosion of situations the code has to handle.
That makes it less and less likely that the code will gracefully handle all situations and makes more and more likely that unrelated bugs will be introduced.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468210</id>
	<title>nice cercopid</title>
	<author>Anonymous</author>
	<datestamp>1268486700000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Since when did two-lined spittlebugs become the bug-of-choice?  I thought it was all about the blatellids.</p></htmltext>
<tokenext>Since when did two-lined spittlebugs become the bug-of-choice ?
I thought it was all about the blatellids .</tokentext>
<sentencetext>Since when did two-lined spittlebugs become the bug-of-choice?
I thought it was all about the blatellids.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466398</id>
	<title>Re:We need full access to the data recorders</title>
	<author>b4dc0d3r</author>
	<datestamp>1268472780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>I believe they already know the problem and don't want to release information that would help certify a class action suit.  I have read reputable reporting that they fixed this in later cars but did not think it was bad enough to recall earlier ones.</p><p>In other words, it would help everyone except Toyota, which is why they are playing games.</p><p>Right now, there are lots of people who blame driver error, and the recalls that have been detailed are physical rearrangement of the brake, floor mat, or other parts in that area.  All of this could be a distraction from faulty code.  I have read of an update which gives brake priority over anything else, but drivers report that doesn't fix the problem.</p><p>Ultimately, what I conclude is that Toyota has a general idea of where the fault is, and is selling a product known to have potential safety risks, but is making fixes without knowing if that is the true root cause.  If that comes out, Toyota will probably be forced to halt sales until they can fully document and prove the cause is known and the issue has been fixed for good.</p><p>In other words, if someone else solves the problem, Toyota USA is going to take a huge hit.  So you release the parts you're sure don't reveal anything until the NHTSA orders all doata be handed over.</p></htmltext>
<tokenext>I believe they already know the problem and do n't want to release information that would help certify a class action suit .
I have read reputable reporting that they fixed this in later cars but did not think it was bad enough to recall earlier ones.In other words , it would help everyone except Toyota , which is why they are playing games.Right now , there are lots of people who blame driver error , and the recalls that have been detailed are physical rearrangement of the brake , floor mat , or other parts in that area .
All of this could be a distraction from faulty code .
I have read of an update which gives brake priority over anything else , but drivers report that does n't fix the problem.Ultimately , what I conclude is that Toyota has a general idea of where the fault is , and is selling a product known to have potential safety risks , but is making fixes without knowing if that is the true root cause .
If that comes out , Toyota will probably be forced to halt sales until they can fully document and prove the cause is known and the issue has been fixed for good.In other words , if someone else solves the problem , Toyota USA is going to take a huge hit .
So you release the parts you 're sure do n't reveal anything until the NHTSA orders all doata be handed over .</tokentext>
<sentencetext>I believe they already know the problem and don't want to release information that would help certify a class action suit.
I have read reputable reporting that they fixed this in later cars but did not think it was bad enough to recall earlier ones.In other words, it would help everyone except Toyota, which is why they are playing games.Right now, there are lots of people who blame driver error, and the recalls that have been detailed are physical rearrangement of the brake, floor mat, or other parts in that area.
All of this could be a distraction from faulty code.
I have read of an update which gives brake priority over anything else, but drivers report that doesn't fix the problem.Ultimately, what I conclude is that Toyota has a general idea of where the fault is, and is selling a product known to have potential safety risks, but is making fixes without knowing if that is the true root cause.
If that comes out, Toyota will probably be forced to halt sales until they can fully document and prove the cause is known and the issue has been fixed for good.In other words, if someone else solves the problem, Toyota USA is going to take a huge hit.
So you release the parts you're sure don't reveal anything until the NHTSA orders all doata be handed over.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465294</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465298</id>
	<title>The problem is they start with a conclusion</title>
	<author>mysidia</author>
	<datestamp>1268508300000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>
Based only on testing and design experience, this is not sound logic.
</p><p>
Agreed software commonly has bugs not exposed to testing, but the same is true of hardware manufacture, and firmware/ROM code too.
</p><p>
But also, there may also be an unanticipated interaction that would not be considered a software bug in and of itself,  but a combination of two unanticipated inputs creates a serious problem.
</p><p>
The software does not exist in a vacuum, and might be susceptible from effects from hardware, especially as the unit ages -- such as corrupt memory area,  multi-bit errors, memory flip errors due to gamma radiation, overheating, and all the same issues that plague desktop computers.
</p><p>
Could be a characteristic of the design of some portion of the software causes the system to handle an error condition ungracefully, that <b>should</b> be trapped, that safety hardware should be added to detect/deal with, or that software changes should occur  (even if it's not strictly a software bug, sometimes you need to change the software to be more robust in the face of a hardware problem).
</p><p>
For example, some chip periodically has a minor (indetectable) manufacturing chip defect, or some minor variation.
</p><p>
Or it could be as simple as the code that gets burned to some chip isn't the same as it's supposed to be 100\% of the time.
</p><p>
For instance, if there was a revision to one component, but the old code was still getting burnt to new units...  things could still be being produced with an old fixed bug, maybe.
</p><p>
Or combination of components at different revision levels than what was tested.
</p><p>
Moreover, an unexpected input could have been found in the field to result in physical lockup of some microcontroller.
</p><p>
You can't test <b>everything</b> 100\% it's arrogant and flat out wrong to claim you can.
</p></htmltext>
<tokenext>Based only on testing and design experience , this is not sound logic .
Agreed software commonly has bugs not exposed to testing , but the same is true of hardware manufacture , and firmware/ROM code too .
But also , there may also be an unanticipated interaction that would not be considered a software bug in and of itself , but a combination of two unanticipated inputs creates a serious problem .
The software does not exist in a vacuum , and might be susceptible from effects from hardware , especially as the unit ages -- such as corrupt memory area , multi-bit errors , memory flip errors due to gamma radiation , overheating , and all the same issues that plague desktop computers .
Could be a characteristic of the design of some portion of the software causes the system to handle an error condition ungracefully , that should be trapped , that safety hardware should be added to detect/deal with , or that software changes should occur ( even if it 's not strictly a software bug , sometimes you need to change the software to be more robust in the face of a hardware problem ) .
For example , some chip periodically has a minor ( indetectable ) manufacturing chip defect , or some minor variation .
Or it could be as simple as the code that gets burned to some chip is n't the same as it 's supposed to be 100 \ % of the time .
For instance , if there was a revision to one component , but the old code was still getting burnt to new units... things could still be being produced with an old fixed bug , maybe .
Or combination of components at different revision levels than what was tested .
Moreover , an unexpected input could have been found in the field to result in physical lockup of some microcontroller .
You ca n't test everything 100 \ % it 's arrogant and flat out wrong to claim you can .</tokentext>
<sentencetext>
Based only on testing and design experience, this is not sound logic.
Agreed software commonly has bugs not exposed to testing, but the same is true of hardware manufacture, and firmware/ROM code too.
But also, there may also be an unanticipated interaction that would not be considered a software bug in and of itself,  but a combination of two unanticipated inputs creates a serious problem.
The software does not exist in a vacuum, and might be susceptible from effects from hardware, especially as the unit ages -- such as corrupt memory area,  multi-bit errors, memory flip errors due to gamma radiation, overheating, and all the same issues that plague desktop computers.
Could be a characteristic of the design of some portion of the software causes the system to handle an error condition ungracefully, that should be trapped, that safety hardware should be added to detect/deal with, or that software changes should occur  (even if it's not strictly a software bug, sometimes you need to change the software to be more robust in the face of a hardware problem).
For example, some chip periodically has a minor (indetectable) manufacturing chip defect, or some minor variation.
Or it could be as simple as the code that gets burned to some chip isn't the same as it's supposed to be 100\% of the time.
For instance, if there was a revision to one component, but the old code was still getting burnt to new units...  things could still be being produced with an old fixed bug, maybe.
Or combination of components at different revision levels than what was tested.
Moreover, an unexpected input could have been found in the field to result in physical lockup of some microcontroller.
You can't test everything 100\% it's arrogant and flat out wrong to claim you can.
</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470162</id>
	<title>"It's good enough, shippit."</title>
	<author>grikdog</author>
	<datestamp>1268506800000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>It sucks, skippit.  But gee, thanks, Mr. Gates, for a philosophy that proves those clowns at IBM had some of it right in the prehistoric Sixties.  (I.e., racks of software printouts, and a multitiered CVS with flinty-eyed human engineers running the protocols, not some flimsy database system.)  You had to SIGN your stuff in the old days.</htmltext>
<tokenext>It sucks , skippit .
But gee , thanks , Mr. Gates , for a philosophy that proves those clowns at IBM had some of it right in the prehistoric Sixties .
( I.e. , racks of software printouts , and a multitiered CVS with flinty-eyed human engineers running the protocols , not some flimsy database system .
) You had to SIGN your stuff in the old days .</tokentext>
<sentencetext>It sucks, skippit.
But gee, thanks, Mr. Gates, for a philosophy that proves those clowns at IBM had some of it right in the prehistoric Sixties.
(I.e., racks of software printouts, and a multitiered CVS with flinty-eyed human engineers running the protocols, not some flimsy database system.
)  You had to SIGN your stuff in the old days.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468726</id>
	<title>Re:Toyota:</title>
	<author>jhd</author>
	<datestamp>1268490780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>Probably just a "race" condition.</p></htmltext>
<tokenext>Probably just a " race " condition .</tokentext>
<sentencetext>Probably just a "race" condition.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467804</id>
	<title>Re:Logic of Testing</title>
	<author>sjames</author>
	<datestamp>1268483520000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>No, code another team wrote had an interrupt routine that somehow corrupted the carry flag. Since the bug was only triggere once in all the lab testing, it seems unlikely that the corruption happened every time. It could even have been a buggy compiler re-ordering instructions that couldn't (in that case) be safely re-ordered.</p></htmltext>
<tokenext>No , code another team wrote had an interrupt routine that somehow corrupted the carry flag .
Since the bug was only triggere once in all the lab testing , it seems unlikely that the corruption happened every time .
It could even have been a buggy compiler re-ordering instructions that could n't ( in that case ) be safely re-ordered .</tokentext>
<sentencetext>No, code another team wrote had an interrupt routine that somehow corrupted the carry flag.
Since the bug was only triggere once in all the lab testing, it seems unlikely that the corruption happened every time.
It could even have been a buggy compiler re-ordering instructions that couldn't (in that case) be safely re-ordered.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465052</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468824</id>
	<title>Re:Help me benefit from media hype</title>
	<author>zenaida\_valdez</author>
	<datestamp>1268491920000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Heel and toe braking. Downshifting for a corner, if you just drop it into the next lower gear, the engine inertia causes the rear wheels to lose traction while the engine is sped up. You'll go sideways on the entrance to a corner. You have to blip the throttle while shifting to raise the engine speed to match the next lower gear. Left foot on clutch, ball of right foot on brake, heel of right foot on throttle.</htmltext>
<tokenext>Heel and toe braking .
Downshifting for a corner , if you just drop it into the next lower gear , the engine inertia causes the rear wheels to lose traction while the engine is sped up .
You 'll go sideways on the entrance to a corner .
You have to blip the throttle while shifting to raise the engine speed to match the next lower gear .
Left foot on clutch , ball of right foot on brake , heel of right foot on throttle .</tokentext>
<sentencetext>Heel and toe braking.
Downshifting for a corner, if you just drop it into the next lower gear, the engine inertia causes the rear wheels to lose traction while the engine is sped up.
You'll go sideways on the entrance to a corner.
You have to blip the throttle while shifting to raise the engine speed to match the next lower gear.
Left foot on clutch, ball of right foot on brake, heel of right foot on throttle.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465866</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469926</id>
	<title>to much hype</title>
	<author>luther349</author>
	<datestamp>1268503560000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext>as a driver of course i have all kinda of situations of something failing on my car being its a old car. the key to any bad situation is not to panic. these would be the same drivers that hit other cars if there brake failed rather then quickly applying the ebrake. the system there wanting to put in cars the smart peddle does the same thing shutting off the car yourself would do. trust me i was going down i-75 in my car and a brake line blew being my car is a single cylinder brake system i lost all braking power and had to pull the ebrake locking the rear tires did i crash no. of course my cars sensors all work and both my abs and brake light lit up right away telling me there was a major problem. i dunno abought other drivers sometimes even if you car all of a suddion whent to full power for no reasion thers always that off button stoping that chain of events dead. weather toyotas cars have a real issue or not driver skill still is the reasion people died. drivers tend to panic hen there put in a bad spot and bad things happon. im not blaming them but any good driver should knoe what to do in case of a runaway or failer of the brake system. but in the usa you dont not need to knoe these things to get  a liance to drive.</htmltext>
<tokenext>as a driver of course i have all kinda of situations of something failing on my car being its a old car .
the key to any bad situation is not to panic .
these would be the same drivers that hit other cars if there brake failed rather then quickly applying the ebrake .
the system there wanting to put in cars the smart peddle does the same thing shutting off the car yourself would do .
trust me i was going down i-75 in my car and a brake line blew being my car is a single cylinder brake system i lost all braking power and had to pull the ebrake locking the rear tires did i crash no .
of course my cars sensors all work and both my abs and brake light lit up right away telling me there was a major problem .
i dunno abought other drivers sometimes even if you car all of a suddion whent to full power for no reasion thers always that off button stoping that chain of events dead .
weather toyotas cars have a real issue or not driver skill still is the reasion people died .
drivers tend to panic hen there put in a bad spot and bad things happon .
im not blaming them but any good driver should knoe what to do in case of a runaway or failer of the brake system .
but in the usa you dont not need to knoe these things to get a liance to drive .</tokentext>
<sentencetext>as a driver of course i have all kinda of situations of something failing on my car being its a old car.
the key to any bad situation is not to panic.
these would be the same drivers that hit other cars if there brake failed rather then quickly applying the ebrake.
the system there wanting to put in cars the smart peddle does the same thing shutting off the car yourself would do.
trust me i was going down i-75 in my car and a brake line blew being my car is a single cylinder brake system i lost all braking power and had to pull the ebrake locking the rear tires did i crash no.
of course my cars sensors all work and both my abs and brake light lit up right away telling me there was a major problem.
i dunno abought other drivers sometimes even if you car all of a suddion whent to full power for no reasion thers always that off button stoping that chain of events dead.
weather toyotas cars have a real issue or not driver skill still is the reasion people died.
drivers tend to panic hen there put in a bad spot and bad things happon.
im not blaming them but any good driver should knoe what to do in case of a runaway or failer of the brake system.
but in the usa you dont not need to knoe these things to get  a liance to drive.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467694</id>
	<title>Re:From the days of "winmodems"</title>
	<author>John Hasler</author>
	<datestamp>1268482680000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>&gt; Would Toyota be having these problems with an accelerator cable vs<br>&gt; electronic?</p><p>GM once had a very similar problem with a 70s car with a cable.  An engine mount failure would allow the engine to rotate under acceleration in such a way as to yank the cable to full throttle and then jam it, causing the car to run away.  The resulting collision would knock the cable free and as collisions often break engine mounts, the evidence disappeared.</p><p>Computerized systems are usually more reliable than mechanical ones, but they must be competently engineered.</p></htmltext>
<tokenext>&gt; Would Toyota be having these problems with an accelerator cable vs &gt; electronic ? GM once had a very similar problem with a 70s car with a cable .
An engine mount failure would allow the engine to rotate under acceleration in such a way as to yank the cable to full throttle and then jam it , causing the car to run away .
The resulting collision would knock the cable free and as collisions often break engine mounts , the evidence disappeared.Computerized systems are usually more reliable than mechanical ones , but they must be competently engineered .</tokentext>
<sentencetext>&gt; Would Toyota be having these problems with an accelerator cable vs&gt; electronic?GM once had a very similar problem with a 70s car with a cable.
An engine mount failure would allow the engine to rotate under acceleration in such a way as to yank the cable to full throttle and then jam it, causing the car to run away.
The resulting collision would knock the cable free and as collisions often break engine mounts, the evidence disappeared.Computerized systems are usually more reliable than mechanical ones, but they must be competently engineered.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470906</id>
	<title>Re:Speaking as an embedded programmer here...</title>
	<author>muridae</author>
	<datestamp>1268562780000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>That was my first thought as well, but I went for Hanlon's razor. You deal with digital software and analogue parts, and know that even a momentary push button switch is analogue. So even something that simple gets de-bounced because it might cause a problem for the software if it changes rapidly. But, picture some software engineer staring at the circuit board specification, and seeing all of these extra capacitors jumping from a signal line to ground. "Hey, I can save the company a few cents by getting rid of these!" Admittedly, because I have been that software engineer on a home-made project, it is an easy mistake to make and the first that came to my mind.</p><p>What I wonder about all of this, is why the Japanese haven't had this problem with Priuses . . . Priusi? kept in Japan. Flaw in North American manufacturing, something weird in the road conditions, driving habits, smaller feet not hitting both the gas and brake when they get panicked, or just numbers on the road?</p></htmltext>
<tokenext>That was my first thought as well , but I went for Hanlon 's razor .
You deal with digital software and analogue parts , and know that even a momentary push button switch is analogue .
So even something that simple gets de-bounced because it might cause a problem for the software if it changes rapidly .
But , picture some software engineer staring at the circuit board specification , and seeing all of these extra capacitors jumping from a signal line to ground .
" Hey , I can save the company a few cents by getting rid of these !
" Admittedly , because I have been that software engineer on a home-made project , it is an easy mistake to make and the first that came to my mind.What I wonder about all of this , is why the Japanese have n't had this problem with Priuses .
. .
Priusi ? kept in Japan .
Flaw in North American manufacturing , something weird in the road conditions , driving habits , smaller feet not hitting both the gas and brake when they get panicked , or just numbers on the road ?</tokentext>
<sentencetext>That was my first thought as well, but I went for Hanlon's razor.
You deal with digital software and analogue parts, and know that even a momentary push button switch is analogue.
So even something that simple gets de-bounced because it might cause a problem for the software if it changes rapidly.
But, picture some software engineer staring at the circuit board specification, and seeing all of these extra capacitors jumping from a signal line to ground.
"Hey, I can save the company a few cents by getting rid of these!
" Admittedly, because I have been that software engineer on a home-made project, it is an easy mistake to make and the first that came to my mind.What I wonder about all of this, is why the Japanese haven't had this problem with Priuses .
. .
Priusi? kept in Japan.
Flaw in North American manufacturing, something weird in the road conditions, driving habits, smaller feet not hitting both the gas and brake when they get panicked, or just numbers on the road?</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466956</id>
	<title>A Most Unusual Bug Indeed</title>
	<author>Stormy Dragon</author>
	<datestamp>1268477160000</datestamp>
	<modclass>Interestin</modclass>
	<modscore>2</modscore>
	<htmltext><p>The Times also helpfully provides a list of all the people who have died in "sudden acceleration" accidents involving Toyotas:</p><p><a href="http://articles.latimes.com/2010/feb/28/business/la-fiw-toyota-deaths-list28-2010feb28" title="latimes.com">Toyotas, deaths and sudden acceleration</a> [latimes.com]</p><p>If you look through the list at the ages mentioned, one begins to notice a rather odd pattern: 18, 21, 32, 34, 44, 45, 47, 56, 57, 58, 60, 61, 63, 66, 68, 72, 72, 77, 79, 83, 85, 89</p><p>This is a most peculiar bug indeed in that it seems occur primarily when the driver is elderly.  Or perhaps, as with previous "sudden acceleration" scares, this will ultimately turn out to be the result of people slamming on the gas when they menat to slam on the brake and then trying to blame the car for their error.</p></htmltext>
<tokenext>The Times also helpfully provides a list of all the people who have died in " sudden acceleration " accidents involving Toyotas : Toyotas , deaths and sudden acceleration [ latimes.com ] If you look through the list at the ages mentioned , one begins to notice a rather odd pattern : 18 , 21 , 32 , 34 , 44 , 45 , 47 , 56 , 57 , 58 , 60 , 61 , 63 , 66 , 68 , 72 , 72 , 77 , 79 , 83 , 85 , 89This is a most peculiar bug indeed in that it seems occur primarily when the driver is elderly .
Or perhaps , as with previous " sudden acceleration " scares , this will ultimately turn out to be the result of people slamming on the gas when they menat to slam on the brake and then trying to blame the car for their error .</tokentext>
<sentencetext>The Times also helpfully provides a list of all the people who have died in "sudden acceleration" accidents involving Toyotas:Toyotas, deaths and sudden acceleration [latimes.com]If you look through the list at the ages mentioned, one begins to notice a rather odd pattern: 18, 21, 32, 34, 44, 45, 47, 56, 57, 58, 60, 61, 63, 66, 68, 72, 72, 77, 79, 83, 85, 89This is a most peculiar bug indeed in that it seems occur primarily when the driver is elderly.
Or perhaps, as with previous "sudden acceleration" scares, this will ultimately turn out to be the result of people slamming on the gas when they menat to slam on the brake and then trying to blame the car for their error.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262</id>
	<title>Re:Help me benefit from media hype</title>
	<author>John Hasler</author>
	<datestamp>1268507940000</datestamp>
	<modclass>Informativ</modclass>
	<modscore>3</modscore>
	<htmltext><p>&gt; And I know how to hit the brakes...</p><p>With the engine past the redline there is very little vacuum to operate the power brakes.  Without power assist the brakes may not be able to overcome the engine (this is, IMHO, a fundamental design defect).</p><p>&gt;<nobr> <wbr></nobr>...shift into neutral...</p><p>The computer may not let you do that with the car moving and the engine at high rpm.  After all, the engine and/or transmission might be damaged (another design defect).</p><p>&gt;<nobr> <wbr></nobr>...and/or turn off the key...</p><p>Some of these vehicles don't have keys: just a radio remote.  The emergency shutdown procedure is to hold a button down for three seconds (another design defect).</p></htmltext>
<tokenext>&gt; And I know how to hit the brakes...With the engine past the redline there is very little vacuum to operate the power brakes .
Without power assist the brakes may not be able to overcome the engine ( this is , IMHO , a fundamental design defect ) . &gt; ...shift into neutral...The computer may not let you do that with the car moving and the engine at high rpm .
After all , the engine and/or transmission might be damaged ( another design defect ) . &gt; ...and/or turn off the key...Some of these vehicles do n't have keys : just a radio remote .
The emergency shutdown procedure is to hold a button down for three seconds ( another design defect ) .</tokentext>
<sentencetext>&gt; And I know how to hit the brakes...With the engine past the redline there is very little vacuum to operate the power brakes.
Without power assist the brakes may not be able to overcome the engine (this is, IMHO, a fundamental design defect).&gt; ...shift into neutral...The computer may not let you do that with the car moving and the engine at high rpm.
After all, the engine and/or transmission might be damaged (another design defect).&gt; ...and/or turn off the key...Some of these vehicles don't have keys: just a radio remote.
The emergency shutdown procedure is to hold a button down for three seconds (another design defect).</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465772</id>
	<title>Hacked?</title>
	<author>b4upoo</author>
	<datestamp>1268512080000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>      Is there much of a chance that some evil idiot created a bug, perhaps transferred from a Toyota diagnostic device that inserts a bug causing the accelerators to act as if they are wide open?<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; My personal bet is that there are three or more ways that these cars run away. One might be the carpet thing. Another might be wear on that little metal part that we saw on TV and more might be in the software. The next question is whether the software glitch was sabotage or design related.<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; That stupid start button needs to be converted to a switch so that off becomes more absolute. Having to hold a button for three seconds to turn a car off is just wrong.<br>
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; The Miami heat have a "Toyota" scoreboard. During the last game the scorekeeper messed up and they had to run the numbers real fast before they could reset it. I could not help but think of it as a run away Toyota score board.</p></htmltext>
<tokenext>Is there much of a chance that some evil idiot created a bug , perhaps transferred from a Toyota diagnostic device that inserts a bug causing the accelerators to act as if they are wide open ?
            My personal bet is that there are three or more ways that these cars run away .
One might be the carpet thing .
Another might be wear on that little metal part that we saw on TV and more might be in the software .
The next question is whether the software glitch was sabotage or design related .
              That stupid start button needs to be converted to a switch so that off becomes more absolute .
Having to hold a button for three seconds to turn a car off is just wrong .
                The Miami heat have a " Toyota " scoreboard .
During the last game the scorekeeper messed up and they had to run the numbers real fast before they could reset it .
I could not help but think of it as a run away Toyota score board .</tokentext>
<sentencetext>      Is there much of a chance that some evil idiot created a bug, perhaps transferred from a Toyota diagnostic device that inserts a bug causing the accelerators to act as if they are wide open?
            My personal bet is that there are three or more ways that these cars run away.
One might be the carpet thing.
Another might be wear on that little metal part that we saw on TV and more might be in the software.
The next question is whether the software glitch was sabotage or design related.
              That stupid start button needs to be converted to a switch so that off becomes more absolute.
Having to hold a button for three seconds to turn a car off is just wrong.
                The Miami heat have a "Toyota" scoreboard.
During the last game the scorekeeper messed up and they had to run the numbers real fast before they could reset it.
I could not help but think of it as a run away Toyota score board.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465584</id>
	<title>Re:Help me benefit from media hype</title>
	<author>Anonymous</author>
	<datestamp>1268510580000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Are there any really good deals on Toyotas available?</p></div><p>Dunno, if you can call this a deal.  Google news, "toyota financing".</p><p>Looks like they're offering zero-percent financing.  Your call if you want to wait until they start offering negative interest (aka rebates).</p><p>This does reminds me of the $25 flights to Las Vegas in late 2001/early 2002.</p></div>
	</htmltext>
<tokenext>Are there any really good deals on Toyotas available ? Dunno , if you can call this a deal .
Google news , " toyota financing " .Looks like they 're offering zero-percent financing .
Your call if you want to wait until they start offering negative interest ( aka rebates ) .This does reminds me of the $ 25 flights to Las Vegas in late 2001/early 2002 .</tokentext>
<sentencetext>Are there any really good deals on Toyotas available?Dunno, if you can call this a deal.
Google news, "toyota financing".Looks like they're offering zero-percent financing.
Your call if you want to wait until they start offering negative interest (aka rebates).This does reminds me of the $25 flights to Las Vegas in late 2001/early 2002.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465130</id>
	<title>I wonder if</title>
	<author>thephydes</author>
	<datestamp>1268507100000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>the acceleration was caused by some external EMI event? Why?.  It is well known amongst ham radio operators that some cars do not have sufficient EMI protection so that an otherwise correctly installed transceiver will interfere with the car electronics when used.

Pure speculation I know......</htmltext>
<tokenext>the acceleration was caused by some external EMI event ?
Why ? . It is well known amongst ham radio operators that some cars do not have sufficient EMI protection so that an otherwise correctly installed transceiver will interfere with the car electronics when used .
Pure speculation I know..... .</tokentext>
<sentencetext>the acceleration was caused by some external EMI event?
Why?.  It is well known amongst ham radio operators that some cars do not have sufficient EMI protection so that an otherwise correctly installed transceiver will interfere with the car electronics when used.
Pure speculation I know......</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465826</id>
	<title>General comment regarding RSS feeds</title>
	<author>Radio\_active\_cgb</author>
	<datestamp>1268512560000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>This is off topic:</p><p>I'd rather not have comments on the article appearing in the RSS feed. I'd like to see the article summaries appear "several on one screen" rather than "one per screen".</p></htmltext>
<tokenext>This is off topic : I 'd rather not have comments on the article appearing in the RSS feed .
I 'd like to see the article summaries appear " several on one screen " rather than " one per screen " .</tokentext>
<sentencetext>This is off topic:I'd rather not have comments on the article appearing in the RSS feed.
I'd like to see the article summaries appear "several on one screen" rather than "one per screen".</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</id>
	<title>Toyota:</title>
	<author>dushkin</author>
	<datestamp>1268504760000</datestamp>
	<modclass>Funny</modclass>
	<modscore>5</modscore>
	<htmltext><p>Always going forward.</p></htmltext>
<tokenext>Always going forward .</tokentext>
<sentencetext>Always going forward.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464984</id>
	<title>Also a witch</title>
	<author>Anonymous</author>
	<datestamp>1268506080000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p>Toyota may also have witches on staff, which may cause the unintended acceleration. If Toyota has indeed searched its personnel as it says without finding any witches, my response is simple: Keep trying. Find new ways to find witches, and come up with more creative tests, possibly involving a duck and a scale. Until these witches are identified, how can you be certain they are not related to sudden acceleration?</p></htmltext>
<tokenext>Toyota may also have witches on staff , which may cause the unintended acceleration .
If Toyota has indeed searched its personnel as it says without finding any witches , my response is simple : Keep trying .
Find new ways to find witches , and come up with more creative tests , possibly involving a duck and a scale .
Until these witches are identified , how can you be certain they are not related to sudden acceleration ?</tokentext>
<sentencetext>Toyota may also have witches on staff, which may cause the unintended acceleration.
If Toyota has indeed searched its personnel as it says without finding any witches, my response is simple: Keep trying.
Find new ways to find witches, and come up with more creative tests, possibly involving a duck and a scale.
Until these witches are identified, how can you be certain they are not related to sudden acceleration?</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465052</id>
	<title>Re:Logic of Testing</title>
	<author>Anonymous</author>
	<datestamp>1268506620000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>How about this howler:<blockquote><div><p>The only viable theory we could come up with was that an interrupt (an external hardware stimulus such as a timer going off) had occurred at just the right microsecond within the execution of Stolper's software. Furthermore, we theorized, the operating system (the equivalent of Windows on the flight computer) had a bug that caused it to misremember whether an arithmetic carry had occurred just before the interrupt. Although highly unlikely, it was the only credible explanation we could come up with. Because this was a new version of the operating system built for Pathfinder, still not yet fully tested itself, this theory had some credibility.</p></div>
</blockquote><p>
So they <i>speculate</i> that code <b>they wrote</b> had an <i>interrupt</i> routine that was not bracketed with PUSHF/POPF instructions!!! Which is like Assembly 101.</p></div>
	</htmltext>
<tokenext>How about this howler : The only viable theory we could come up with was that an interrupt ( an external hardware stimulus such as a timer going off ) had occurred at just the right microsecond within the execution of Stolper 's software .
Furthermore , we theorized , the operating system ( the equivalent of Windows on the flight computer ) had a bug that caused it to misremember whether an arithmetic carry had occurred just before the interrupt .
Although highly unlikely , it was the only credible explanation we could come up with .
Because this was a new version of the operating system built for Pathfinder , still not yet fully tested itself , this theory had some credibility .
So they speculate that code they wrote had an interrupt routine that was not bracketed with PUSHF/POPF instructions ! ! !
Which is like Assembly 101 .</tokentext>
<sentencetext>How about this howler:The only viable theory we could come up with was that an interrupt (an external hardware stimulus such as a timer going off) had occurred at just the right microsecond within the execution of Stolper's software.
Furthermore, we theorized, the operating system (the equivalent of Windows on the flight computer) had a bug that caused it to misremember whether an arithmetic carry had occurred just before the interrupt.
Although highly unlikely, it was the only credible explanation we could come up with.
Because this was a new version of the operating system built for Pathfinder, still not yet fully tested itself, this theory had some credibility.
So they speculate that code they wrote had an interrupt routine that was not bracketed with PUSHF/POPF instructions!!!
Which is like Assembly 101.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470676</id>
	<title>Re:It is possible, and is done, but hard/expensive</title>
	<author>phantomfive</author>
	<datestamp>1268559000000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Wow, mind if I ask what sorts of companies do that kind of work, and how you got into it?  That sounds awesome.</htmltext>
<tokenext>Wow , mind if I ask what sorts of companies do that kind of work , and how you got into it ?
That sounds awesome .</tokentext>
<sentencetext>Wow, mind if I ask what sorts of companies do that kind of work, and how you got into it?
That sounds awesome.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466836</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466296</id>
	<title>Re:Speaking as an embedded programmer here...</title>
	<author>girlintraining</author>
	<datestamp>1268472120000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><p><div class="quote"><p>Does the system as a whole get into a weird state if packets drop?</p></div><p>My theory: Older drivers tend to not to mash the accelerator. Have you noticed on like PS2 or XBox that if the controller loses calibration because you went into a menu or are very gentle with moving it sometimes it'll 'stick' in the software and rotate continually until you unplug the controller (thus resetting the zero state)?</p><p>It's like the <a href="http://en.wikipedia.org/wiki/Therac-25" title="wikipedia.org" rel="nofollow">Therac-25</a> [wikipedia.org] incident; The software makes certain assumptions about the mechanical interlocks that, in select cases, result in an inconsistent reading. It happens all the time in embedded systems.</p></div>
	</htmltext>
<tokenext>Does the system as a whole get into a weird state if packets drop ? My theory : Older drivers tend to not to mash the accelerator .
Have you noticed on like PS2 or XBox that if the controller loses calibration because you went into a menu or are very gentle with moving it sometimes it 'll 'stick ' in the software and rotate continually until you unplug the controller ( thus resetting the zero state ) ? It 's like the Therac-25 [ wikipedia.org ] incident ; The software makes certain assumptions about the mechanical interlocks that , in select cases , result in an inconsistent reading .
It happens all the time in embedded systems .</tokentext>
<sentencetext>Does the system as a whole get into a weird state if packets drop?My theory: Older drivers tend to not to mash the accelerator.
Have you noticed on like PS2 or XBox that if the controller loses calibration because you went into a menu or are very gentle with moving it sometimes it'll 'stick' in the software and rotate continually until you unplug the controller (thus resetting the zero state)?It's like the Therac-25 [wikipedia.org] incident; The software makes certain assumptions about the mechanical interlocks that, in select cases, result in an inconsistent reading.
It happens all the time in embedded systems.
	</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467220</id>
	<title>If the pedal is stuck</title>
	<author>SetupWeasel</author>
	<datestamp>1268479320000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext><p>It isn't a software or electrical problem. It is a mechanical problem.</p></htmltext>
<tokenext>It is n't a software or electrical problem .
It is a mechanical problem .</tokentext>
<sentencetext>It isn't a software or electrical problem.
It is a mechanical problem.</sentencetext>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464954</id>
	<title>Re:Toyota:</title>
	<author>Anonymous</author>
	<datestamp>1268505840000</datestamp>
	<modclass>None</modclass>
	<modscore>0</modscore>
	<htmltext><a href="http://www.despair.com/toyota.html" title="despair.com" rel="nofollow">Oblig DespairWear plug.</a> [despair.com]</htmltext>
<tokenext>Oblig DespairWear plug .
[ despair.com ]</tokentext>
<sentencetext>Oblig DespairWear plug.
[despair.com]</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469998</id>
	<title>Re:Logic of Testing</title>
	<author>tcgroat</author>
	<datestamp>1268504760000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext> <p> <i>   * If you don't find any bugs, then your software doesn't have any.
 </i></p><p><i>   * If you don't find any bugs, then there must be some left in your software.
</i></p><p><i>It sounds to me as if Toyota is saying the former, while Cummings says the latter. Neither is a correct conclusion.</i> </p><p>
I agree with that, but it comes down to a principal of safety engineering (related to what goombah99 was saying). If the design has not, or cannot, be shown safe and reliable, you should assume that it is <b>not</b> safe. Such designs should have a truly independent back-up system that can be shown to be safe and reliable. While software that disables the electrical throttle control when the brake is pressed and shuts down the engine when the button is held for 3 seconds is helpful, it does not guard against single points of failures ( control computer, various sensor, wiring failures, as well as the software). With literally millions of affected vehicles on the road, each for hundreds of hours per year, even highly unlikely events cannot be ignored. Safety engineering is a rather paranoid profession, and for good reason!
</p><p> <a href="http://www.nutwooduk.co.uk/downloads/Toyota25Feb2010.doc" title="nutwooduk.co.uk">Keith Armstrong</a> [nutwooduk.co.uk] [MS Word doc file] discusses many possible failure mechanisms that could cause the run-away Toyotas, in ways that would leave no clue as to the actual cause. His key point: I<i>t is impossible to prove, by testing alone, that electronics are reliable enough for safety-critical systems such as throttle control.</i> That doesn't mean to <i>not</i> test, only that testing alone is never enough.</p></htmltext>
<tokenext>* If you do n't find any bugs , then your software does n't have any .
* If you do n't find any bugs , then there must be some left in your software .
It sounds to me as if Toyota is saying the former , while Cummings says the latter .
Neither is a correct conclusion .
I agree with that , but it comes down to a principal of safety engineering ( related to what goombah99 was saying ) .
If the design has not , or can not , be shown safe and reliable , you should assume that it is not safe .
Such designs should have a truly independent back-up system that can be shown to be safe and reliable .
While software that disables the electrical throttle control when the brake is pressed and shuts down the engine when the button is held for 3 seconds is helpful , it does not guard against single points of failures ( control computer , various sensor , wiring failures , as well as the software ) .
With literally millions of affected vehicles on the road , each for hundreds of hours per year , even highly unlikely events can not be ignored .
Safety engineering is a rather paranoid profession , and for good reason !
Keith Armstrong [ nutwooduk.co.uk ] [ MS Word doc file ] discusses many possible failure mechanisms that could cause the run-away Toyotas , in ways that would leave no clue as to the actual cause .
His key point : It is impossible to prove , by testing alone , that electronics are reliable enough for safety-critical systems such as throttle control .
That does n't mean to not test , only that testing alone is never enough .</tokentext>
<sentencetext>     * If you don't find any bugs, then your software doesn't have any.
* If you don't find any bugs, then there must be some left in your software.
It sounds to me as if Toyota is saying the former, while Cummings says the latter.
Neither is a correct conclusion.
I agree with that, but it comes down to a principal of safety engineering (related to what goombah99 was saying).
If the design has not, or cannot, be shown safe and reliable, you should assume that it is not safe.
Such designs should have a truly independent back-up system that can be shown to be safe and reliable.
While software that disables the electrical throttle control when the brake is pressed and shuts down the engine when the button is held for 3 seconds is helpful, it does not guard against single points of failures ( control computer, various sensor, wiring failures, as well as the software).
With literally millions of affected vehicles on the road, each for hundreds of hours per year, even highly unlikely events cannot be ignored.
Safety engineering is a rather paranoid profession, and for good reason!
Keith Armstrong [nutwooduk.co.uk] [MS Word doc file] discusses many possible failure mechanisms that could cause the run-away Toyotas, in ways that would leave no clue as to the actual cause.
His key point: It is impossible to prove, by testing alone, that electronics are reliable enough for safety-critical systems such as throttle control.
That doesn't mean to not test, only that testing alone is never enough.</sentencetext>
	<parent>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908</parent>
</comment>
<comment>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465286</id>
	<title>acceleration could have been prevented....</title>
	<author>beofli</author>
	<datestamp>1268508180000</datestamp>
	<modclass>None</modclass>
	<modscore>1</modscore>
	<htmltext>Everyone knows that the first thing to do, when creating acceleration software, is to test for race-conditions...</htmltext>
<tokenext>Everyone knows that the first thing to do , when creating acceleration software , is to test for race-conditions.. .</tokentext>
<sentencetext>Everyone knows that the first thing to do, when creating acceleration software, is to test for race-conditions...</sentencetext>
</comment>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_35</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465774
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_40</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468138
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467694
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465214
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_27</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465200
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_29</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464976
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467610
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_43</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465586
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_34</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466982
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_57</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466836
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470676
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_33</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465742
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31488020
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465292
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_49</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465744
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_54</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465866
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468824
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_25</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470000
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_56</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465062
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_39</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464840
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467936
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466956
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469448
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470644
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_32</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465466
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_55</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469998
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465794
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470760
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_46</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467618
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466134
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465520
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465434
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_47</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467806
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_38</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470406
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_41</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465054
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_37</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466228
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_28</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465726
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465070
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470430
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_44</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466296
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465572
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466048
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469638
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464924
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465506
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_36</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465158
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_30</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464840
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464872
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465588
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_53</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465584
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_26</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470360
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_31</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467020
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464924
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465256
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31496558
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466290
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470906
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465088
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_52</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468726
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467750
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_48</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466814
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_51</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467644
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_42</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465294
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466398
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464840
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464878
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468624
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466616
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465052
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467804
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_45</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464954
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_50</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469362
</commentlist>
</thread>
<thread>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#thread_10_03_13_1611248_21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466956
http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467680
</commentlist>
</thread>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.5</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465940
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.15</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465564
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470906
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467618
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466296
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466982
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.3</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465464
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.13</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466956
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469448
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470644
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467680
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.20</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465210
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.9</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464976
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467610
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.7</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465024
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465292
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465774
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467644
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.4</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469656
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.1</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464918
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465214
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465262
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466814
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470360
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466290
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468624
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467020
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466228
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465742
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465866
---http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468824
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466134
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469362
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465572
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465586
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465584
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.2</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465026
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465466
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467694
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465794
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470760
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468138
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.8</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465096
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.6</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465086
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.18</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469242
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.19</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469482
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.0</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465294
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466398
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.12</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464908
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470406
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465088
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465052
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466048
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467804
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467750
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465434
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465744
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465200
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469998
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.23</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465060
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.10</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466836
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470676
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.21</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465150
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.16</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467200
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.24</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464840
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464872
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465588
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467936
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464878
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.14</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464824
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465054
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465520
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466616
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464954
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465062
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465158
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31468726
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31469638
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31467806
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465726
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31496558
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465070
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470430
--http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31470000
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31488020
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.22</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31466930
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.17</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31464924
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465256
-http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465506
</commentlist>
</conversation>
<conversation>
	<id>http://www.semanticweb.org/ontologies/ConversationInstances.owl#conversation10_03_13_1611248.11</id>
	<commentlist>http://www.semanticweb.org/ontologies/ConversationInstances.owl#comment10_03_13_1611248.31465236
</commentlist>
</conversation>
