トヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサス4車種のリコールを決めた。
今回もプリウスのときと同様にソフトウェアの複雑性が絡んだ問題のようだ。
【
レクサスホームページより引用】
レクサスLS460、600hのお客様へのお詫びとお願い
本日、レクサスLSのVGRSに関する報道により、お客様にご心配をお掛けすることになり、申し訳なく存じます。
現在、リコールの準備を進めておりますので、LSのお客様には次の項目に注意して運転していただきますようお願いいたします。
なお準備が整い次第 販売店よりあらためてご連絡申し上げます。
●注意していただく運転状況
・右左折やＵターン等でハンドルを据え切り状態にしたのち、急ハンドルのような素早い戻し操作をすると一部報道されましたハンドルの中立位置ずれが発生しやすいので、急な操作はできるだけ避けていただきますようお願いします。
●運転中にハンドルの中立位置ずれが発生した場合
・車両の進行方向に注意してハンドルを操作するとともに、急な発進や加速は行わないようにお願いします。
・車両が直進状態でハンドルの中立位置がずれていることに気づいた時はハンドルに軽く手を添えていると車両の直進状態に合わせてVGRSシステムが自動的に中立位置ずれを補正（ハンドルが微動しながらズレを修正）します。
・ハンドルを中立位置にしたのに車両が直進状態でないことに気づいた時はハンドル位置に関係なく、車両が直進状態になるようハンドルを操作して いただきますようお願いします。
●当該現象は急ハンドルに相当するような素早い戻し操作をした場合に発生する場合があるものですが、走行中に現象を確かめるような運転は危険ですので絶対におやめください。
2010年5月19日
トヨタ自動車株式会社
【引用終わり】
なお、相変わらず報道各社の情報は問題の本質を分析するための材料となる情報が乏しい。Tech-On! のような技術寄りのサイトが解説してくれるとよいのだが、5/22現在ではこの件に関する記事はなかった。
一番詳しいと思われる記事が毎日jp に載っていた。
【『
トヨタ：レクサスをリコールへ 信頼回復途上に痛手 イメージ低下、不可避』 毎日jp より引用】
トヨタ自動車は19日、ハンドルが一時的にタイヤと連動しなくなる不具合があるとして、レクサスの旗艦車種「LS460」など４車種のリコール（回収・無償修理）を決めた。台数は国内で約4000～4500台、海外分を合わせても１万台余と少ない。しかし、米国を中心に延べ約1000万台に及んだ大規模リコール問題の衝撃がようやく沈静化してきただけに、新たなリコールの発生は、ブランドイメージの低下など痛手となりそうだ。【米川直己】
「信頼回復には、顧客の不安に瞬時に対応する必要がある」－－。トヨタ幹部は、今回のレクサスのリコール決定をそう説明する。一連の大規模リコール問題で、対応の遅れを厳しく批判されたトヨタ。豊田章男社長は再生に向けて「顧客の安心・安全を最優先する」との方針を掲げ、リコールを躊躇（ちゅうちょ）しない姿勢を示している。
ただ、今回、リコールの対象となったのは、高級車ブランド「レクサス」の中でも最上位クラスのLSシリーズ。セダンタイプの「LS600hL」は１台1000万円以上。メルセデス・ベンツなどに対抗するトヨタの看板高級車種だけに、リコール対象台数以上に、富裕層など顧客へのイメージダウンの影響が懸念されそうだ。
リコールの原因となったのは、ハンドル操作と前輪の動きを適切に調整する電子制御装置「ギア比可変ステアリングシステム（VGRS）」。もともとトヨタがベンツなど欧州の高級ブランドに対抗する武器の一つとして導入したものだが、今回はその自慢の高度なハイテク装置に落とし穴があった。
LSのパワーステアリングは電動式で、ハンドルを切るとモーターに熱が発生する。ハンドルをいっぱいまで切った状態を保った場合や、何度もハンドルを切ってモーターが一定以上の熱を持つと、故障を防ぐためVGRSが停止する仕組み。1～2秒でVGRSは再び作動するが、作動前にハンドルを戻し始めると、ハンドルを切る量と実際のタイヤの角度が一致しない状況が一瞬発生する現象が起きた。VGRS作動後はハンドルとタイヤ角度のズレを検知する装置が働き、通常に戻るが、この際のタイムラグが顧客に不安を与えていたという。
今回の問題は通常の運転ではほとんど起こらないといい、トヨタは説明書に注意書きを入れていた。しかし、顧客からの不安の声が相次いだ以上、信頼回復途上のトヨタにはリコール以外の選択肢は無かった。
＝＝＝＝＝＝＝＝＝＝＝＝＝＝
■ことば
◇ギア比可変ステアリングシステム（VGRS）
車の速度に応じてハンドル操作を補助し、前輪の動きを最適に調整する電子制御装置。低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動くようにし、駐車やＵターン時の操作を容易にする。一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能がある。トヨタは02年、SUV「ランドクルーザー100」に初搭載。「クラウンマジェスタ」や「レクサスGS」などにも採用を広げた。
【引用終わり】
断片的に次のような情報も流れている。
トヨタは昨秋、VGRSの制御プログラムを変更。その際に不具合を把握していたが、「安全性には問題がない」として取り扱い説明書への記載で済ませた。しかし、今年3月以降、トヨタに対して12件の苦情が寄せられた。
トヨタ幹部によると、ハンドルが一時的に戻りすぎるのは機構上の特性で、説明書に注意書きも入れていた。しかし「対象の車は戻り方が極端で、顧客に不安を与えてしまった。より運転しやすくするために昨年秋の一部改良でプログラムを変更したことが裏目に出た」と説明している。
「運転しやすくするため、モデルチェンジにあわせてプログラムを改良したのだが…」。トヨタのある幹部は、電子制御の改良が、リコールにつながったことを嘆いた。同時に「機構上の特性」としたことに対する悔恨もにじんだ。
このような情報を総合すると、次のような経緯があったのではないかと予測される。
【レクサスのパワーステアリング問題発生の経緯（予測）】
- メルセデス・ベンツなどに対抗するため、トヨタは低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動き駐車やＵターン時の操作を容易にし、一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能「ギア比可変ステアリングシステム（VGRS）」をレクサスに搭載した。
- VGRSではハンドルを切るとモーターに熱が発生する。ハンドルをいっぱいまで切った状態を保った場合や、何度もハンドルを切ってモーターが一定以上の熱を持つので、熱による故障を防ぐため（ある一定以上の熱を帯びると？）VGRSが停止する。1～2秒でVGRSは再び作動する。
- VGRSが作動前にハンドルを戻し始めると（当初、この行為は取扱説明書上の禁止事項としていた）、ハンドルを切る量と実際のタイヤの角度が一致しない状況が一瞬発生する現象が起きた。
- 2009年の秋にレクサスのモデルチェンジに合わせてより、快適な運転ができるようにVGRSのソフトウェアを変更したところ、3の角度不一致の度合いが大きくなり最大で90度までずれるようになった。（角度のズレは自動的に補正される）
- 今年3月以降12件の苦情が寄せられたため、ソフトウェアを改変（どのような改変かという情報はまだキャッチできていない）し、約4000台の回収に踏み切った。
メーカーは想定されるリスクは軽減のため機器に対して設計上の対策を講じる。しかし、どうしても設計でリスクを回避できないとき、効果効能に対してリスク回避の対策に莫大なコストがかかるようなとき、表記上の対策、すなわち取扱説明書に禁忌事項を掲載したり、機器にラベルを貼ったりしてユーザーに注意を喚起することでリスクを回避する場合もある。
あってはならないのだが、エンジニアが設計上の対策を講じるのが面倒（正確にはそこに注力を注いでいると期限が間に合わない）と考えたとき、「これは表記上の対策にしよう！」と問題に正面からぶつかるのではなく、逃げるケースがある。リスクの度合いにもよるが個人的にこのようなことを自分は絶対に許さない。「何のために、誰のために開発をしているの」か技術者に問うことにしている。
今回のレクサスのパワーステアリングの不具合のケースは表記上の対策で済ませるべきか、設計上の対策まで講じるべきが微妙なところだ。こんなことで、いちいちリコールしていたらたまったもんじゃないと思っている自動車メーカーはたくさんあるはずだ。現に、プリウスのリコールが話題になっていたときあまり大きく取り上げられなかったがいろいろな自動車メーカーが（裏で）リコールをしていた。
トヨタはプリウスのリコールの件で信用を失墜しかけたので、今はグレーでもある一定数のユーザーから黒ではないかと言われたら躊躇せずに「黒でした。設計上の対策を講じます。」というようにしている。
ソフトウェアのリスクとその回避の手段を常に考えている分析者としては、それはやり過ぎではないかと感じている。グレーか黒かの切り分けは、ユーザーリスクの大きさで判断するべきであってユーザーのクレームの強さで判断するべきではないと思う。顧客の感覚は主観的である場合も少なくなく、客観的な判断ができないこともあるからだ。
ただ、このブログでも何度も言っているがソフトウェアの不具合はハードウェアの部品ように故障率のような概念がないため、不具合に至る手順が分かると、確実に不具合を再現することができてしまう。（システマティックエラー）
だから、ユーザーが滅多にやらない行為であっても、「こんな風になります」と実験報道することが簡単にできる。これをやられるとマイナスイメージが瞬く間に広がる。
だからこそ、ソフトウェアが起因する不具合は表記上の対策では片付けられない。ユーザーは許してくれない。滅多にやらないからといって対策を取らなくていい、「発生確率が低いので安心してください」とは言えない。だから、実際に問題が起こってもリスクは小さいと言えるのなら、ユーザーがちょっとだけ不快に思うだけなのなら誠意をもって説明し、不快な気持ちを和らげる努力として何ができるか考えた方がいい。いろいろ考えても、それが設計上の対策になるのならはじめからヤレということになる。
■不具合が発覚したとの組織がエンジニアに取る態度について
今回もプリウスのブレーキのソフトウェア改変のときと同様に、ソフトウェアの複雑性が絡んでいるため問題を分析するとき「ソフトウェアのバグ」「検証し忘れ」などと短絡的に原因を決めつけてはいけない。
ソフトウェア絡みのリコールが発生すると組織内で鬼の首も取ったように「それ見たことか」という態度を取る人たちがいるが、自分はそういう人たちに言いたい。「では、同様の問題がリコールを実施する機種や他の機種にないかどうか調べる方策は考えているのか」「再発防止についてどんなアイディアがあるのか」と。
問題が明らかになってから大騒ぎするのは誰でもできる。ソフトウェア品質保証担当の重要な役目は是正と予防だ。なぜ、そのような問題が起こるのかを分析し、どうすれば今後起こさなくできるのか対策を立案し、実行し、うまくいったかどうかを継続的にウォッチすることがソフトウェアQAには求められる。
■顕在的価値(Real Value)と潜在的価値(Potential Value)のトレードオフ関係
プリウスのブレーキにせよ、レクサスのパワーステアリングにせよ、問題の原因には、ユーザー要求の多様化とソフトウェアの複雑化のトレードオフが関係していると思っている。『
組込みソフトエンジニアを極める』でも『
リコールを起こさないソフトウェアのつくり方』でも、組込み機器にはカタログに載せるような「顕在的価値(Real Value)」と、ユーザーが当たり前に確保されていると思っている「潜在的価値(Potential Value)」の両方の価値が存在し、そのバランスが保たれていないと長い目で見たときに顧客から信頼を得て高い業績を上げることはできないと書いた。
簡単に言えば、ユーザー要求は多様かつ複雑になっているので、その多様性や複雑性に起因する顕在的価値をソフトウェアで実現しようとすると、やり方によっては潜在的な価値が下がってしまう可能性があるということだ。
通常はその2つは、トレードオフの関係にある。多用で複雑なものが当たり前に動くことを実証するのは難しい。だから、安全や信頼が求められる潜在的価値の高い機能や性能は、多用で複雑にはせず、多用で複雑なものは安全や信頼とは切り離しておく方がよい。カーナビのように多用で複雑なものは安全や信頼と切り離しておかないと危ない。
■ギア比可変ステアリングシステム（VGRS）は顧客にとってどんな価値がある？
そこでまずは、ギア比可変ステアリングシステム（VGRS）の顕在的価値について考えてみたい。
<ギア比可変ステアリングシステム（VGRS）のポイント>
- 低速走行時には、ハンドルを少し切るだけで前輪が左右に大きく動くようにし、駐車やＵターン時の操作を容易にする。
- 一方、高速走行時にはハンドルを動かす角度に対する前輪の動きを小さくし、急ハンドルによるスピンなどを回避する機能がある。
- レクサスやクラウン、マークXなどの一部に採用しており、高級車としての差別化を図るために採用した機能だと思われる。
さて、上記の機能、性能は顧客満足にどれくらい貢献しているといえるだろうか。分析にはQFD（品質機能展開＝
組込みプレス Vol.8 の特集記事参照のこと）を使うとよいのだが、まあ、普通に考えて他社と差別化するための付け足しの機能、性能であり、車としての本質的な機能や性能ではないことは明らかだ。個人的にはパワーステアリングが基本的な機能だけあれば十分ではないかと思う。
そして問題は、この付け足しの機能を実現するためにソフトウェアが複雑化し、ハンドルが曲がっている状態で直進してしまうという、車としての基本機能を損なう問題を埋め込んでしまったという点だ。基本使用における安全性は確保されていようだが、0.1%の品質にこだわるトヨタとしてはユーザーに不安を与える可能性があるので回収を決めた。
トヨタは今後、検査態勢を強化することで再発を防止するとニュースサイトに書かれていたが、それは本質的な改善策にはならないと思っている。なぜなら、これほどに複雑化したソフトウェアシステムを完全に検査するためのテストケースは爆発的に増えてしまっており、テストケースと結果が妥当かどうかを完全に検証していたら設計するときよりも時間がかかってしまうからだ。
検査で何とかなると考えていること自体、21世紀のソフトウェアシステムの品質管理の概念ではない。Verification（検証）でソフトウェアの完全性を追い込めるのは規模や複雑性が小さいときだけであり、10万行を超えるサブシステム、そして、サブシステム同士が相互の作用しあって動くシステムでは、Verification（検証）は安全や信頼の確率を高める効果でしかなく、絶対に安全である、信頼できるというお墨付きは出せない。
それを理解した上で、いかにユーザーリスクを受容できレベルまで引き下げるかという取り組みがSoftware Validation（妥当性確認）である。
■大規模複雑化したソフトウェアシステムの潜在的価値を高めるには
トヨタのみならず、多くの組込み機器メーカーの組織上層部は複雑化したソフトウェアの怖さ、当たり前にできていることの価値、すなわち潜在的価値(Potential Value）を高くキープすることも難しさを認識できていない。
そして、他社と商品を差別化する際に部品代がかからないからという理由ではソフトウェアによる機能追加を考える。それにより潜在的価値が犯される可能性など予想もしないし、不具合が発見されるとそれはプログラマのうっかりミスと決めつけられる。それで不具合の発生する確率が下がるのならいいが、ソフトウェアの規模が大きくなるにつれ、逆に確率は上がっていくだろう。
多くの組込み機器の開発に関わる組織は当たり前にできていることの価値、すなわち潜在的価値(Potential Value）を過小評価している。というよりは、細かい顕在的価値(Real Value）を積み重ねることでシステムが複雑化し、そのことによって当たり前に出来ていることに問題が起こることを想定できていない。
特にトヨタはその認識が不足しているのではないかと思う。それはなぜかと言えば、これまでは徹底的に顧客要求のチューニングのためにソフトウェアを変更しまくることで、98%の顧客満足度を0.1%刻みで100%に近づけることに成功してきており、その成功体験がリスクを見えなくしていると思うからだ。
トヨタはユーザーの使用環境を想定したソフトウェアのシステムテストとソフトウェア部品を供給するサプライヤーに対する厳しい検証要求で問題を潰しきれると思ってはいないだろうか。
日本のたたき上げの組込み機器産業ではよく見られる光景だ。顧客満足を高めるために尽力を注ぐことは正しい。しかし、ユーザーが当然できていると思っていること、すなわち安全や信頼がシステムが複雑になることで脅かされるリスクについてはみな鈍感だ。
理由は簡単。日本のたたき上げの組込み機器産業の組織上位層はソフトウェアはハードウェアを制御するつなぎ役として長い間見てきており、現在のように巨大化して複雑になったソフトウェアシステムに内在する爆弾の怖さを実感できていないからだ。
爆弾をサプライヤの管理とカイゼンの積み重ねでつぶせると思っているのなら、それは間違いであり、MISRA SA（『
リコールを起こさないソフトウェアのつくり方』のAppendix B に概要を書いた）をよく読んだ方がよい。安全は上流の要求分析とアーキテクチャで押さえ込まなければならない時代になっている。
安全なアーキテクチャ、基本機能が脅かされない信頼性の高いアーキテクチャでソフトウェアが設計されているかどうかをソフトウェア開発の上流で検証する必要がある。それをせずにすり合わせ的手法、付け足し手法でソフトウェアを作って、徹底的にテストで爆弾を見つけようとしてもムリである。
■シンプルデザインの価値とは？
シンプルデザインの価値は有限なテストケースで Validation ができるということだ。一流の職人（ソフトウェア技術者）はシンプルなアーキテクチャを評価できるが、セールスマン、マーケットプランナーは一流でも、シンプルなアーキテクチャを評価できない。要求を実現できれば、シンプルなデザインになっているかどうかは気にしない。ソフトウェアの見えなさの弊害だ。
安全や信頼だ求められるソフトウェアはシンプルなアーキテクチャで潜在的価値を最大にする。どうしても複雑にならざるを得ないときは0.1%の表面的な顧客満足度よりも、数10%の潜在的価値＝当たり前品質につながるシンプルアーキテクチャの方を取る。それができるのは、数々のものづくりを経験してきた職人（＝システムアーキテクト）だけだ。
顧客の要求を取り入れメーカーが自分でアーキテクチャを設計せず、サプライヤーにものづくりを任せて何年もたつとその感覚はどこかに飛んでしまう。
自分はクルマ屋さんは頼むからカーナビとブレーキの機能を連動させるような複雑なシステムを作らないで欲しいと思う。時代は進化しているから、新しい機能がないとユーザーが買ってくれないからといって、システムを複雑にし、わざわざリスクを盛り込んでいったらシステムアーキテクチャはシンプルデザインとは言えなくなってしまうのではないか。（洗練されたアーキテクチャで、安全と複雑性の高い要求を実現できていると言えるようなら脱帽だが、本当にそうなっているだろうか）
真の銘品には洗練された美しさがあり、経験を積んだ仕事人はそれをかぎ分けることができるのだが、ソフトウェアは見えないからそう簡単にはいかない。できるといっていることが多用で複雑で使いそうにもない機能満載の場合、怪しいと感じる。
一時の快楽＝おいしいカタログのうたい文句が顧客に効き、売り上げに貢献するのは最初だけであり、潜在的な価値のよさは長年使い込んだ時にはじめてユーザーに理解され、そして、それが理解されるとユーザーはそのブランドやメーカーのファンになる。長く惚れ込んでくれるファンを増やすためには、シンプルなアーキテクチャが美しいと感じる感性と、複雑よりもシンプルを選択する組織の分析力、決断力がいる。
フィールドで問題が起こったときメーカーはサプライヤに「コラー！なんてことしてくれたんだ！」と言っているだけではダメで、ユーザーニーズと安全が確保できるアーキテクチャであるかどうかを判断できなければいけない。そのためには自分自身でものづくりを主導し続けなければいけない。サプライヤーから提供された部品を組み合わせているだけでは安全アーキテクチャができているかどうかを見極めるスキルはつかない。
アーキテクチャの分析能力が大事であり、くるまドメインの方は、まずは、MISRA SA（Safety Analysis）を読むとよいと思う。
）
先日、コメントを書かせて頂きました『自動車エンジニア』です。
また、コメントさせて頂きます。
-----------------------------------
プラットフォームの共通化・モデル駆動開発ということばに踊らされて、商品の価値を高めることができるという確信がないままに、共通プラットフォームを採用してしまうと後々商品開発の基盤をプラットフォーム提供者に握られてしまうことに気がつく。
----------------------------------
確かにそのとおりだと思います。
自動車業界でいうと、モデルベース開発がMATLABという１つのツールに依存しすぎると、ツールベンダーに主導権を握られるリスク当然はあります。
実際そうなりつつありますが...
MathWorksがマイクロソフト状態にならないように、MAAB、J-MAABなんかでも、MathWorksにソフト改良への要求などを（強気に?）行って、かなり牽制しようとしてますが...
デンソーなんかは、ツールベンダーに依存しなくてよいような方向を志向しているのかどうかわかりませんが、最近はプラットフォーム環境を内製化しようとしてしいる感じは、各公演等から感じられます。
トヨタでも同じようなことは考えられているかもしれません。
----------------------------------
重松氏の話を聞いていてトヨタは自前で自動車のソフトウェア全部を作り上げるつもりはないように聞こえた。サプライヤからのソフトウェア供給は今後も続くという考えのようだ。
----------------------------------
参考までに、トヨタは自前で組み込み用のＯＳの開発を行っているようです
あくまで、メディアの情報です。
【トヨタ、「クルマＯＳ」独自開発】
【50人体制の開発組織・トヨタ正発表】
【経済産業省、車載標準OSを開発へ--トヨタや日産らが参加】
トヨタも現状は、サプライヤーにソフトの供給を依存しているかもしれませんが、もしかしたら、将来的に自前でいくことも考えているのかしれませんね。
ただ、本当の戦略？？です
-----------------------------------
これはかなり危ない。車や鉄道の特性やリスクを知らない、意識しない技術者が作ったソフトウェアは間違いなく危ない。その機器が使われる場面においてどんな危険やリスクがあるのか知らないツールメーカのツールやプラットフォームも危ない。
----------------------------------
自動車業界にいる者として、真摯にご指摘を受け止めなければなならないと思います。
現状、車メーカー側には組み込みのエキスパートは少ないように感じます。
いくつかの車メーカーはグループ内にＥＣＵメーカーをもっていて、組み込みは子会社のＥＣＵメーカーに任せて、車メーカーはシステムのアルゴリズム開発に注力するという方向かもしれませんが、それが、大問題の原因になるとのご指摘かと思います。
車メーカー：組み込みの素人、制御アルゴリズムや車両の特性には詳しく、ロジック開発のみやる
⇒どんどん、組み込みに疎くなる。
⇒【組み込み技術】と【制御ロジック/制御対象特性】の両方を把握するエンジニアがいなくなる。
システム/組み込み開発で全体を把握でる人がいなくなり、部分分のみの知識/経験しかない人だけになると絶望的になる。
さらに、自動車の特性に関する知識に疎いツールベンダーが、人命を預かって走る車において、ＥＣＵの組み込みの根幹を握るようにると、さらに怖いというご指摘かと思います。
（間違っていたらご容赦ください）
車メーカー側は組み込み技術の向上（組み込みエンジニアの育成も含めて）を真剣に考えていかなければいけなかと思います。
最後は車メーカーが全ての責任をとらなければいけませんので、組み込みＥＣＵの責任も最後は車メーカーが持たなければなりません。
私も、組み込みに関する知識不足を痛感しています。
最近、組み込み関連の本を何冊か購入して勉強していますが...
『組込みソフトエンジニアを極める』も今、読ませて頂いております！
ＥＣＵメーカーの組み込みエンジニアとも情報交換及び、今後のシステム/組み込み開発のやり方を議論する場なども定期的にもっていたりします。
----------------------------------
こういうのにコロッとやられてしまう鴨ネギタイプのエンジニアやマネージャは組織の中に必ずひとりやふたりはいるものだ。
----------------------------------
私もそんな１人ですね（笑）
ベンダーの営業トーク（いいことしか言わない）によくコロッといったりします（笑）
9月 08, 2007
自動車エンジニアさん、コメントありがとうございます。
自動車エンジニアさんは本当に自動車のソフトウェア開発にお詳しいですね。
自動車のソフトウェア安全については、ISO 26262 の策定が進んでいると思いますが、ソフトウェアの安全性を分析する考え方として MISRA-SA というのもあります。
どっちにしても、ソフトウェアの安全性は電気的安全性のようにはっきりと白黒つけることは難しいので、エンジニアがどれだけ客観的な根拠・証拠をもってシステムの安全性や信頼性を証明できるかどうかにかかっていると思います。
自動車ソフトウェアの安全性は、これまでソフトウェアエンジニアがユーザーの要求や機器のメカニズムを熟知しており、どんな風に使われるのか、どんな風に ハードソフトが動くのか知っていてソフトウェアを作っているということで担保されていた部分が大きかったと思いますが、これからは誰がどんなソフトウェア を作り込んでしまうか分からないという前提で、ソフトウェアの安全性や信頼性が確保されていることを客観的に示していかないといけないと思います。
モデルベース開発は安全を客観的に示すための有力な方策の一つだと思いますが、モデル変換のソフトウェアを作っているエンジニアが特に車のメカニズムを意識していない場合、意図しない洩れや抜けにより変なコードが埋め込まれてしまう可能性はあると思います。
ただ、「理系白書から考えるソフトウェア工学」で書いたように、モデルベース開発が自然科学を相手にしているうちは正しく変換できているという信頼性をVerification（検証）することは難しくないと思います。
しかし、自然科学以外のすり合わせ的ソフトウェアアーキテクチャをモデル駆動開発に取り込んでいった場合は、信頼性の証明やシステム全体のValidation（妥当性確認）は難しくなってくると予想します。
組織内部の Closed のすり合わせ的アーキテクチャ・アルゴリズムの安全性や信頼性は、そのハード・ソフトが使われる場面や要求を実現するメカニズムを熟知しているソフトウェ アエンジニアの「慎重さ」「そのソフトウェアが安全を担っているという使命感」のようなものが確保していたのが本当のところでしょう。（要求通りに作られ ているかどうかを検証するのは Verification です）
これからは、その安全アーキテクチャ、安全ソフトウェアをカプセル化して、他の安全クラスの低いソフトウェアから隔離し、影響を受けにくいソフトウェアの構造を作っていかないといけないと思います。
これは ECUが物理的に分かれていることで責任分担され証明しやすかった状態に比べると、自信を持って「安全です」と言えるところまで持っていくのに時間も手間やソフトウェア的工夫もいるだろうと予想しています。
自分は自動車ドメインのエンジニアではありませんが、このブログでもその方策について考えていきたいと思います。
9月 08, 2007