図表5-10 icカード内の様々な保護情報 - smrj.go.jp ·...
TRANSCRIPT
- 139 -
図表5-10 ICカード内の様々な保護情報
資料：IPA/SEC 2007年『組込みシステムの脅威と対策に関するセキュリティ技術マップの調査』
5.4.2 組込みソフトウェア開発のやりやすさはどこにあるか？
組込みシステムの用途が限定されているため、汎用性を考慮しなくて良い。
ハードウェア構成を開発元がコントロールできるので、バリエーションが限定され
ており、その分設計・テストはやりやすい（パソコンは多種多様な機器と接続でき
るようになっている）。
汎用システム向けソフトウェアと違い、条件に応じてOSを比較的自由に選べる。ま
た、OSを採用しなくてもよい。
5.4.3 組込みソフトウェア開発と外部委託
事務処理系システム開発と比べ、組込みソフトウェア開発はそれほど外部委託が進んでいないよ
うに見られる。実際、調査によると「外部委託を行っていない」と答えた組込みソフトウェア開発
関係者は30.9%にも上る28。事務処理系システム開発は、ユーザ企業は自分をITの専門家と捉えて
おらず、専門家である外部のベンダーに委託するという考え方をとりがちであるのに対し、組込み
ソフトウェア開発では、メーカーはそれを自らの手による製品設計・開発活動の一部と考えている
という違いがあるが、このことも外部委託の動きが目立たないことと関係あるだろう。
組込みシステム開発の現場はハードウェアを中心に考えており、ソフトウェアはハードウェア設
計の枠組みの中に位置づける傾向がある。また、それだけでなく、組込みシステム開発ではハード
ウェアの設計とソフトウェア開発が同時に進行することが、オフサイトでの（現場を離れた）外部
委託化を難しいものにしている。そのため、メーカーは、さまざまなソフトウェア企業の人材をメ
28 経済産業省 2007年『2007年版組込みソフトウェア産業実態調査報告書』
- 140 -
ーカーの開発現場に集め、オンサイトで作業する場合が多い。この場合でも、メーカーからの依頼
は委託を受けたソフトウェア企業側の管理者が受け、その企業所属の各開発メンバを指揮・監督す
ることで請負の形をとってはいるものの、実際にはこれらの人材はそのメーカーの特定部門の中に
入り込んで長い協力関係を結ぶことになり、メーカーから見ると、完全な外部委託と比べると大変
使い勝手がよいのである。
しかし、急激に大規模・複雑化する組込みソフトウェアを前に、メーカーは対策を迫られている。
今後はソフトウェア開発を外部の専門部隊に委託する動きが活発化することになる。
組込みソフトウェア開発における2社間の委託・受託形態については第６章でより詳しく取り上
げる。
５．５ 組込みOSとオープンソース・ソフトウェア
5.5.1 組込みOSの特徴
組込みシステム用のOS（Operating System）を組込みOSと呼ぶ。多くの組込みOSは、リアルタ
イムOSである。リアルタイムOSは、処理（タスク）の実行のための時間の割り振りを管理・制御
し、いつどのタスクが開始あるいは完了するかを予測しやすいことを特徴とするOSである。ITRON
やVxWorksなど専門のリアルタイムOSは、次の瞬間に実行すべきタスクに切り替える際に発生する
遅延（レイテンシ）が短い（数～数十マイクロ秒）。レイテンシが短いことは優れたリアルタイム
OSの必要条件だ。なぜなら、レイテンシが短ければ、タスクは一回の切り替えで割り当てられた時
間のより多くを実際の仕事に費やすことができるからである。
組込み Linux など、もともと汎用システムの OS だったものにリアルタイム性を強化した場合に
は、レイテンシは 100 マイクロ秒（0.1 ミリ秒）程度かそれ以上であることもあり、またレイテン
シの予測できない変動（ジッタ）も大きい。したがって、汎用システム向けOSから引き継いだリッ
チな機能と引き換えに、リアルタイム OS としての性能は一桁以上劣ることになるが、こうした OS
においても現在改良が進められている。
（社）トロン協会のアンケート調査によると、機能面で組込み OS を見た場合、もっとも利用さ
れる機能はメモリ保護機能である。メモリ保護機能とは、一つのプログラムの誤動作の影響が他の
プログラムやOS本体に及ばないようにするための機能である29。
組込み OS の構造面では、モジュール性があることが望ましい。すなわち、組込みシステムの要
求するところに応じて、OSの不必要な機能をモジュール単位で取り外してフットプリント（この場
合メモリ等資源の要求量）を最適化し、また必要な機能をモジュールを追加することで実現しやす
いことが求められる。
29 ただし、メモリ保護機能はOSとプロセッサが内蔵するMMU（メモリ管理ユニット）が協調動作することで実現する機能であり、一部の組込みシステムでの利用は適さない。特に制御システムにおいてはリアルタイム性を確保するために、プログラム設計段階であるタスクが何サイクルで完了するかを予測したいが、メモリ保護機能の利用はMMUによる予測困難な付加処理が入りリアルタイム性を損なう場合があることから、用いられない場合も多い。
- 141 -
5.5.2 組込みOSの種類
組込みOSには様々な種類がある。調査報告によってそのシェア構成は大きく異なり、実態は把握
しにくいのではあるが、日本市場においては国産OS仕様であるITRONの勢力が強いことは間違いな
いだろう（図表5-11）。メーカー独自実装OSとITRON以外のOS（仕様）に目を向けると国産のもの
は事実上存在しない。その意味でITRONは特異な存在であり、また日本のメーカーが組込みシステ
ム開発能力を高める上で果たした役割は大きいと言うべきである。つまり、日本のメーカーはITRON
によってリアルタイムOSとは何かを学んだのである。ITRONは東京大学で開発された。それを産業
界が積極的に取り入れることで競争力を高めたのであるから、産学連携がことのほか苦手な日本に
あってこの事例は際立った例外ではなかろうか。
さて、海外に目を向けると、すこし異なる風景が目に入る。シェアの上位を占めている組込みOS
は企業が開発した商用製品である30。その中で中長期的にシェアを伸ばしているのはオープンソー
ス・ソフトウェアであるLinuxをベースとしたいくつかのOSであり、今後民間の有償製品とオープ
ンソースのLinuxのシェア構成の変化に注目したい31。
図表5-11 日本国内の組込みOSの利用比率
資料：経済産業省 2007年『2007年版組込みソフトウェア産業実態調査報告書』
図表5-12として主要な組込みOS、OS仕様及び関連製品／標準を列挙する。
図表5-12 主要な組込みOS、OS仕様及びアプリケーションプラットフォーム
ITRON 東京大学坂村教授が主導するTRONプロジェクトの成果の一つ。日本で普及している国
産組み込み用リアルタイムOS仕様。デジカメ、一般的な家電、情報家電など様々な機
30 Jim Turley 2006年『Operating systems on the rise』Embedded.com（http://www.embedded.com/columns/surveys/187203732?_requestid=666029） 31 2006年『Linux top embedded OS but declining, survey suggests』LinuxDevices.com（http://www.linuxdevices.com/news/NS8291914289.html）
- 142 -
器に組み込まれている。
軽量版のμITRON であれば、8ビットプロセッサで10KB程度のプログラムサイズで十
分動く。仕様は公開、実装は市販品のライセンスを購入するか、メーカーが自分で行
うのが一般的。
オープンソース実装も複数存在する（TOPPERSやeCosなど）。
（社）トロン協会の調査によると、プログラムサイズ16MB未満でTRON系採用が多い。
CTRON TRONプロジェクトの成果の一つで、日本の電話交換機用に開発・利用されたOS。
eTRON IC カード用OSで、データキャリアチップの機能を管理し、安全性を高める。TRON プ
ロジェクトの成果の一つ。
T-Engine OSだけでなく、ソフトウェア、ハードウェアを含めた組込みシステム全体のプラット
フォーム仕様。OS部分はT-Kernelと呼ばれるITRONの後継。ITRON仕様が緩やかな規
格で（「弱い標準化」）、自由に拡張・カスタマイズが自由なのに対し、T-Engine は標
準化されたプラットフォームの上での動作を前提とされており（「強い標準化」）、ITRON
のようにメーカごとに実装がバラバラでソフトウェアやツールを流通・再利用しにく
いといった問題を解決し、開発効率の向上を図っている。
TOPPERS 名古屋大学高田教授が主導するプロジェクト。μITRONカーネル実装やOSEK/VDXとい
ったOS仕様の実装をオープンソース・ソフトウェアとして公開している。
Palm OS PDA 製品「Palm」用に開発されたOS。次世代版はLinux ベースとなることが決まって
いる。
Windows CE／XP Embedded以
外のWindows
Windows NT や XP は ATM など、内部にパソコンを組み込んでいる大型機器で利用され
る。
Windows XP Embedded Windows XPをコンポーネント形式で提供し、組込みシステム向けにフットプリントを
最適化できるようにしたもの。
Windows CE PDAライクな機器のOSとして利用が広まっているが、高機能携帯電話でも採用される
場合がある。
近年のバージョンではリアルタイム機能が強化されている。
これをベースにした関連OSにWindows Mobile（旧称PocketPC）がある。
Linux オープンソースOS。POSIX準拠。もともとパソコン用OSだが不用な機能を削ったり、
リアルタイム機能を付け加えたり、マイコンで動作するように改造するなどした組込
み用Linuxカーネルも存在する（Red Hat Linux、MontaVista Linux、BlueCat Linux、
Linux/RT、RTLinux、RT NELinux、uClinux など）。また、LynxOS は Linux との互換性
を持つ組込みOSである。
VxWorks WindRiver 社の組込み機器用リアルタイム OS。信頼性・安全性に優れ、航空宇宙分野
で用いられていたが、近年は情報家電での採用も増えているとされる。
- 143 -
pSOS 旧 Integrated Systems 社（Wind River 社によって吸収合併）が開発した組込み機器
用リアルタイムOS。IPv6やCORBAなどの高度なネットワーク通信や分散処理機能に優
れる。デジカメへの搭載が多いとされる（？）。現在はVxWorksに統合されている。
OS-9 Microware（現RadiSys）社のリアルタイム・マルチタスクOS。もともとMotorola 社
の8ビット・マイクロプロセッサ用に開発されたにも関わらず、UNIXライクな機能を
実現している。
LynxOS LynxWorks社のPOSIX準拠リアルタイムOS。
QNX Harmon International社のPOSIX準拠リアルタイムOS。
Symbian 携帯電話端末販売世界一位の Nokia が採用していることから、世界で最もポピュラー
なスマートホン用OSと言える。EPOCというPDA用OSをベースに設計された。
REX CDMA規格で知られる米Qualcomm社のリアルタイムOS。BREWと組み合わせて使われ、
Qualcomm社製ベースバンドチップには両者が搭載される。
Windows Mobile Windows CEの項を参照。
BlackBerry OS 米国市場でビジネスユーザに人気を博している携帯端末 BlackBerry に搭載されてい
るOS。
Garnet OS 日本のAccess社のスマートホン向けOS。
携
帯
電
話
端
末
用
Ｏ
Ｓ Android 検索エンジン大手Google 社が発表した携帯電話用OSプラットフォーム。報道による
と同社はこれをWindows Mobileの対抗軸として位置づけている。
J2ME Java 2 Micro Edition。OSではなく、アプリケーションのプラットフォーム。Javaの
ライブラリ使用を縮小・改変し、組込み機器上でのアプリ実行に適した形にしたもの。
Javaで書かれたプログラムはハードウェア・OSのインターフェースを抽象化（あるい
はブラックボックス化）するバーチャルマシン（VM）上で実行する。業務系のJavaの
プログラミングの知識が活かせるため、プログラマの調達がしやすい利点がある。ま
た、メモリの自動開放など、プログラミングを簡単にするための高度な仕組みを提供
する。反面、消費メモリが大きい、リアルタイム処理ができない（もしくはしにくい）、
機器上にJ2ME自体を実装するのが大変、機器特有の機能を利用するプログラムを書き
にくいといった制約があり、用途は限定される。携帯電話端末で多く採用されている。
BREW OS ではなく、API（Application Programming Interface）。au 社の携帯電話、中国や
米国のCDMA携帯電話に搭載される。C言語でプログラミングする。Javaと比べて機器
特有の機能を利用することに優れ、小さいメモリで動作するアプリが作りやすい反面、
Javaのような安全機構に乏しく、プログラミングを誤った場合周辺のプログラムに障
害をもたらしやすい欠点がある。
- 144 -
OSVM Smalltalkというオブジェクト指向プログラミング言語によってプログラミングする。
バーチャルマシン（VM）を使う点と併せて、仕組みはJavaと類似である。携帯電話端
末や携帯情報端末での利用例があるとされる。
MISRA-C OS ではなく、欧州の車載組込み／制御ソフトのコーディング規約。C 言語のソースコ
ードがこの規約に準拠しているかどうかをチェックするツールなど（例：英
Programming Research社のQA C）が販売される。
車載に限定せず、組込み C プログラミングでバグを招く原因となるような不適切なコ
ーディングを予防するために導入するケースが多い。
関連する国内規約として、経済産業省 組込みソフトウェア開発力強化推進委員会によ
る「組込みソフトウェア用C言語コーディング作法ガイド」がある。
OSEK/VDX ドイツ系のOS仕様。OSEKはMercedes BenzとBosch社主導の組織で1993年発足。現
在 ISO 17356 として国際標準化もされている。エンジン制御ユニットやその他の ECU
で用いるリアルタイム OS として先行している。 OSEK：Offene Systeme und deren
Schnittstellen fur die Elektronik im K raftfahrzeug。
TOPPERS/OSEKカーネル TOPPERSプロジェクトによるOSEK/VDX準拠のOS。ITRONとは非互換。オープンソース
として公開。
Windows Automotive （カーナビなど）車載情報端末用のOSで、Windows CEベース。
5.5.3 組込みシステム向けオープンソース・ソフトウェア
多くの組込みシステム製品は多数生産され、出荷されるものであるため、メーカーとしてはコス
トの観点から、出荷台数に応じたライセンス料の発生するソフトウェア製品の利用はなるべく避け
たい。そこでキーとなるOSなどにオープンソース・ソフトウェアを採用することになる。
TOPPERS プロジェクトはμITRON4.0 仕様の OS カーネルである TOPPERS/JSP カーネル、及び
OSEK/VDX使用のOSカーネルであるTOPPERS/OSEKカーネルをそれぞれオープンソース・ソフトウェ
アとして公開している。
eCos は数十～数百 KB 程度のメモリを搭載した組込みシステムをターゲットとしたオープンソー
ス・リアルタイムOSである。POSIX及びμITRONとの互換性を備える。
LinuxはUNIX系のOS仕様であるPOSIXに準拠したオープンソースOSである。近年ではサイズを
小さくし、リアルタイム機能などを強化した組込みシステム要のLinuxカーネルも複数が存在する
が、小規模な組込みシステムでの利用には適さないとされる（2MB 程度以上のメモリが必要とされ
る）。Linuxならではの豊富な資産が利用しやすい反面、リアルタイム性能は専門のリアルタイムOS
と比べると弱い欠点がある。
組込みシステムでも携帯電話やSDカードなど様々な情報を扱うものが増え、データベース搭載事
例も増えてきた。こうした状況ではオープンソースの組込みデータベース製品の利用も考慮に入れ
られる。具体的にはSQLiteなどのオープンソース製品が存在する。
- 145 -
組込みシステムが TCP/IP でネットワーク通信を行う際に必要となるプロトコルスタックと呼ば
れるソフトウェアに関しても、TOPPERSプロジェクトの「TINET」など、オープンソース実装が公開
されている。また、デジタル家電やパソコンなどを簡単にネットワーク化するためのプロトコルで
あるUPnPのプロトコルスタックのオープンソース版（「CyberLink for C」）も存在する。
組込みシステムにおいてオープンソース・ソフトウェアの利用が重視される背景には、前述のラ
イセンス料を省きたいという動機のほかに、必要に応じてそのソースコードが自由に閲覧できるこ
とがある。何か特定の処理のときだけ動作が遅くて原因を調べたいなどの場合、ソースコードのレ
ベルでOSの実装を調査できれば有効な解決策が見つかるかもしれない。これが有償製品の場合、相
応のサポート契約を供給元と結んでいれば同程度の調査が可能となる場合もあるが、オープンソー
スであれば少なくともソースコードはいついかなるときでも開示されているという安心感がある
（実際に OS のソースコードを読み込むだけの知識をもった人材が開発現場にいるかどうかは別問
題であるが）。
５．６ 組込みソフトウェア開発プロセス
5.6.1 組込みシステム能力の向上とソフトウェア開発モデルの進化
1980年代は組込みソフトウェアの規模は小さく、ハードウェアの開発の過程で主にアセンブリ言
語を用いて作られるのみであり、それ自体が専門のプロセスを持つようなものではなかった。1990
年代に入ると16-bitマイクロプロセッサが利用されたり、搭載可能がメモリが増えたりなどして、
C言語（高級言語）の利用が一般的な選択肢に上った。さらに1990年代後半に入るとメーカーはITRON
に準拠したOSを自社実装して様々な製品に応用するようになった。この段階で組込みソフトウェア
の開発はOSという一定の規約下で、マイクロプロセッサの選択によらず同じ文法でプログラムを記
述できる高級言語を用いながら、同じ設計の考え方、同じ表現によって行うことが可能となった。
C 言語を拡張し、オブジェクト指向プログラミングと呼ばれるより生産性の高いプログラミング
手法を取り入れたのがC++言語である。1990年代後半から多く用いられるようになったこの言語を
用いることでフレームワークと呼ばれる一種の半完成ソフトウェアや、ミドルウェアを効率的に利
用できるようになり開発を効率的なものにできるが、完成したプログラムの性能はC言語と比べて
若干劣ることもあり、ある程度処理能力の高い組込みシステムで使われる傾向がある。
2000年代に入ると組込みシステムの能力はいっそう向上し、32-bit RISCプロセッサの利用も一
般的になり、また搭載メモリも数十MB以上と余裕が出てきた。これとともに組込みソフトウェアも
大規模化の傾向を帯びてきたため、単なるプログラミングという考え方での開発では品質、保守性
及び生産性の維持に限界が見られ、体系的・工学的にソフトウェア開発を進める必要性が一部で言
われるようになったのである。いわゆるソフトウェア・エニジアリングの考え方を取り入れたり、
プログラムの自動生成技術を応用したり、あるいは共通のソフトウェア資産に基づいて様々な製品
向けのソフトウェアのバリエーションを効率よく開発するソフトウェア・プロダクトライン・エン
ジニアリングの導入が検討されるといった動きが見られる。
- 146 -
また、従来の組込みシステム開発はハードウェアの開発が主で、ソフトウェア開発は従という考
え方が取られており、後者は常にハードウェア設計の細かい変更に影響を受けていた。ここ数年は
この主従関係を見直し、ハードウェアとソフトウェアの開発は対等に、同時並行的に進むべきだと
の理念の下に「ハードウェア／ソフトウェア・コ・デザイン」（またはハードウェア／ソフトウェア
協調設計）が提唱されている。これについては次節で述べることとする。
ハードウェア開発そのものでもイノベーションが行われている。すなわち、開発の初期段階にお
いて実機や試作機を用いることなくシミュレーションによってハードウェア設計を検証し、生産性
とシステムの信頼性を向上する開発手法である。実際にはハードウェアだけでなく、ソフトウェア
で実装すべき制御アルゴリズムもあわせて検証するため、ソフトウェア開発にも関わる。むしろ、
ハードウェア＋制御アルゴリズムを仕様として記述し、これに基づいてシミュレーション、検証及
び一部プログラムの自動生成を行う手法だと考えるべきだろう。
図表5-13 組込みシステム能力とソフトウェア開発モデルの進化
5.6.2 組込みシステム開発環境
ここで組込みシステム開発で一般的に用いられるツール等をおさらいしておきたい（図表5-14）。
注意されたいのは、特定の製品向けにこうしたツールを用いてロジックICをカスタム設計する場合、
そこで用いる組込みソフトウェアの設計との間に何らかの関連があるということである。つまり、
あるロジックを実装したい場合、それをハードウェアとして実装するか、ソフトウェアとして実装
するかの選択があり、前者を選択した場合と後者とでソフトウェアで実装すべき部分も変わってく
るのである。組込みシステム開発者はハードウェアとソフトウェアの両方の知識が求められるとい
われるのは、ひとつにはこうした理由によるのである。
- 147 -
図表5-14 組込みシステム開発環境の構成要素
EDAツール Electronic Design Automationツール。ロジック設計用や電子回路設計用のCADを含
むツールの総称。1980年代、こうしたツールはEWS（Engineering Workstation）と呼
ばれる専用のコンピュータ・システム上で利用されたが、現在では一般のワークステ
ーションやパソコンで利用される。HDLやFPGAを用いたLSI設計にも用いる。
評価ボード ハードウェア設計の詳細が決まる前に、評価ボード（標準的な構成をもったボードコ
ンピュータ）を使い、その上で動作するソフトウェアをまず開発することができる。
この場合、実際のハードウェア設計が完成した後に、開発したソフトウェアをターゲ
ット・ハードウェア向けに実装することになる。
ICE In-Circuit Emulator（インサーキット・エミュレータ）を用いる。組込みソフトウェ
アのデバッグのための機器。これにより開発対象の組込みシステムとパソコンを接続
し、対象のプロセッサやFPGAを乗っ取りその動作とメモリをICEがエミュレートする
ことで、パソコン上で組込みソフトウェアを実行しながらデバッグ作業を行うことが
できる。特に組込みソフトウェアのリアルタイム性の観測などができることが利点で
ある。近年ではチップから出ている回路／基盤検査用のJTAGコネクタをデバッグ用に
拡張したものを利用してプロセッサやFPGAと接続できるようになっている。
シミュレータ 組込みシステムのハードウェアを含めてパソコン上でシミュレートする開発環境。こ
れによりハードウェアの実物（ターゲットボード）がない状態でも、組み込みソフト
ウェアの開発が可能となる。
コンパイラ／デバッガ、統合
開発環境
C/C++などのプログラミング言語を使った組込みソフトウェアの構築ツール。パソコン
を使用する。経済産業省の調査によると、組込みソフトウェアの 93%は C または C++
によって開発されている32。
ロジックアナライザ ロジック回路の動作を分析する測定器。シミュレータでは捉えきれないハードウェア
の動作を分析できる。FPGA のデバッグにも多用される。Agilent 社とTektronix 社の
製品が市場シェアのほとんどを占める33。
スペクトラムアナライザ 回路上の電気信号のスペクトラム（周波数成分）を分析する測定器。
5.6.3 組込みシステムと開発プロセスモデル
調査によると、開発プロジェクトが採用する開発プロセスモデルとして最も多いのはウォーター
フォール型34であり（36.2%）、次いで多いのが「標準的な開発プロセスはない」であった（22.7%）
32 経済産業省 2007年『2007年版組込みソフトウェア産業実態調査報告書』 33 ロジックアナライザやスペクトラムアナライザに至っては、純粋にハードウェア技術者の領域のようにも思われるが、組込みシステム開発の現場においては、ハードウェア／ソフトウェアを含めた製品全体としてのパフォーマンスの評価が問題となるため、ソフトウェア技術者であっても、しばしばこうした機器を使って（いちいちハードウェア技術者の助けを借りずとも）ターゲットボード上でのシステムの動作をある程度検証できることが優秀な技術者としての条件となっている。 34 要件定義→アーキテクチャ設計→詳細設計→実装（プログラミング）・単体テスト→結合テスト→総合テスト の
- 148 -
35。ただしウォーターフォール型の採用理由は「メンバが慣れているから」や「社内／部門標準だ
から」といった消極的な理由が大半を占めており、「開発プロセスはこうあるべきだ」という問題意
識がない場合に受身的な態度でウォーターフォール型を実行していることが疑われる。そうであれ
ば当然開発プロセスは効果的なものとはなりにくい。開発ソースコード規模1万行以上のプロジェ
クトでは不具合の原因の40%以上がソフトウェア要件定義工程にあることは36、ただでさえ要件定義
の有効性を早期に確認することが難しいといわれるウォーターフォール型を漫然と受身的に適用す
ることの問題点を露にしている。他の開発プロセスモデル37を採用している場合の理由は「開発条
件に適しているから」がもっとも多く、積極的であることと対照的である。
ハードウェア開発との関連で言えば、基本的にハードウェアとソフトウェアは工程を同じくして
並行で進んでいる傾向がある（図表 5-15）。ただしハードウェアの場合は結合テストと総合テスト
は同時に行われている（実際には区別がないものと思われる）のに対し、ソフトウェア総合テスト
はソフトウェアおよびハードウェアの結合テストの次の工程として実施されているという違いがあ
る。これはハードウェアの設計が固まった後にソフトウェアの動作をテストしているものと解釈で
きる。
図表5-15 各工程の平均開始時期とその平均期間（開発ソースコード規模10万行以上）
資料：経済産業省 2007年『2007年版組込みソフトウェア産業実態調査報告書』
5.6.4 製品の検証・評価
組込みシステム製品の検証・評価は開発チームとは別の専門チームが行う場合がある。特に第三
者機関が行う場合を第三者検証と呼ぶ。検証・評価作業を専門に請け負う会社も数多く存在する。
ように工程を区切って一方向的に開発が進展していく開発プロセスモデル。 35 経済産業省 2005年『2005年版組込みソフトウェア産業実態調査報告書』 36 経済産業省 2007年『2007年版組込みソフトウェア産業実態調査報告書』 37 スパイラルモデル（18.9%）、プロトタイピングモデル（8.9%）、インクリメンタルモデル（8.2%）、XP等アジャイルプロセス（2.8%）、その他（3.5%）。資料：同上
- 149 -
すでに述べたように、メーカーにとって発売した製品のリコール・回収は多大な損害をもたらす
ため、これはもっとも避けたい。そのためには検証・評価に大きな期間とコストを費やす。検証・
評価は全ての開発コストの数十%を占めるとも言われる。この中では様々な種類のテストを実施する
（図表5-16）。
製品には決められたリリース・スケジュールがあり、これに遅れないために検証・評価作業は製
品の開発と並行で行う（図表5-17）。
図表5-16 検証・評価作業の中で行われるテストの種類
テストの種類 説明
タスク指向機能テス
ト
仕様書や操作説明書に従った操作を行い、機器が正常に動作し、ユーザの目的を達成できるか
どうかをテストする。正常系テストの一種。
強制エラーテスト 設計上エラーの結果に終わるべき操作を行い、実際にエラーになるかどうかをテストする。異
常系テストの一種。エラーになるべきところでエラーにならないと、後で見かけ上の別のエラ
ーにつながるが、これではユーザは何を間違えたのかが分からないばかりか、メーカーによる
サポートや補修も不的確なものになってしまう。
頑健性テスト 仕様書や操作説明書にない操作手順によるテストや、全ての機能を網羅するようなテストを行
う。開発者が想定していないような操作を含む。ユーザは時に思いもよらぬ変則的な使い方を
するものである。このテストでは、どのような操作を経ても機器が使用不能になるなどの不都
合がないことを検証する。
境界値テスト 仕様上の上限値・下限値およびそれらの±1の状況での動作をテストする。
ランダムテスト 無作為操作によるテスト。専門の評価技術者が行う。特に、機器の不良動作を引き起こす操作
手順を見つけることが目的。例：デジタルカメラで、連続撮影中にダイヤルを「再生」に換え、
すばやく「撮影」に戻すと操作不能状態になる。
図表5-17 並行に実施される製品開発と検証・評価作業