===========================================================================
セッション E3 チュートリアル

「自動車向け組込みC言語用ガイドラインMISRA-Cに代表される
  バグ予防と設計改善のためのプログラミングガイドライン」
  〜海外製の組込みシステムに勝てる品質向上〜

講師：   二上 貴夫 （東陽テクニカ）
会場：   C会場 (約100席)
参加者： 40名程度
===========================================================================

講演の概要

MISRA

  Motor Industry Software Reliability Association の省略形．
  本拠地を英国に置く自動車用ソフトウエアの信頼性向上を目指した研究機関．
  欧州自動車技術会(MIRA:Motor Industry Research Asociation)の下部組織．
  自動車用組込みソフトの品質向上技術の研究，
  EMC(Electromagnetic Compatibility)/電装部品の調査などを行う．
  現在は，モデルベースの信頼性向上などが研究されている．

MISRA-C

  ECU(Electronic Control Unit)の品質向上を目指した，C言語プログラミングの
  ガイドライン．品質システムの解説と127個のプログラミング標準から構成される．
  自動車会社がスポンサーなので自動車用と銘打っているが，C言語プログラミングの
  品質向上ガイドラインと捉えることができる．

  この種のガイドラインが社内に存在しても社外に公開されることは少ない．
  危ないCプログラミングについて記述した書籍はあるが，組込みＣプログラムに
  適した良いリファレンスといえるものはない．
  MISRA-Cは，今後の世界的なデファクト・リファレンスとなりうる．

  ガイドラインが必要なのは複数の人で開発する場合であり，「自分でできると，
  100人でできるとは全然違うこと」であることを思い出して欲しい．

MISRA-Cの例：ルール52 「到達しないコードがあってはならない」
  (CASE文の"default"を"defautl"と誤って記述した例を示しながら)

  この例では，異常が発生したときに実行されるよう準備された命令が，
  実は "決して実行されない" ようになってしまっている．
  この種のスペルミスは結構な頻度(100回に1回くらい)で発生する．
  しかし，"defautl"はラベルと判断され，このラベルを参照するコードがなくても，
  コンパイラではエラーと判断されない．また，CASE文には"default"がなくても良いので，
  この誤りはコンパイラでは発見されない．
  この異常が顕在化するのは，呼出す親関数が間違いを起こした時となり，
  自動車では非常に恐ろしいことが起こり得ることになる．

  同様な到達しないコードは，例えば，
  "if文"の途中に"return"があると，それ以降が実行されない
  といった場合などに発生する．

MISRA-Cの経緯と波及

  MISRAでは1990年頃から，高信頼性ソフトウエア開発技術の研究がなされ，
  1994年に，それらをまとめて「自動車用ソフトウエア開発ガイドライン」を
  公表した(このガイドラインは MISRA-Gと呼ばれる，80ページ強の資料)．
  これは，CMM(Capability Maturity Model)である程度成果の出ていたものを，
  関係者からヒアリングしてまとめたものである．
  1998年に MISRA-Cを公表し，2000年に MISRA-C補足を公表した．

  日本では，日本自動車技術会(JSAE)で，2000年にMISRA-G，2002年にMISRA-Cを
  翻訳し，CD-ROM化した．

MISRAの具体的目標

  C言語のコーディングを主に扱い，危険性を徹底的に回避する．
  それゆえ，MISRA-Cのガイドラインに従っていれば安心できる．

  C言語の開発者の一人が「C言語はかみそりのように切れる言語である」と
  言っているように，強力だが危険性もある言語である．
  スペルミスも発生するし，実装依存も多く存在する言語である．

  例えば，整数のビットのシフトは実装依存であり危険である．
  具体的には，符号ビットの実装方法が機種依存であるからである．
  (多くは最上位ビットが符号ビットだが，そうでないものも存在する)
  "unsigned"にすれば，実装依存ではなくなる．

品質保証ラベル

  MISRAの適合検定に合格した製品に，品質マークを貼付しようという取り組み．

品質指標(メトリックス)

  テスト可能な設計(DFT:Design For Test)を重視している．
  例えば，「テスト可能な設計は電子工学の常識」と記述されている．
  コードサイズ，経路複雑度，静的パスカウントを有用な指標として明示している．

合致マトリクス

  MISRA-Cのルールに合致していることを，文書化しなければならない．
  この文書は合致マトリクスと呼ばれる．
  具体的には，127個のルールについて，準拠していることを検証する手段を明記する．
  ルールを遵守していない場合は，その理由などが文書化されていないといけない．

  ツールを使って検証できるのは，全体の80%程度である．
  残りの20%程度は，設計ポリシーなどであり，ツールでは検証できない．

プログラミング・ルール

  127個のプログラミング・ルールが示されている．
  実例がある程度ついているが，なぜ必要かなどの説明が若干不親切なところもある．

幾つかのルール

  ・インラインアセンブラとCが混在しないこと．
  ・charは，signedかunsignedかで定義されること．
  ・有効範囲が入れ子になる同一名称の識別子を使用してはならない．
    コンパイラに許されることでも，分かりやすくするために使わない．
  ・論理結合演算子の被演算項は一時式とすること．
    評価順序，演算順序を正しく理解していなくても正しく書けるためのルール．
  ・浮動小数点数を等式，非等式で評価してはならない．
    以前は学生時代に習ったものだが，浮動小数点を使う人が少なくなっており，危ない．
  ・関数へのポインタを動的に変更してはならない．
    これは，MISRAでも意見の分かれたところと聞いている．

MISRAコードの開発方法

  問題検出ツールによって問題を発見し，手動で修正する方法が多く採られている．
  自動的に問題を発見し修正するツールも出現してきている．
  UMLからMISRA-C準拠のCコードを生成するツールも出現している．このツールを使うと，
  コードレベルでは(当然だが)世界最高レベルの品質指標となる．構造レベルの指標は，
  元のモデル(UML)の良さに依存するので，ツールを使ったら良くなるというものではない．

  MISRA-Cでの指摘件数は，通常のコードで 60件／Kloc程度である．
  この位でも商品になる．これが，80〜90件だと商品にはならない．
  高信頼コーディングの教育をうけると 20件／Kloc程度に減少する．
  本物のエキスパート(Cの標準化活動をする程度の人)で 3件／Kloc程度となる．
  最高到達レベルは 2.5件／Kloc程度．これは，生成ツールでの実現の場合．

日本での取り組み

  自動車技術会，MISRAC研究会などで活動が行われている．
  組込みソフト技術者管理者研究会は，現状の活動はないが，動き出す可能性あり．

まとめ

  MISRA-Cは，インスペクションの指標として有効に利用可能．
  適合検定によって品質保証レベルを誇ることができる．

---------------------
質疑

Q: メトリックスの上限値はどの程度か？
A: MISRAでは数値を規定していない．各々で決定することになる．
   私見では，関数あたりで，複雑度20，経路数200，行数200程度と考えている．

Q: ツールでチェックできないのはどのようなところか？
A: 例えば，「入力データを動的にチェックできるアーキテクチャにせよ」という
   ルールは，アーキテクチャに関することなのでツールではチェックできない．
   これは設計段階でチェックすることになる．

---------------------
おまけ

MISRA:http://www.misra.org.uk/
MIRA:http://www.mira.co.uk/
日本自動車技術会:http://www.jsae.or.jp/

---------------------
感想

一定の品質レベルを維持するために，コードレベルの実装基準を適用するに留まらず，
アーキテクチャに関する基準を整えていることに驚嘆せざるを得ない．
講演の中にも，「全てが文字通り適用できるとは限らない」との発言があったが，
適用するしないの判断が，品質を左右する恐れを含むことになり，品質重視の
実作業の厳しさを感じた．