分科会1 SA-3 組み込みシステムの試験と検証 〜OS,コンパイラ,ネットワーク 会場 : B会場 席数 : 120 出席者 : 30 コーディネータ : 今井和彦,小川清 議論内容の紹介文 :  OS,コンパイラ,ネットワークについて,規格に基づいた試験・検証方法が提案さ れていないものがある.しかし,具体的に試験・検証の方法がわからない/試験結果 が公表されていないことにより,試験・検証の可能性と効果について理解が得られて いない場合がある.  試験サービスを実施している組織,ツール提供者をはじめ,OS,コンパイラ,ネッ トワークの開発者とその利用者により具体的な議論を行い,より良い製品開発を目指 したい. 議論 : ・MISRA-Cについて:  欧州の組み込みシステムの規格OSEKについて.   Cでコーディングされたシステムやボードについての話と,これに関する本の紹介. ・Linuxの組み込みについて:  Linux はフリーのオープンソースソフトウェアであり, 1から組み込みOSのシステ ムを記述するのに比べて,Linux のソースを転用して,これに無い必要な部分のシステ ムの記述を行うことで,生産コストの低いシステムを作成することができる.しかし, ライセンスの問題というものはどう考えれば良いのか?  また,一度エラーが起き,その原因がLinux ソース(製品の開発者が記述していな い部分)から来るエラーだった場合,トラブルの処理や責任問題などはどうなるのか?  また,WindowsOS の場合ではトラブルやエラーの集計を行っている結果,トラブル 処理に関するノウハウが蓄積されているが,Linux の場合はそれが無いため,対抗し ていけるのか? ・ITRON/TOPPERSの試験・検証について  ある定められた検証を行うことで, ITRON仕様であるということを認定するように なっている.(μITRON 4.0 検定仕様) ・CROSV(クロスビー)の紹介. ・TOPPERS/OSEKの試験・検証について  MISRA-Cの基準が適用されている。  ○○には××という試験が必要,などのようにあるパターンの試験が定められてい る.  OSEKでは上記のようにはっきりとした検定が定められているが, ITRONの検定は、 未だはっきりとした検定が定められていないが大丈夫なのか? ・T-Engineの紹介と組み込みシステムの試験についての考え  T-EngineはOSの試験を行いたくない為に使用.一般的に見てもOSの試験などはした くないのでは?  既に出来てしまっているものには触れず,ユーザはアプリケーションを作っていれ ば良いのでは?  (Linux の組み込みについては, Linuxの部は完成しているものとして,ノータッ チとすれば良いのでは?)  但し,OSに新しい機能などを追加しようとする場合は,その部分にかかわる試験を 行う必要は有る. ・hamana-1のケースについて:  非常にタイトな日程で開発を行ったため,システムの試験は満足にできてはいない.  様々な仕様変更を何度もおこなったため,どう試験すれば良いかもそのケースその ケースにより変わってきている.  使用方法を限定しなければ,試験の量は膨大になってしまうため大変である. ・μITRON OSの検証について実際にしている事:  μITRON3.0を使用しているが,実際に検証しているのは,「検証仕様に沿っている か?」をチェックするのみ.その他の検証について(耐久時間等)は,各社のノウハウ によって変わってきてしまう. ・SESSAMEの取り組み:  組み込みシステムエンジニアの育成などを目的とした機関.本の紹介など.  携帯電話のOSのテストについてのお勧めを挙げる.   ・中国などの安い労働力を用いて人海戦術を行ったり,自動化することでテスト    を行う.   ・女子高生などヘビーユーザにテストプレイをしてもらうことでエラーを検出さ    せる.   ・状態遷移表をじっくり見つめて,イレギュラーを探す.   ・近年の携帯電話のネットに繋ぐ事ができる特性を利用して,バグやエラーなど    に対しアップデートをかける. (早稲田大学の方):  Linuxの組み込みや,スケジューラ,CPU使用率について. ・試験の目的についての実務者のコメント:  試験の目的というのは品質の向上である.  しかし、試験を行うだけで品質向上をすることができるのか?といわれるとノー である.このギャップはどうすれば解消することができるのだろうか? ・(プリンタ系の会社の方)  PostScript等の言語を用いて画像を作成し,印刷させる.(プリンタ言語)  WindowsOS を使用する為,マイクロソフトからの締め付けが厳しい.この点のクリ アはそれ専門の人員・部署が行っている. (質問)ネットワークプリンタとしての制御と,パラレル等PCから繋がるプリンタと しての制御に違いはあるのか? (回答)  プリンタ自体にネットワークを識別させるような形で構成させている.  もしくはネットワークサーバを介してデータをプリンタに送り,このデータを用い て印刷させるような構成になっている.ここの部分は,長くネットワークに携わって いる面子がプロトコルのノウハウを持っている. (質問)ノウハウとは? (回答)  ドキュメント化されていないが,個人個人の経験から,トラブル等問題解決の手法 が判っているものの事を言うのでは?それならば,このノウハウというものを文章と して形式化できれば,それは試験・検証の手法として用いることができるのでは? しかし,この点については企業・経営側からの締め付けがあり,実際には文章化でき ない. (A氏)  テスト・ツールについての紹介 再びLinux についての議論:   Linuxは非常に整理がなされていなく, BSD等のほうがまだ良いのでこちらを使え ば良いのでは?  他に整理されているオープンソースソフトウェアが存在するのにもかかわらず、 なぜ Linuxを使用するのか?   Linuxを使用し始めた当初は現在のようなライセンスの問題が存在せず,有能なOS と認識されていたから. NetBSDについてのコメント:   GPLがあるため,長く使用しているとUnix系が必ずしも良いとは言えない.仮想領 域と物理領域の設定・使用等が非常に難しい.  様々なプラットフォームで使えるようなOSが理想.  メモリプロテクションの有無により,リソースに大きな違いが生じる. (質問):効率的にテストを行う方法は無いものか? (回答)  テスト量について:   全てのパターンの入力についてテストを行おうとすると,あまりに莫大な量とな  ってしまう.いかに条件を限定してテストを行えるかが重要.  ザウルスOS:   様々な企業にあわせてシステムに手を加えた結果,契約上の問題や多岐にわたる  ソースの複雑さからオープンが不可能に. (質問)品質などを数値化できないか?  ハードは入力が 0-1であるため、ある程度は可能であろうが,ソフトは入力パター ンが多すぎるため基準の作成が難しい.  その他採用されている数値化検証の方法として,バグ収束率などの紹介.  テストしようとするターゲットにより,単位が様々に変わってきてしまうため,具 体的なものを設定するのは無理なのでは?  ISO/IEC9126というJIS規格の登録が存在するが,これにおいても具体的な単位につ いては存在しない.  詳しいテストや品質の程度は、顧客からの要求仕様や,コストの問題となってくる. まとめ :  オープンソースのソフトウェアには様々なもの(LinuxやITRONなど)が存在する。 これらのソースをうまく活用して,新たなシステムを構築することが,安価なものを 作るためには重要であるが,それ相応に試験・検証などの問題が生じてくる.  また,新たなソースを作成する場合,いかに再利用しやすく作るか,なども大きな 要因となる.  テストケースが何故オープンソースとされないのか?ここがクリアになれば、より 良いものができてくるかも知れない. 感想 :  組み込みシステムに限らず,テストを行い品質を保つ事は重要な事であると思われ る.世に出してそれの対価としてお金を貰う以上,作成したシステムの品質は保証さ れるべきでもあると思う.ただ,共通したシステムの評価方法が確立していないのも また事実であり,この手法を確立することは,より高性能なシステムを作成すること よりも重要度が大きいと思う.