July 2005

ソフトウエアの信頼性の見直し エレクトロニクス製品が自動車に広く使用されるにつれて、ソフトウエアの信頼性が最重要課題になりつつある。業界団体とツールベンダーは、死活問題にもなりかねないプログラムコードの品質を確保するためにエンジニアのための支援策に乗り出している。 　 　 Graham Prophet, EDN Europe, Editor in Chief

機械系システムの制御にエレクトロニクス製品を使用する場合、自動車メーカーは、すべてのシステムが完璧に機能することを保証しなければならない。ソフトウエアの複雑性が増すにつれて、エラーがないソフトウエアは、欠陥がないハードウエアと同程度の重要性を持っている。自動車メーカーは、システムを追加するにつれて、各システムが個別に正常に動作することだけでなく、各種サブシステムの相互動作が正しく行われることを保証しなければならない。 Advertisement 　ソフトウエアに欠陥があった場合、悲惨な人的被害をもたらすばかりではなく、販売後もその修正に莫大な費用がかかる。例えば昨年、英Jaguar社は、コントローラがトランスミッションオイル圧力の大きな低下を検出したときに、ギアが勝手にバックに入ってしまうシステム障害を引き起こしたことにより、北米、欧州および日本で、約6万8000台のリコールを実施しなければならなかった。　 　自動車業界は、MISRA（Motor Industry Software Reliability Association）が作成した推奨プログラミング・プラクティスMISRA-C:2004などのイニシアチブを通して、ソフトウエアの品質問題に対処しようとしている。この組織は、Cコードを安全に記述する128のルールを規定して、バージョン1を1998年に発表した。それ以来、このガイドラインは、航空宇宙産業から鉱業までのあらゆる業界で活用されている。　 　結果的に、多くのコンパイラ・ベンダーがMISRA-Cコードチェッカを提供し、自ら所有する独自のソースをこのルールに準拠するように変更した。その一方で、中核のMISRAグループは、米国に本拠を置くSAR（Society of Automotive Engineers）のほかにも、日本での同等の組織であるJSAE（Society of Automotive Engineers of Japan：日本自動車技術会）、JAMA（Japanese Automotive Manufacturers Association：日本自動車工業会）およびISOのグループと連携を続けている。新しいバージョン2の仕様は、四則演算のための新しいルールを追記し、元の文書に改良を加えている。また、バージョン2は一部の総括的なルールを具体的なディレクティブに変更し、勧告ルールの一部をdo-or-donﾕt式ガイドラインへと強化した。このバージョンは、フレームワーク内の121の必須ルールと20の勧告ルールをそのまま残し、バージョン1との密接な互換性を保っている。 　 MISRA 　 　ソフトウエア作成の理想的なプロセスは、包括的なコレクト・バイ・コンストラクション（correct-by-construction）方式により、リリース版のコードにエラーが出ないようにすることである。しかし、これはあくまでも理想で現実的ではないため、自動車業界は、依然ソフトウエアの試験に投資を続けている。複雑なシステムを検証するほかの分野でも同様に、ソフトウエア試験の革新性からは、過去のすべての方法を一蹴するような「特効薬」が与えられていない。その代わり、新しいテスト製品が現れる度に、ユーザーは、包括的なソフトウエア検証を実現するために自社が築いてきた実績の上に、テスト製品を積み重ねていくような傾向がある。　 　設計者は、ソフトウエアの検証にいわゆるコード自身を分析する静的解析と並行して、もっとも直接的なアプローチである機能試験の実施をしている。米国のリサーチ会社VDCは、2004年の調査で、ソフトウエア試験市場で大手のサプライヤ15社を特定した。その最大手がRationalのコード開発とテストスイートを提供する米IBM社である。このソフトウエア市場のパッケージは、主にシート単位（per-seat basis）で販売され、特に高価というわけではない。 　また、自動車業界は、基幹ソフトウエアに依存する業界と同様に、より信頼性の高いコードを作成するために可能な限りの援助を積極的に展開してきた。したがって、ほとんどの会社では、少しでも現状の問題解決に結びつくあらゆる技術の評価を行ってきたと考えられる。その結果、ほとんどすべてのツールベンダーが、自動車メーカーとサブシステムのサプライヤに対して全く同じ印象を抱いたとしても過言ではない。このような顧客のコード開発フローに対して、量産ライン用の本体にツールを組み入れようとしても、その成功の兆しはほとんど見られない。　 　米PolySpace Technologies社の静的テストツールである、MISRA-C: 2004 準拠バージョンのPolySpace for MISRAのリリースにより、MISRA-Cの重要性が増している。PolySpaceは本来、航空宇宙業界から派生したツールである。このツールは、抽象解釈（abstract interpretation）を用いてソースの分析を行う。このツールは、変数を取ることができるすべての値のほかに、コード内のデータフローを調査することによって、機能試験や回帰試験を実施しなくても、ラン・タイムエラーを検出する。　 　同様に、米Programming Research（PRQA）社や英LDRA社は、自社のソフトウエア・テストスイートで、MISRA標準規格との適合性を検証している。PRQAの場合、MISRA準拠モジュール（MCM）は、ソースの分析と品質評価の手法と、ソフトウエア作成プロセス自体のプロセス管理を具体化するスイートで部分的に構成されている。　 　業界の観測筋は、IEC-61508機能安全規格（www.iec.ch）がやがてMISRA-Cに取って代わり、自動車システムの事実上の標準規格になると考えている。この規格は、特定できる障害を減らすため、電装系システム内での機能的な安全性の実現に関するガイドラインである。このガイドラインは、装置設計と技術管理のプロセスに対応し、各プロセスが正確に、そして安全に機能する確率に基づいたリスク評価方法を提供するもので、業界特有の安全基準のベースとなっている。 　 OSEK と NEXUS 　 　このような公式の評価を作成するに至った理由は、OSEK準拠のRTOSコードを用いてOSの決定論を保証し、さらにNexus準拠のハードウエアデバッガによる総合的なリアルタイムのトレーサビリティを提供するなど、最近の自動車業界に見られる理論的なイニシアチブの進歩である。 　当初、ドイツのKarlsruhe大学で始まったOSEK/VDX（open system and corresponding interfaces for automotive electronics/vehicle distributed executive）は、複数のプロジェクトにわたってソフトウエアの移植性と再利用性をサポートし、ECU（電子制御ユニット）ソフトウエアの開発と再開発の繰り返しにかかるコストを削減するためのプロジェクトである。　 　OSEKはSiemensの商標で、その運営委員会と技術委員会のメンバーは欧州の自動車メーカー、半導体サプライヤ、ソフトウエア・メーカーから選ばれている。OSEKは、ECU間の通信、ネットワーク管理、オペレーティングシステムの3つの分野から構成されている。MODISTARC検証と呼ばれる補完的なテストは、OSEK/VDXベースの分散アーキテクチャ検証のための方法とツールを網羅している。最新のバージョンは www.osek-vdx.orgからダウンロード可能である。 　もうひとつ関連する活動に、Nexus 5001 フォーラムがある。この業界主導のプログラムでは、オンチップ・メモリー内のキャリブレーションデータに透過的にアクセスしながら実行中のリアルタイムシステムをデバッグするという困難な問題の解決に取り組んでいる。米Freescale Semiconductor社、独Infineon Technologies社、伊仏合弁のSTMicroelectronics社を含む半導体メーカーのメンバーは、「MPC5554 Copperhead」、「TC1796 TriCore」、「Super-10 microcontroller」を内蔵したサンプル・プロセッサをそれぞれ提供している。STMicroelectronics社はSuper-10をハードディスク・ドライブ向けとしているが、Freescale社とInfineon社はそれぞれ、エンジン管理用とパワートレイン用を狙っている。　 　現在、Nexus-5001は、バージョン2で、Class 1で始まる4つのコンプライアンスクラスから構成されている。Class 1は、 処理能力が限定されたJTAGベースの接続となり、実行、停止、ブレークポイントの設定、レジスタの読み取りと設定、プロセッサを停止した状態でのメモリーのアップロード/ダウンロードをサポートする。Class 2では、オーナシップ・トレースとプログラム・トレースが追加され、オーナシップ機能によってデバッガがRTOS内で実行中のタスクを追跡可能である。ハードウエアの拡張により、低速の補助デバッグポートをI/Oポートピン間で共用することが可能である。Class 3では、プロセッサを停止しなくても、データの書き込み/トレース、メモリーのリード/ライトが可能である。これらの機能を実現するには、専用で高速の補助ポート用I/Oインターフェースが必要となる。Class 4では、標準規格準拠の補助ポートを通してデータの取り込みまたは読み取りを行うメモリー代替機能が追加され、またウォッチポイントからトレース機能を起動可能である。Class 4は、任意にウォッチポイントにメモリー代替機能を組み込める。これは実行中のシステム内のキャリブレーション定数を動的に変更する場合に役に立つ。 　 モデルアプローチ 　 　自動車業界の関係者の多くは、通信などのほかの領域で複雑なシステムのソフトウエア・エンジジニアと同様に、設計プロセスにモデル駆動型のアーキテクチャを完全に実装することによってのみ、適正水準のソフトウエア開発が可能であると信じている。　 　この考え方では、単一の高水準のシステム記述から、詳細な仕様、最終の運用プログラムコードが生まれるまで徐々に洗練される実行可能モデルと、そして正しい動作の検証に必要なテストベンチが生成されることになる。この分野で意欲的に活躍しているベンダーは、長い歴史を持つ要件管理製品「Doors」とソフトウエア開発製品「Tau」を提供している米Telelogic社と、「StateMate」製品ラインを提供する米iLogix社である。どちらの会社の製品もUML（Unified Modeling Language：統一モデリング言語）をベースにしている。 　しかし、こうした状況は目新しいものではない。自動車業界は、すでに10年以上に渡ってモデルベースの開発と活用の最前線にいる。このような新しい技術の投入は、「エリート」と呼ばれる高級車市場に限定させることもあれば、包括的なモデル駆動型デザインへの欲求があるにせよ、その技術の適用を特定のサブシステムだけに留めたケースもある。 　ただし、現在、システムの複雑さが段階的に増していることもあり、自動車業界はこれらのデザイン哲学を量産車のデザインに試さざるを得なくなっている。今後、自動車メーカーは自社と関係のある第一階層（Tier One）のシステム・サプライヤとの開発上の結びつきを強化し、開発ツールチェーンに対してさらなる要求を行っている。その結果、今では、多くのベンダーが、米MathWorks社の「MATLAB」や「Simulink」という、有名なシミュレーション環境との接続機能を持つツールを提供している。　 　このツールチェーンは、最近、モデリング段階でコードカバレージ試験を実行するSimulinkの検証モジュールで構成されるようになった。これらの機能は、特にFPGAを内蔵したターゲットに合わせてコアプラットフォームが提供する自動コード生成機能を補完している。伝統的にプログラマブル・ロジックの使用に慎重なはずの自動車業界が、この考え方に夢中になっている、とすべての主要なプログラマブル・ロジック・ベンダーは報告している。現在、プログラマブル・ロジックは、ハードウエアとしての信頼性が立証されたことから、米Actel社、米Altera社および米Xilinx社などの主要ベンダーのすべてが、エンジン管理のアプリケーションに定評のあるPowerPCなどのプロセッサを組み込むことが可能な車載レベルの半導体を供給するようになった。また、プログラマブル・ロジックの各メーカーは、自動車メーカーが要求する経済性にかなった、または少なくともその要求に近い低価格の製品ラインも整備している。 　プログラマブルなハードウエアと、ソフトウエアと同じようにリコンフィギュラブルなハードウエア・オプションは、当然、両方の領域で安定したプログラムコードを必要とするが、プログラマブルなハードウエアは、厳格な検証と試験によって、統合化するための仕様駆動型および、モデル駆動型の設計プロセスへの原動力となる。これらのすべての要素が、有能なシステムレベルの言語と設計環境の重要な探求に深く関係して、EDA（電子設計自動化）社会に大きな影響を与え続ける。

>>> EDN GLOBAL REPORT 目次