兔子特饱 发表于 2013-10-28 03:05

正在看这个证词,CPU好像是NEC.model=V850, ECU是denso开发的..

compiler是green hill的

语言是C

code analysis查出来很多的coding style的毛病(比如用了很多的全局变量等等).

So the code complexity and the McCabe Code Complexity
21  is one of the measures of that. And the code complexity for
22  Toyota's code is very high. There are a large number of
23  functions that are overly complex. By the standard industry
24  metrics some of them are untestable, meaning that it is so
25  complicated a recipe that there is no way to develop a
***** THIS TRANSCRIPT HAS NOT BEEN PROOFREAD *****
66
1  reliable test suite or test methodology to test all the
2  possible things that can happen in it.
3  Some of them are even so complex that they are what
4  is called unmaintainable, which means that if you go in to
5  fix a bug or to make a change, you're likely to create a new
6  bug in the process. Just because your car has the latest
7  version of the firmware -- that is what we call embedded
8  software -- doesn't mean it is safer necessarily than the
9  older one.
10  So the metrics that I see in the source code that I
11  will talk more in specific with you about, they predict that
12  there are many more bugs.

兔子特饱 发表于 2013-10-28 02:56

@今若是

我建议你还是不要买lc了...

Thankfully no. The source code review involves
7  looking at electronic documents on computers. There is
8  basically a room the size of a small hotel room that is
9  disconnected from the Internet, no cell phones allowed
10  inside or would work inside. In that room there is about
11  five computers and some cubicles.
12  In there, it is possible to believe view on the
13  computer screen Toyota's source code. We couldn't take any
14  paper in, take any paper out, couldn't wear belts, watches.
15  There was a guard. It was worse than airport security was
16  on the way here. Each time in and out, even to go to the
17  bathroom.

NASA was brought in to look at source code because
6  NHTSA couldn't get to the heart of the problem, it didn't
7  have any software engineers on staff. So NASA was given
8  access to a few model years of Camry source code, as I
9  understand it, at a Toyota facility in California.
10  They didn't have as much time. They didn't have as
11  many vehicles, and so what we did actually was to build on
12  their work. First, we confirmed that what they were seeing
13  was consistent with what we were seeing, at least for the
14  vehicles that they had, the 2005 Camry was the one they
15  wrote about. And we also dug deeper, and so we pushed on
16  various topic issues researching different aspects of the
17  software design.

And I know we will talk about it in depth as we go
3  along, but did NASA have access to as much information as
4  you ultimately had in reaching conclusions about Toyota
5  software?
6  A No. Even just for the 2005 Toyota Camry we had more
7  documents, we had more source code, we had more things than
8  NASA had.

In a nutshell, the team led by Barr Group found what the NASA team sought but couldn’t find: “a systematic software malfunction in the Main CPU that opens the throttle without operator action and continues to properly control fuel injection and ignition” that is not reliably detected by any fail-safe. To be clear, NASA never concluded software wasn’t at least one of the causes of Toyota’s high complaint rate for unintended acceleration (UA); they just said they weren’t able to find the specific software defect(s) that caused UA. We did.

An Oklahoma County jury found Toyota liable Thursday; later that day, Toyota reached a settlement rather than allowing the jury to decide punitive damages.

A side note: When I was discussing a "Task X" fatality unearthed by the experts, I asked Barr why it's called Task X. Does X mean something specific?

"Ah, that's interesting," he said. "You know, I'm not allowed to say what Task X is." It is one of the dozens of tasks of the 2005 Camry L4 software, and all 24 tasks are meant to run all the time. Under a court agreement, Barr is not allowed to disclose which one is X. When he testified about Task X, the judge had to clear the courtroom, except for the jury.

Wow. The mystery of Task X.

We'll be discussing this case further in news and blogs at EE Times and in technical articles by sister publications, such as EDN and Design News. Stay tuned. Meanwhile, if you know anything about X...

adonishong 发表于 2013-10-28 01:51

memory corruption, 不一定带来崩溃, 至少在原文描述的状况下... 对于一个可靠性很高的系统, 内存中的若干位被破坏, 是不会导致系统失效的, 系统本身应该是可以检测这样的问题, 并且校正错误, 从错误的状态中回到正常的状态中来

"变量对位失序"这六个大字, 不管是六个合体还是两个两个拆开, 变成"变量 对位 失序", 无论用baidu还是用google又或者bing, 都没有搜到他们一起出现过... 所以说奇葩啊. 我本人也了解, 这样一遍又一遍的吐槽, 真的是一个很mean的行为, 我也懂得人艰不拆的道理, 但是, 真的很对不起大家, 这六个大字并排放一起让我实在失去了自控能力, 不得不一遍一遍的吐槽, 不然得被憋死...

BYY 发表于 2013-10-28 01:47

memory corruption不就是内存崩溃么， 换句话说就某一段内存的内容被修改了，而这个修改并非使用这段内存的程序的本意，早期的windows系统内存没有保护经常出这问题。这个中文对应翻译是什么？变量对位失序这个名词我头一次听说，请问对应的英文是什么，狗了一下没看到。

云漫 发表于 2013-10-28 01:23

这个不好说 ，奥迪当年在美国因为Sudden unintended acceleration灰头土脸，那时候可没有软件吧。后来吉普福特等很多车都出过这毛病。最近Tesla也被人控诉这事。

回到这个问题，我猜想，把别的车厂的程序拿来分析，说不定能找出类似的一堆虫子。软件系统实在太复杂了，要没有虫子目前人类没能力做到。

云漫 发表于 2013-10-28 01:23

这个不好说 ，奥迪当年在美国因为Sudden unintended acceleration灰头土脸，那时候可没有软件吧。后来吉普福特等很多车都出过这毛病。最近Tesla也被人控诉这事。

回到这个问题，我猜想，把别的车厂的程序拿来分析，说不定能找出类似的一堆虫子。软件系统实在太复杂了，要没有虫子目前人类没能力做到。

adonishong 发表于 2013-10-28 01:14

巨大防抖, uh... 我看你就别继续你那个说法了, 你这行内人看一眼就知道你不是做底层的, 内存管理压根不是你说的意思, 至于什么"变量对位失序", 这基本上就是一场灾难, 我一个Linux内核开发, 驱动开发干了六七年的人, 其中有两年折腾的就是ECU, 我就压根就没听说过这个词... 你这段话完全就没有解释人家原文说的意思. mcv基本上用了人类可以看懂的语言, 把人家原文说的事儿认真解释了一遍

强劲脚力 发表于 2013-10-27 23:24

说的应该是发动机ECU程序了，这东西说是嵌入式系统也行，我觉得更倾向于单片机，拆开过，看着也真是单片机，这东西的复杂程度远远不到手机系统，就按单片机理解应该没错，它没有一个系统平台，简单说直接就是一段程序，一块ROM放程序及数据表，一块RAM运行程序，所以说到内存管理它都达不到级别，并且比较特别的是软件运行的时候可以直接对某些位操作，事实上是必须对某些位直接操作。

既然是美国码农发现的，估计不是硬件问题，应该是程序问题，栈溢出或者数组越界这种可能性非常小，单片机不像嵌入式系统那样复杂，数据量不大，就那么些可操作内存空间，都能一个个字节数过来，写程序的会非常注意。可能是某些意外情况出现的时候语句非受控地修改了某个关键控制位了，软件出错肯定是丰田责任了，不过，这种问题一旦发现很好解决。

ECU程序主错主要是来源于电磁干扰，汽车上的电磁干扰很严重，启动的时候启动机干扰，行车的时候点火线圈干扰，别的因素影响相对小很高。如果说某次过于高压的点火绕圈放电干扰使ECU某位意外翻转了，然后程序就出错，这种硬件故障都不算什么希奇，错误校验是肯定有的。但如果是程序设计的时候就存在这个隐患，执行的时候就是合理的，则不关校验什么事了，那设计 ...

mcv 发表于 2013-10-27 22:26

注意这个题目“Toyota Case: Single Bit Flip That Killed”。这是文章的重点。

bit-filp error是一个专有名词，指的是存储器内某些位意外的翻转，可以由软件或者硬件造成。single bit-filp，指的是单一bit的翻转，由于软件不直接操作bit，所以软件故障很少造成这个问题，通常是硬件导致的。由于宇宙射线或者材料自身的放射性导致的某些bit意外翻转，这是本质上无法彻底避免的。

文章中尤其提及了“He believes that Toyota's engineers sought to protect numerous variables against software- and hardware-cause corruptions, but they failed to mirror several key critical variables, and they made no hardware protection available against bit flips.”

这里面无论是"mirror"还是"hardware protection available against bit flips"都已经是fail-safe的范畴了。mirror是指关键变量具有多个拷贝，从而避免意外修改。"hardware protection available against bit flips"有很多的方法，最常见的就是ECC，服务器的内存带ECC就是这个原因。

当然我并不是说丰田的内存管理没有问题，栈溢出或者数组越界当然也可能造成“software-cause corruptions”。

但是问题的关键是，丰田对 ...