シナリオ1 電気自動車時代の不具合
2020年、電気自動車用の充電プラグは家庭やコンビニエンスストアにも普及が進み、郊外には電気スタンドもよく見かけるようになってきた。充電場所が増えるにつれて、それまで聞いたこともない電気自動車メーカー、ブランドの車も数多く現れてきた。電気自動車の販売価格帯は二極化しており、老舗の自動車メーカーの150万円以上のブランド車と、アジアのメーカーの100万円以下の車に人気が集中している。低価格電気自動車は安いものなら50～60万円で買えるようになり、都心の若い世代ではこのような低価格電気自動車を個人で購入するのではなく、電気自動車がシェアカーとして用意されているマンションを選ぶようになってきた。電気自動車の普及の裏で、困っているのは自動車の新規登録を許可している日本の規制当局だ。申請数が多すぎて数をさばききれない。かといって5年前に締結されたTPP協定によって、外国メーカーの自動車の新規登録が遅れると協定違反となって国際司法裁判所に提訴されるようになったから、手続きを遅らせる訳にはいかない。だから手続きは粛々とこなしていかなければならない。職員は増やしたが経験が追いついていないため、細かい見落としはどうしても増えている。
許認可の問題だけでなく、新規参入の自動車メーカーが作った自動車そのものの不具合が原因の事故も確実に増えている。電子制御のブレーキが突然効かなくなる、アクセルが急加速する、モータが急停止するといった、日本の自動車メーカーが起こしたらトップニュースになるような不具合が当たり前のように起こるようになった。電気自動車では部品をサプライヤから買い集めて組み合わせるだけで簡単に完成品ができるようになり、自動車ドメインでの経験をほとんど持っていない企業の電気自動車製造販売の参入が急増したことが原因だ。アセンブリメーカーはできるだけ安く自動車を作ることが使命であるため、もっとも安くECUを供給できるサプライヤからハード、ソフトを買う。自動車業界ではプラットフォームの共通化が進んだことで、どこのECUを買ってきても表面上は問題なく動くようになった。非常にわかりにくいソフトウェアに起因した不具合があることなど気にもせず、新規参入のアセンブリメーカーは安いECUを供給するサプライヤに次々と切り替えるため、これまで発生していなかった問題がECUの切り替えとともに突然起こったりする。
自動車のソフトウェアの作り方がすり合わせから組み合わせに変わり、規格化された共通インタフェースの部品を共通プラットフォームに接続することで基本的な電気自動車の機能が実現できるようになった。しかし、一つ一つの部品を一から作ったことがない、それどころか一つ一つのデバイスの性能限界もよく分かっていないアセンブリメーカーには、突然発生したソフトウェア制御のブレーキの誤動作やアクセルの急加速といった原因がまったく分からないし、何をどうやって調べればよいのか見当もつかない。したがって、このような原因不明の事故を起こした新規参入の自動車メーカーの車は、最近、日本では急速に販売数を減らしている。日本でも自動車雑誌にリコール情報の分析データがワーストランキングと共に掲載されるようになった。一方アジアの国々では、それでも低価格の電気自動車はまだ人気がある。
事故を起こしたメーカーも ISO 26262 適合というフレコミのECUを使っていた。アセンブリメーカー自身もISO 26262 のプロセス認定を受けている。それでも事故が起こるのはシステム全体に対する安全管理ができていなかったからなのだ。日本の自動車メーカーが当然のようにできていた不具合の原因追及や再発防止策の立案、継続的な改善活動が新規参入のアセンブリメーカーにはできない。しかし、だからといってアセンブリメーカーを市場から排除しようとすると非関税障壁だと訴えられてしまう。そうなると日本の消費者は自分の安全を自分で守るしかなくなる。事故情報を分析することで自動車の価格と自分の安全を天秤にかけるしかない。家庭電化製品と同じように消費者はまず、自動車の安全情報のサイトで事故情報と既存ユーザーの評判をじっくり読んでから、販売店に向かうようになった。2020年、自動車は選択を誤ると安心して運転できない恐ろしい乗り物になった。
シナリオ2 高級車に搭載するインテリジェンス安全機能の落とし穴
 |
| 早いスピードには危険が伴う |
しかし、それだけではライバルメーカーとの競争に勝てないため、自動車の安全性を新しい機能という目に見える形で表し、テレビコマーシャルで宣伝する作戦に出る。例えば、ナビゲーションシステムとブレーキの連動機能だ。
老舗の自動車会社Aは飛躍的に進化したVICSからの情報を使い、車一台一台の正確でリアルタイムな移動情報とナビゲーションシステムを融合させて、これまでにない安全機能を新たな売りとすることにした。前方に迫る十字路をナビゲーションシステムで認知し、左右から来る自動車の存在と速度を進化したVICSの情報から得て、直進する自分の車が横からくる車に追突されそうになったときには信号の赤青にかかわらずブレーキが自動的にかかる機能をナビゲーションシステムのサプライヤと共同開発した。この機能が正しく機能すれば十字路での衝突事故を避けられるようになる。
40代の会社経営者のBは1年前にこの新しい安全機能を搭載した車をA社の販売店から購入した。このオプション機能の搭載により購入価格は50万円もアップしたが、命には代えられない。Bは前の車に乗っていたとき、黄色信号が終わりかけの交差点に高速で進入し、横からきた車と接触事故を起こしそうになった経験がある。その後、家族と会社の部下から、自分一人の命ではないのだから本当に気をつけてくれと言われていたのだ。
この新しい機能があれば、左右がよく見えない信号のない交差点でも安心だ。交差点の手前で速度を落とさなくても、スッーと安全に通過できる。危ないときはこの車が自動的にブレーキをかけてくれるのだ。
その日Bは深夜、午前3時に県道を飛ばしていた。前日の夕方、翌日から始まる自社商品のイベントの準備でトラブルが発生し、急遽自ら陣頭指揮を執り問題の解決にあたらなければならなくなった。トラブルが解決し、イベントの準備がすべてが終わったのが午前2時半だった。眠いし早く家に帰って少しでも多く睡眠を取りたい。郊外の家に着くまであと5キロ。車の通りもほとんどなくなって、車は制限速度を30キロもオーバーしていた。「ああ、交差点の信号が黄色から赤に変わりかけている。」「でも、セーフティ機能があるからぶつかりそうになればブレーキがかかるし、ここはアクセル全開だ。」
その数秒後、交差点に入った瞬間にちょうど青信号になったばかりの左側の道路からきたCが運転する軽自動車に側面衝突した。Bの車のセーフティ機能は働かなかった。
この事故でBとCは大けがをした。もちろんBの信号無視が原因だった。その後自動車会社Aはなぜこの事故が発生したのか原因を突き止めるために、ECUとナビゲーションシステムに記録されていたデータログを徹底的に解析した。
原因は その日のその時間、VICSシステムがメインテナンスのため5時間ほど機能を停止しており、その情報にBが気がついていなかったからだということが分かった。実はナビゲーションシステムの取り扱い説明書にはこのことは注意として書かれており、実際VICSシステムの稼働中アイコンもそのときはナビの画面から消えていた。これまでBはVICSシステムの情報受信のアイコンなど気に留めたことなどなかった。
この件について、自動車会社Aがナビゲーションシステムの供給会社Dに厳しく問いただしたところ「何も間違った情報は送っていない。VICSが稼働中かどうかのステータスは正しく表示しているし、ブレーキシステムにも通信している。取り扱い説明書で表記上の対策もしている、できることはすべてやっているので我が社には過失はないと考えている。」という回答が返ってきた。
自動車会社Aのチーフエンジニアは頭を抱えた。これまでこんなことが起きたことはなかった。ブレーキシステムを担当するサプライヤはその機能と性能を隅々まで把握し、エンドユーザーに対して責任を感じながら完璧な仕事をしてきた。ところが、新しいセーフティ機能を次々に加えていった結果、自動車の安全機能がどんなときにも期待通りに働くのかどうか自信が持てなくなってきた。誰に聞いたら確信が持てるのか分からなくなってきた。それほど、システムは複雑化している。
昔の車作りのチームなら、VICSのサービスが提供されないことのリスクがどんなハザードにつながるのかチーフエンジニアの自分が気がつかなくても、誰かが気がついて対策を取っていた。それが今ではできなくなっている。リスクを分析して一つ一つのハザードに対するリスクコントロールの実装を確認していかないと、安全機能に関する確証が持てない。確実に自動車の作り方は変わってしまった。いや、変えないと安全な自動車を提供できなくなったのだ。事故が起こるたびに何十年もかけて築いてきた信用ががた落ちになる。10年前に導入した ISO 26262 は役に立たない形式的なものだと思っていたが、今初めて真剣に取り組まなければいけないと実感した。
2つのシナリオから考える自動車ソフトウェアの未来予想図
 |
| 車には子供が乗っているかもしれない |
また、欧米のやり方でこれまでの日本製品の品質が実現できるわけではないので、欧米の要求を日本向けにテーラリングしないといけないのに、日本人はそれが大の苦手ときている。
一番目のシナリオは電気自動車の普及にともない部品の組み合わせで自動車ができてしまうという話だった。ブラックボックスの部品の組み合わせで自動車が作られてしまうことで、システム全体としての安全が脅かされるという話は、共通プラットフォーム化、ECUの共通インタフェース化が進めば絶対に増加する。
中身が分からないブラックボックスのソフトウェア部品をハードウェア部品と同じ取り替え可能な部品として使い始めたら不具合は減らない。ISO 26262 への適合を目安にすることはできるが、ISO 26262 の要求に沿って作りましたという ECU ではリスクを回避できない。なぜなら、ISO 26262 はリスク分析の結果から考えたリスクコントロール手段をセーフティマネージャ（自動車メーカー）がサプライヤに要求し、安全を管理することでリスクを回避する。システム全体のリスクを分析しないで、お墨付きがあると差し出された ECU はそもそも想定されたリスクを受容できるまで低減できているという担保がない。どんな事故が起こる可能性があるかを分析しないで、オールマイティなセーフティ機能を実装することはできない。すべてのリスクに効果のあるリスクコントロール手段などない。危ない時に制御を止めなければいけないケースと動かし続けなければならないケースはどちらも存在する。だから、サプライヤだけではリスク分析はできないのだ。人や組織も含めた安全管理やシステム全体のリスク分析抜きに、ソフトウェアをハードウェアと同じように代替えできる部品と考えたら、その時点で安全は脅かされる。そのことにどれだけの自動車メーカーやサプライヤが気づいているかが心配だ。
二番目のシナリオは、安全機能を複雑化させたために起こるディスコミュニケーションの悪影響の結果だ。全体を見通せなくなった時点で古い日本の安全確保の方法論は力を失っていく。しかし、プロセスアプローチだけで安全が確保できるわけではないので、日本のプロジェクト向けの安全へのアプローチを規格をテーラリングしながら考えなければいけない。
このことは、CMMIのレベル5を取った、取らないといった話とは次元が全く違う。CMMI のレベル5を取った組織が、ソフトウェアの不具合を起こしたとしてもクライアントから嫌みを言われるだけだろう。CMMIは営業が仕事を取るための道具にはなっても、プロダクトアウトしたソフトウェアの信頼の証にはならない。
しかし、ISO 26262 への適合は安全や信頼の指標にならなければこの規格ができた意味がない。そうでなければ技術者が苦労して規格に適合するために積み重ねた努力が無駄になる。そして、規格適合が形骸化すれば上記のシナリオのように事故が起きたり人が死んだりするかもしれない。消費者から嫌みを言われて終わるレベルの話ではない。真剣に取り組まなければ人の命に関わる可能性があるのだ。
そういう気持ちを持ってエンジニアは規格適合に取り組んで欲しいと思っている。このことは自動車ドメインのエンジニアだけでなく、リスクを抱えた製品、クリティカルな製品に携わっているすべてのエンジニアに言いたい。2011年3月に日本で発生確率が極めて低いが、発生したときの被害の重大度が極めて大きい事故が起こった。リスクの大きさ = 発生確率 × 被害の重大度 という従来の安全工学の考え方を見直さなければいけないかもしれない。（ISO 26262ではハザードの評価において、発生確率と被害の重大度に加え、回避可能性の要素が考慮されている。）
被害の重大度が大きければ、ppmオーダーでもリスクは大きいと考えなければいけないのではないだろうか。また、発生確率が予測できないソフトウェアの不具合の場合、どうやってリスクを制御すればいいのかソフトウェアエンジニアが真剣に考えなければ、誰が安全な製品を作れるのだろうか。
あんな事故があっただけに、2012年、エンジニアはどうすれば事故の再発を防止できるのか、これから起こるかもしれない事故を未然に防ぐことができるのか、自分達の技術は事故の予防や再発防止のどのように役立つのかをよく考えて、安全という同じ目標、同じ価値観をもって日々の仕事に取り組む義務があると考えている。
ISO 26262-1:2011 Part1 Vocabulary(用語の定義）
 |
| ISO 26262-1 Part1 Vocabulary（用語の定義） |
そのような箇所を見つけられた方は是非連絡をして欲しい。多くの人のチェックを経て完成度を高めていきたいと思う。また、本資料を利用される方は 常にバージョンを確認して欲しい。間違いに気がついたら修正を加えてバージョンを上げていくつもりだからだ。
さて、142の用語を邦訳しながらあることに気がついた。それは、これらの用語はつぎの3種類に分類できるということだ。
【ISO 26262-1 で定義されている用語の分類】
- 安全・品質工学、規格適合に関する用語（43語）
- ソフトウェア工学に関する用語（30語）
- 自動車ドメインまたはISO26262特有の用語（69語）
分類は主観によるものなので異論もあるかと思うが、カウントしたら1が43語、2が30語、3が69語あった。これが示すことは何か読者の皆さんは分かるだろうか。
それは、ISO 26262 という規格は、安全工学・品質工学または国際規格への適合に関する知識を有する者、ソフトウェア工学の知識を有する者、自動車ドメインに造詣が深いまたはISO 26262 の規格策定に関わった者の3者が互いに協力しないと完全には理解できないということである。
 |
| ソフトウェア工学だけではダメだ |
よって、ISO 26262 に本気で取り組もうと思ったら、この3者が一つの目的、一つの目標に向かって協力しなければダメだ。それぞれの専門家が自分の強みを主張して、自分の専門分野に相手を引き込もうとしたり、相手が自分の専門領域のことを知らないことを「そんなことも知らないのか」と心の中で馬鹿にし出したりしたら、バラバラになって空中分解する。ついでに言うと、それまで知らなかったことを新しく知ったことで知ったかぶりをする者が出てきても調和は乱れる。
3者のディスコミュニケーションは相手が認知していない言葉を意識しないで使い始めたときから始まる。自分が知っている言葉を相手が知っているかどうか考えながらしゃべれる人は、主観と客観を自在に操れる人であり、世の中にそれほど多くは存在しない。ほとんどの人は自分が知っている言葉は相手も知っていると思って話をしてしまう。そして、日本人は奥ゆかしいから分からない言葉が出てきたところで、「その言葉の意味が分からないから教えて欲しい」となかなか言わない。
さて、コミュニケーションギャップの可能性を ISO 26262 の用語の例で考えて見よう。例えば、anomaly（異常）、 harm（危害）、 hazard（ハザード）、 severity（重大度）といって何のことだか、ソフトウェア工学や自動車ドメインの専門家はピンとくるだろうか。また、partitioning（パーティショニング）、baseline（ベースライン）、branch coverage（分岐カバレッジ）、 walk-through（ウォークスルー）について、規格適合コンサルタントはその意味を説明できるだろうか。また、ASILデコンンポジション、exposure（暴露）、redundancy（冗長性）について、正確に解説できる者はいるだろうか。
ちなみに、自分は最初の二群はキチンと説明できるが、最後の自動車ドメインや ISO 26262 特有の用語については自信がないところもある。
このように、分からない言葉が出てでて、そのままにしてしまうと人間は思考を停止してしまったり、自分の勝手な思い込みで解釈してしまったり、そもそも自分の専門分野でない、担当分野でないと考えることを放棄してしまったりする傾向がある。
そのような状況が現れ出すと、それは冒頭で紹介したシナリオ1やシナリオ2が始まったことを示す。ISO 26262-1 の用語集が示しているのは、この規格は3つの専門領域を合わせないと規格が目指している目標を達成できないということなのだ。セーフティマネージャが3つの領域を完全に理解することは難しいだろうが、それぞれの領域の担当は他の領域の知識を学習して、より多くのオーバーラップを持つことが求められる。そして、大事なのは安全という共通の目的、安全を確保するというエンドユーザにとっての価値を共通認識とすることだ。
自動車ドメインの場合は、上記の3つの専門領域の区分けとは別に、自動車メーカーとサプライヤという立場があるため、問題はより複雑であり、共通の目的、共通の価値観を持って規格への適合を達成するのはさらに困難を極めると予想される。
自分が考えるうまくいくシナリオは、はやり自動車メーカーにしてもサプライヤにしても、自動車ドメインの技術者が安全工学、品質工学、ソフトウェア工学について学習を重ね、それぞれの専門家からアドバイスをもらいながらも自分達が主導権を取って規格適合を進めていくという流れだ。なぜなら、規格適合を監査する者やプロセスコンサルタントは、なんだかんだ言っても自分達の仕事がエンドユーザーの命に関わっているとは考えていないだろうし、エンドユーザーの命に対してなんら責任もないからだ。しかし、自動車メーカーのエンジニアと、安全に関わるソフトウェア、ハードウェアを納品するサプライヤは違う。自分達には安全に関わる機能・性能に対して責任があると認識して仕事をしているだろう。何か事故が起これば他人からも責められるし、自分自身も責めてしまうのが日本のメーカーとサプライヤのエンジニアだ。その責任の範疇の中にいるのか外にいるのかの差はとてつもなく大きい。中にいる者は人の命を背負っているが、外にいる者はそこまでの責任は感じていない。
別な言い方をすると、そのような責任感が品質の向上に寄与するようなやり方を脱するために作られたのが ISO 26262 なのだが、現実には品質を心配する意識とプロセスアプローチの両方がないと安全は確保出来ないというのが自分の考えだ。ISO 26262 の形骸化が始まったら、安全の確保は危うくなると思っている。
規格適合は役に立たないと考えずに、たましいを入れて取り組くむには、ひとつ見方を変えればよい。ISO 26262 の適合という機会は、自分自身の幅を広げるまたとないチャンスだと考えればよいのだ。自分がブログサイトでこの特集記事を書いているのは、読んでくれる読者がいるからだけれども、それにもまして記事を書くことが自分自身の知識の幅を広げることにつながり、結果的には自分のドメインでも役に立つし、それまで気がついていなかったことがたくさんでてくることが分かっているからだ。
実際、ISO 26262 の用語の定義を邦訳して、医療機器ドメインでの解釈とかなり違うところがあることがわかった。例えば、ISO 26262-1 には validation や software validation に関することばの定義がない。 safety validation ：セーフティゴールが満足され、達成されたことを試験やテストに基づいて保証すること、という簡単な説明しかない。なぜか。おそらく、自動車ドメインではユーザーインタフェースや、ユーザーのオペレーションに起因する不具合や事故がまだ、それほど多くないのだろう。それらが多くなって、ユーザビリティに対する対策の必要性が高まってくると、validation（妥当性確認）の解説はもっと長くなってくると思われる。（いずれくわしく説明をしたいと思う。）
逆に医療機器ドメインでは ASILデコンポジッションのような考え方がまだ確立していない。ハードウェアにしろ、ソフトウェアにしろ安全を確保するためのアーキテクチャに関する研究が進んでいない。
 |
| 技術者は技術で安全に貢献できることがある |
そう考えれば、新しい分野を勉強する時間は自分をより高めることに有益であり、決して無駄ではないことが分かる。
2012年の新年を迎えて、まだまだ勉強すべきことは山ほどあると再認識したところである。
0 件のコメント:
コメントを投稿