Toyota Motor Company -criminal charge
03-24-14, 03:32 PM
#32
Lexus Test Driver
Also, there is absolutely no need for personal attacks or attempted put-downs.
As far as the second highlighted statement, if you're really going to rely on jury decisions to make arguments about science, history is not a very pretty place to look for support for that argument.
03-24-14, 08:01 PM
#34
But he never said the software was not at fault. What he said is that if the software were at fault due to some problem, then the problem could be replicated. This is true, and this has happened in accident investigation before (see, e.g., Aeroflot Flight 593 [wiki article link]).
Also, there is absolutely no need for personal attacks or attempted put-downs.
Please note that the first highlighted statement has already been addressed in this thread by spwolf, namely that negative proof is a logical fallacy. The burden of proof is still on the proponent of the argument.
As far as the second highlighted statement, if you're really going to rely on jury decisions to make arguments about science, history is not a very pretty place to look for support for that argument.
Also, there is absolutely no need for personal attacks or attempted put-downs.
Please note that the first highlighted statement has already been addressed in this thread by spwolf, namely that negative proof is a logical fallacy. The burden of proof is still on the proponent of the argument.
As far as the second highlighted statement, if you're really going to rely on jury decisions to make arguments about science, history is not a very pretty place to look for support for that argument.
If you work in that industry you would be smart enough to not rule that out. It requires the coming of various conditions to make for the perfect storm. Your take is just because we cannot repeat it means it has to be ruled out, and means that nothing is wrong with the software.
Now if you were defending your turf, this argument makes a lot of sense. If you cannot prove it, then it did not happen. This is not the case here. spwolf is not at trial here.
I am expressing my opinion as an experienced professional in this industry. This is very much plausible and I see these cases everyday. Cases where program runs, provides erratic results once in 12 months, and no one is able to replicate it. All it means is that no one is capable of replicating it. My claim to fame has been that I have solved many such issues in my field where everyone simply wrote them off like spwolf has done in this case.
btw, i was merely responding in kind. I do not like to start the trend to put down anybody.
Last edited by chikoo; 03-24-14 at 08:13 PM.
03-24-14, 10:11 PM
#35
Lexus Test Driver
03-25-14, 07:25 AM
#37
Anyways, here are some more thought on bugs in software, from NASA itself
Anyways, I am not claiming Toyota is at fault, nor am I saying that they are not at fault. It is the nature of software, or pushing the boundaries. If we stop advancements, then there shall be no bugs 
. All I am saying is they need to keep an eye on their software, monitor it, and so should we, as the informed consumer.
Future plans for the SPF included incorporating backup system software development, then done at Rockwell, and introducing more automation. NASA managers who experienced both Apollo and the Shuttle realize that the operations software preparation is not enough to keep the brightest minds sufficiently occupied. Only a new project can do that. Therefore, the challenge facing NASA is to automate the SPF, use more existing modules, and free people to work on other tasks. Unfortunately, the Shuttle software still has bugs, some of which are no fault of the flight software developers, but rather because all the tools used in the SPF are not yet mature. One example is the compiler for HAL/S. Just days before the STS-7 flight, in June, 1983, an IBM employee discovered that the latest release of the compiler had a bug in it. A quick check revealed that over 200 flight modules had been modified and recompiled using it. All of those had to be checked for errors before the flight could go. Such problems will continue until the basic flight modules and development tools are no longer constantly subject to change. In the meantime, the accuracy of the Shuttle software is dependent on the stringent testing program conducted by IBM and NASA before each flight.
....
So, despite the well-planned and well-manned verification effort, software bugs exist. Part of the reason is the complexity of the real-time system, and part is because, as one IBM manager said, "we didn't do it up front enough," the "it" being thinking through the program logic and verification schemes153. Aware that effort expended at the early part of a project on quality would be much cheaper and simpler than trying to put quality in toward the end, IBM and NASA tried to do much more at the beginning of the Shuttle software development than in any previous effort, but it still was not enough to ensure perfection.
http://history.nasa.gov/computers/Ch4-5.html
....
So, despite the well-planned and well-manned verification effort, software bugs exist. Part of the reason is the complexity of the real-time system, and part is because, as one IBM manager said, "we didn't do it up front enough," the "it" being thinking through the program logic and verification schemes153. Aware that effort expended at the early part of a project on quality would be much cheaper and simpler than trying to put quality in toward the end, IBM and NASA tried to do much more at the beginning of the Shuttle software development than in any previous effort, but it still was not enough to ensure perfection.
http://history.nasa.gov/computers/Ch4-5.html
. All I am saying is they need to keep an eye on their software, monitor it, and so should we, as the informed consumer.
Thread
Thread Starter
Forum
Replies
Last Post
pagemaster
Car Chat
7
02-26-10 06:34 AM
