湘Nyan!のブログ一覧

数万行を超えた制御ソフトにおいて、バグが一つもないということを証明することは不可能のはずなのに、”システムに問題ない”と強気なトヨタ。その自信はどこから！？　こういった発言から品質保証の管理者達はソフトウェア開発に素人ばかりだということが、はっきりとわかります。５０歳を超えた管理者達は若い頃は機械屋さんと入社して、課長職になったころにソフトウェアが車に進出し始めたような年代なので、自分でコーディングしたことなんてないはず。。。もし、少しでも経験していれば、今とは違った対応や発言ができたでしょう。


トヨタの電子システムの信頼性を確認する各種試験装置の充実ぶりにはびっくりします。特にEMC試験装置は、放送局顔負けの電波照射装置を持っていて、耐電磁波対策は万全にみえます。しかし、物理的な確認をいくらしたところで、ソフトウェアが万全だなんて絶対に証明できない。　数年前から、”Vプロセスで信頼性を高める”　だとかいって自社の開発の仕組みを自慢してましたが、結果としてザルだったことを露呈。　充実すべきは設備ではなくて、開発エンジニアの質ですからね、間違えないように。

そもそも設計思想もおかしい。二つのCPUで計算して、不一致だったら減速を優先するとあるが、２つのECUがそれぞれ間違って加速の指令を出してしまったら、どうなるのさ！？
アポロ・ロケットの場合は３つのCPUで計算して多数決で決めていたらしいが、ソフトウェアのバグの場合は、そのような方法では、異常検知はできません。間違った計算をするようにプログラムされていたら、どのCPUも間違った結果しか出しませんから（残念

トヨタは車載コンピュータのソフトウェア信頼性を高める方法を、今一度考え直したほうがよいです。まずは、ソフトウェア開発経験者を品質管理者に指名し、チェック方法を総点検すべきでしょう。

過去起こった様々なことから私が言えるのは１００％完全な車載ソフトは存在しないけれど、それを重大な不具合に結びつかないようにすることは可能です。たとえば、下記のようなことが起こってもね。

・スタックオーバーフローや異常な入力によりプログラムアドレスが不合理に書き換えられ、予期しないPC（プログラムカウンタ）から実行されてしまった場合。
・Cコンパイラーや、不動小数点ライブラリーに致命的なバグがあり、計算結果が大きく狂ってしまった場合。
・多重割り込み等により、想定外に計算時間がかかり、本来セットすべきフラグがセットできず、次のプロセスを開始してしまった場合。
・何らかの原因により周辺のチップからの応答がなかったときの異常処理中に、さらに異常が重なった場合。


不具合には色々ありますが、何が起こってもWINDOWSみたいに暴走させてはいけないのが車載コンピューターシステムです。そういった大切なシステムにもかかわらず、派遣社員や、タイ、ベトナム、インドなど人件費の安さを優先して使って開発してきたことにも、問題があるでしょうね。