Slashdot Mirror
Toyota Raises Concerns About California Self-Driving Oversight, Calls It 'Preposterous' (reuters.com)
A Toyota official on Tuesday raised concerns about California's plans to require compliance with a planned U.S. autonomous vehicle safety check list, calling it "preposterous." Reuters reports:Hilary Cain, director of technology and innovation policy at Toyota Motor North America, criticized California's proposal to require automakers to submit the U.S. National Highway Traffic Safety Administration's (NHTSA) 15-point safety check list before testing vehicles. "If we don't do what's being asked of us voluntarily by NHTSA, we cannot test an automated system in the state of California. That is preposterous and that means testing that is happening today could be halted and that means testing that is about to be started could be delayed," she said at a Capitol Hill forum. On September 30, California unveiled revised rules that carmakers will have to certify that they complied with the 15-point NHTSA assessment instead of self-driving cars being required to be tested by a third-party, as in the original proposal.
After the unintended acceleration fiasco (for which some engineers and management really should have been put to death instead of settling out of court), no one at all should be driving a Toyota, self-driving or otherwise.
Source:
http://www.safetyresearch.net/Library/Bookout_v_Toyota_Barr_REDACTED.pdf
tl;dr:
Here is a list of ways Toyota fucked up:
-Not following appropriate coding style (ie: 'spaghetti'/unmaintainable code, acknowledged by Toyota engineers in internal emails)
-Not following appropriate coding standards (ie: MISRA-C)
-No memory error detection and correction (which they told NASA they had, but "Toyota redacted or suggested redactions that were made in the NASA report almost everywhere the word EDAC appears it's redacted. So someone at Toyota knew that NASA thought that enough to redact from the public that false information.")
-Not mirroring all critical variables (which they initially claimed they did), in particular the critical kernel data structures had no protection, as well as the global throttle variables
-Task X responsible for a retarded amount of work: pedal angle reading, cruise control, throttle position, writing diagnostic troublecodes, failsafes
-Buffer overflows (at least one confirmed)
-Invalid pointers (pointers not checked for validity before being used)
-Existance of race conditions
-Using nested/recursive locks
-Unsafe type casting
-Insufficient parameter checking
-Stack overflows
-Excessive code complexity - 67 functions have cyclomatic complexity (MCC) over 50 (aka -'Untestable') (30 is a typical max), 12 functions have MCC over 100 (aka 'Unmaintainable')
-The function that calculates throttle position is MCC 146 and is 1,300 lines of code (executed by Task X)
-Uses recursive functions, which must not be used in critical applications according to MISRA-C
-Incorrect worst case stack size analysis - Toyota claims worst case usage was 41%, expert found worst case stack usage was 94% *NOT INCLUDING RECURSIVE FUNCTIONS!!!*
-Critical, unprotected kernel structures located directly after stack. IE: if stack overflows, critical kernel data is guaranteed to be lost.
-No runtime stack monitoring to ensure it doesn't overflow
-RTOS (named RX OSEK 850, after the OSEK API/Standards used by many automotive RTOSes) was not actually certified as compliant with the OSEK standard, but used by Toyota anyways
-MISRA-C rule violations (over 100 rules in total). NASA looked at 35 rules and found over 7,000 violations. Expert looked at all rules and found over 80,000 violations.
-Toyota claims their internal coding standards overlap ~50% with MISRA-C, but in reality, only 11 rules overlap. 5 of those rules were violated. In total at least a 3rd of their own internal standards were violated.
-Toyota cannot produce any records of bugs or bug fixing from testing, no bug tracking system was used
-Inadequate/rare/no peer code review
-Over 11,000 global variables
-Totally incorrect ("abysmal") watchdog usage: Run by hardware timer so operates if other parts of CPU are failing, doesn't check that critical tasks are running, throws away error codes sent to it by the OS from other tasks, allows for CPU to overload for 1.5 seconds before reset (a football field @ 60mph).
-Toyota didn't look at or review the monitor CPU code, though they claimed that there could be no software cause for UA
-Monitor CPU had all the requirements (electrical signals coming in and going out, adequate memory, CPU) to monitor brake pedal, throttle and to do something useful if there was a malfunction, but it just wasn't implemented due to lazyness or incompetence
-Many single points of failure
-Their failure mode analysis missed obvious things because they didn't follow any formal safety processes like MISRA
-Mix of Toyota code and Denso code
-"It cost them less to water down the watchdog then to upgrade the CPU to a fast enough CPU"
-If a fault occurs when there is pressure on the brake pedal, then applying further press