組み込みシステム環境とリアルタイムOS の動向
− ITRON仕様を中心に −

１．はじめに

本稿ではまず，組み込みシステムの現状について紹介し，組み込みシステム用 リアルタイムOS仕様の標準化に対する要求が高いことを指摘する．次に，その 要求に答えるために作成したμITRON仕様の設計方針について述べ，その実 装・応用状況を紹介する．また，μITRON仕様カーネルの実装技術について も解説し，μITRON仕様の今後の発展性について述べる．

小規模な組み込みシステムの現状と特徴

マイクロコンピュータ技術の発展に伴い，組み込みシステムの応用分野も拡大 の一途をたどり，当初工場の生産ラインの制御等産業用途で産声をあげたもの が，通信機器や OA機器等業務用途に拡大し，近年は，自動車をはじめ，電子 楽器やゲーム機，携帯電話，携帯用ビデオカメラ，テレビ，オーディオ，洗濯 機，エアコン，照明器具等民生分野に急激に拡大し，今では身の回りで組み込 みシステムでないものを探す事の方が難しくなっている．

一般に，民生機器に代表される小規模な組み込みシステムには，産業機器に代 表される規模の大きい組み込みシステムと比較して，機器の製造個数が極めて 多く，単価が安いという特徴がある．そのため，大規模な組み込みシステムで は開発コストを下げることが重視されるのに対して，小規模な組み込みシステ ムでは最終製品の製造コストを下げることが重視される傾向にある．また，特 に民生機器分野では，一度販売した機器のソフトウェアを改修することはほと んどなく，システム開発のライフサイクルが短いことも，特徴の 1つとなって いる．

小規模な組み込みシステムの分野では，プロセッサコアに加えて，ROM，RAM， 汎用I/Oデバイス，用途に応じたデバイスなどを 1チップ化した MCU が広く使 われている．

1994年の全世界での出荷個数ベースで，MCU は MPU より 1桁多く，年間約20 億個が出荷されている (表-1)．特に日本においては MCU の割合が高く，日本 国内での出荷が全世界の中で占める比率が，MPU では1割以下であるのに対し て，MCU では約4割を占めている．トロン協会が 1994年に行ったアンケート調 査からも，日本においては，8bit や 16bit といった小規模なプロセッサが使 用されるケースが多いことがわかる (図-2)．

MCU上のソフトウェアを開発する際には，最終製品のコストダウンの要請から， ハードウェア資源の制約が問題になる．とりわけメモリ容量の制約は厳しく， 典型的な 8bit MCU で，ROM が 32KB，RAM が 1KB 程度，少し大規模なもので もそれぞれ 128KB，4KB 程度のメモリ容量しか持っていない．

表-3 日本メーカ製の MCU用プロセッサコアの例

メーカ名	8bit	16bit	32bit
(株)東芝	TLCS-870, TLCS-90	TLCS-900, TLCS-9000	R3900
(株)日立製作所	H8/300, H8/300L	H8/500, H8/300H	SH1, SH2, SH3
富士通(株)	F2MC-8L	F2MC-16L/H/F	FR20, SPARClite
三菱電機(株)	38000	7700, M16, M16C	M32

※ ITRON専門委員会メンバ社の代表的なプロセッサコアをリストアップした

高いコストパフォーマンスが求められる MCU は，しばしばアプリケーション に最適化して設計されることから，プロセッサコアの種類が極めて多いことも 特筆すべき点である．表-3 に，日本の半導体メーカが販売している MCU用の プロセッサコアの例を挙げる．この表にあるプロセッサコアの多くは，各メー カ独自のアーキテクチャを採用している．

このような小規模な組み込みシステムの分野においても，ソフトウェアの生産 性の向上は重要な課題となっており，C言語などの高級言語を使うケースや， μITRON仕様を代表とするリアルタイムOS を用いるケースが多くなってい る．

このことを実証するデータとして，トロン協会が 1994年に行ったアンケート 調査でも，組み込み用リアルタイムOS の問題点として，OS により仕様が異な るために切替えの負荷が大きい，上位互換性がないといった標準化の問題，設 計者が少ない，技術が不足といった教育上の問題を挙げたケースが多くを占め た (図-4)．

以上のことから，小規模な組み込みシステム用リアルタイムOS仕様の標準化に 対して，強い要求があることがわかる．とりわけ，概念や用語の統一といった 教育面を重視して，広い範囲の組み込みシステムに適用できるものであること が求められている．それに対して，他の多くの OS標準仕様が重視しているソー スコードレベルの完全な互換性はそれほどは重要ではなく，コストパフォーマ ンスを低下させてまでポータビリティを向上させる意義は少ない．これは，小 規模な組み込みシステムの場合，別のプロセッサおよびその上の OS への移行 が必要になるのは，制御対象の機器の側にも変更がある場合が通常であり，ア プリケーションプログラムを修正なしに他の OS 上へ移植するという状況はほ とんどないためである．また，用いるプロセッサを変更した場合には，最終製 品のコストダウンのために，ソフトウェアのチューニング作業をやり直すこと も多く，ソースコードの完全な互換性が重視されないもう一つの理由となって いる．

以上の要求をもう一度整理すると，次のようになる．

• ハードウェアの性能を最大限に発揮できること

  MCU を用いたシステムにおいては，ハードウェア資源の制約が厳いため，与え られたハードウェアの性能を最大限に発揮できることが，リアルタイムOS を 採用する前提条件となる．前述したように，小規模な組み込みシステムにおい ては，ソースコードレベルの完全な互換性よりも，ハードウェアの性能を最大 限に発揮できることが重視される．

• ソフトウェアの生産性向上に役立つこと

  ソフトウェア生産性の向上は OS を用いる動機の 1つであり，重要なのはいう までもない．とりわけ，概念や用語の統一や，設計手法の標準化といった教育 面からの標準化が重視される．

• 各規模/多種類のプロセッサに標準的に適用できること

第一の問題点として，プロセッサのアーキテクチャの仮想化が，実行時性能の 低下を引き起こしていることが挙げられる．複数種類のプロセッサ上で動作す る OS を設計する場合には，それらのプロセッサに共通する仮想アーキテクチャ を想定し，その上に OS が構築されるのが通常である．しかしこの方法では， 実際のプロセッサのアーキテクチャと仮想的なアーキテクチャとの差が実行時 のオーバヘッドの原因となり，実行時性能の低下につながる．

次の問題点として，ソフトウェアの生産性を上げるために，小規模な組み込み システムには必ずしも必要でない高度な機能を取り込んだことで，OS のサイ ズが大きくなり，実行時性能も低下しているケースが多いことがある．そのた め，限られたハードウェア資源で動作させることが難しくなっている．

さらに，多く種類のプロセッサに共通に利用できるリアルタイムOS のオープ ンな標準仕様がないことも，大きな問題点である．半導体メーカは，自社のプ ロセッサ向けの OS しか提供しないし，OSメーカは，数多くのプロセッサをサ ポートしきれていない．標準仕様の欠如は，同じ用語を OS ごとに違う意味に 用いていたり，同じような機能は持っていても細部がばらばらで混乱を招きや すいといった問題を引き起こしている．

• ハードウェアの過度の仮想化を避ける

  ハードウェアの持つ性能を最大限に発揮させ，高いリアルタイム性能を得るた めには，仕様作成にあたって，ハードウェアを過度に仮想化することは避けな ければならない．μITRON仕様は複数種類のプロセッサ上に実装することを 目的としたカーネル仕様であるが，具体的な実装設計は，プロセッサ毎に独立 して行うことを基本方針としている．

  μITRON仕様においては，プロセッサ間で標準化する仕様と，実装に依存し て決めてよい仕様を明確に分離した．標準化した項目には，タスクのスケジュ ーリング規則，システムコールの名称と機能，パラメータの名前・順序・意味， エラーコードの名前と意味などが含まれる．

  逆に，標準化すると実行時性能の低下につながるような部分については無理に 標準化を行わず，標準化・仮想化による性能の低下を避けるように配慮した． 具体的には，パラメータのビット幅や割り込みハンドラの起動方法については， 実装ごとに決める方針としている．

• アプリケーションに対する適応化を考慮する

  アプリケーションに対する適応化とは，アプリケーションに必要となるカーネ ルの機能や要求される性能に応じて，カーネルの仕様や内部の実装方法を変更 し，システム全体として性能向上をはかるアプローチをいう．組み込みシステ ムの場合，カーネルのオブジェクトコードはアプリケーション毎に生成される ため，アプリケーションに対する適応化が特に有効に働く．

  具体的には，カーネルが提供する各種の機能をできる限り独立させ，アプリケー ション毎に必要な機能だけを用いることができるように考慮して，仕様の設計 を行う．実際，多くのμITRON仕様カーネルは，カーネル自身がライブラリの 形で提供されており，アプリケーションプログラムとリンクするだけで，カー ネルの必要なモジュールだけが組み込まれる仕組みになっている．また，シス テムコールの単機能化を行い，必要な機能のみ取り込むことを容易にしている．

• ハードウェアに対する適応化を考慮する

  ハードウェアに対する適応化とは，ハードウェアの持つ性能や性質に応じて， カーネル仕様や内部の実装方法を変え，システム全体としての性能向上をはか ることをいう．

• ソフトウェア技術者の教育を重視する

  組み込みシステムにおいては，あるシステム用に開発されたソフトウェアがそ のまま次に開発するシステムに使えることはまれであり，ソフトウェアの互換 性やポータビリティは，それほど重視されない傾向にある．それよりも，カー ネル仕様の標準化によって，ソフトウェア技術者の教育が容易になったり，用 語や概念の統一を通じて技術者間の意志疎通がスムーズになることが重要と考 えられる．

  μITRON仕様では，ソフトウェア技術者の教育を重視し，標準化を通じて一 度覚えた事が広く活用できるよう配慮している．また，仕様における用語の使 い方や，システムコール等の名称の決め方などは，できる限り一貫性を持つよ う配慮した．また，教育用テキストの作成にも力を入れている．

• 仕様のシリーズ化やレベル分けを行う

  多種多様なハードウェアへの適用を可能にするため，仕様のシリーズ化やレベ ル分けを行なう．過去に作成した仕様のうち，μITRON仕様 (Ver 2.0) は主に 8bit MCU など小規模なシステム向けに作成されたもので，ITRON2仕様は 32bitプロセッサなど大規模システム向けの仕様である．また，これらの仕様 の中でも，さらに機能毎の必要度に応じたレベル分けを行なっている．最新の μITRON3.0仕様では，システムコールのレベル分けにより，1つの仕様で小規 模なプロセッサから大規模なプロセッサまでをカバーしている (表-5)．

  表-5 μITRON3.0仕様におけるレベル分け

  レベルR (Required) μITRON3.0仕様カーネルに必須の機能． レベルS (Standard) 標準的なμITRON3.0仕様カーネルが持つべき機能． レベルE (Extended) 高度な機能や追加機能． レベルC (CPU dependent) プロセッサ，ハードウェア構成，実装に依存した機能． レベルX (option) システムコールの機能の一部として導入できる拡張機能．

  また，ネットワークで接続された分散システムのための仕様や，マルチプロセッ サシステムのための仕様も，一連の ITRON仕様シリーズの中で標準化作業を行っ ている．この内，分散システムのための仕様は，μITRON3.0仕様の中にも 取り込まれている．

• 豊富な機能を提供する

  カーネルが提供するプリミティブを少数に限定するのではなく，性質の異なる 豊富なプリミティブを提供するというアプローチを取る．ハードウェアやアプ リケーションの性質に適合したプリミティブを利用することで，実行性能やプ ログラムの書きやすさの向上が期待できる．

これらの設計方針のいくつかに共通するコンセプトとして，弱い標準化がある． 弱い標準化とは，共通化すると実行時性能の低下につながるような部分につい ては無理に標準化を行わず，プロセッサや応用に依存して決めてよい部分とし て残すアプローチのことをいう．弱い標準化の考え方により，多様なハードウェ アの上で，その性能を最大限に発揮させることが可能になる．

この内，μITRON仕様は，極めて限られた計算能力とメモリ容量しか持たな い MCU でも，実用的に利用できる性能を発揮することができたために，多く の種類の MCU 用に実装された．実際，ほとんどすべての日本メーカ製の 8bit MCU 用にμITRON仕様のカーネルが開発されているといっても過言ではない． さらに，MCU の適用分野が広がるにしたがって，各種の 16bit MCU，さらには 32bit MCU，MPU用にもμITRON仕様カーネルが開発され，トロン協会に登録 されているものだけでも，十数種類のプロセッサ上に 30近くの実装例がある (表-6)．また，μITRON仕様カーネルは，規模が小さく，比較的容易に実装 することができるために，ユーザが自社内専用に開発しているケースも多く， 製品化されているもの以外にも多くの実装例がある．また，フリーソフトウェ アとして配付されているμITRON仕様カーネルも，複数種類ある．

言うまでもなく，このように多くの μITRON仕様カーネルが実装されるの は，広い応用分野と極めて多くの応用事例があるためである．μITRON仕様 カーネルが使用されている機器の例を表-7 に挙げる．

また，前に紹介したトロン協会が 1994年に行ったアンケート調査でも， μITRON仕様が民生機器の分野において広く使われており，事実上の標準と なっていることがわかる (図-8)．また，自社製の ITRON仕様カーネルを使用 しているケースが多いことから，μITRON仕様が真にオープンな標準仕様と なっていることがわかる．

このように，μITRON仕様カーネルが広範な分野に応用されるにしたがって， それぞれの機能の必要性や性能に対する要求が，より正確にわかってきた．ま た，上でも述べたように，μITRON仕様カーネルを 32bit プロセッサ用に 実装するという当初想定していなかった適用例も出てきた．そこで，これまで の ITRON仕様を再度見直す作業を進め，1993年に，第3世代の ITRON仕様であ るμITRON3.0仕様を公開した [3]．μITRON3.0仕様カーネルの主な 機能を表-9 に示す．

表-9 μITRON3.0仕様カーネルの主な機能

タスク管理機能 タスクの状態を直接操作したり，参照したりする機能． タスク付属同期機能 タスク自身が持つタスク間同期機能． 同期・通信機能 タスクとは独立した同期・通信機能で，セマフォ，イベントフラグ，メ イルボックスの 3つの機能が含まれる． 拡張同期・通信機能 タスクとは独立した同期・通信機能のうち高度な機能を持つもので，メッ セージバッファ，ランデブポートの 2つの機能が含まれる． 割込み管理機能 外部割込みに対するハンドラを定義する機能． 外部割込みの禁止/許可などを行う機能． メモリプール管理機能 ソフトウェアによって，メモリプールの管理やメモリブロックの割当を 行う機能． 時間管理機能 システムクロックの設定や参照を行う機能． タスクを遅延させる機能． 時間をきっかけに起動されるタイマハンドラを扱う機能． システム管理機能 システム全体の環境を設定したり参照したりする機能． ネットワークサポート機能 疎結合ネットワークの管理やサポートを行うための機能．

また，カーネル開発側にとっても，カーネル仕様を標準化することの利点は大 きい．一例として，複数のプロセッサ上に μITRON仕様カーネルを実装し たメーカにおいて，最初に μITRON仕様カーネルを開発した時と 2回め以 降の開発とで，バグの原因となった工程を比較した結果を図-10 に示す．この 図から， 2回め以降の開発においては，上流工程に原因があったバグが減少し， 対策が容易な下流工程におけるバグが相対的に増加したことがわかる．

小規模なMCUへの実装

例えば，16bit MCU用のμITRON仕様カーネル TR900 では，プロセッサの動 作モードに対応させてカーネルも 2種類用意しているが，シングルチップ内に すべてのメモリを入れる構成を想定したミニマムモード時に，TCB (Task Control Block) のサイズを 8バイトにまで小さく押えている (表-11)．ここ で，レディキューなどのタスクのキューを作るためのタスクチェインに，次の タスクの ID を入れるようにすることで，メモリ使用量の節約が図られている ことがわかる．

この他にタスク毎に必要な領域として，スタック領域がある．汎用レジスタの 内容など，タスクのコンテキスト情報は，スタック領域に保存される．また， タスクの初期化情報を入れるために，タスク 1個あたり 7バイト (マキシマム モードでは 9バイト) のタスク定義テーブルが ROM上に作られる．

弱い標準化の考え方を積極的に利用した例として，同一メーカが同じ 16bit MCU用に，機能を絞って実行速度の向上やメモリの節約を行ったカーネルと， 機能の豊富なカーネルとの 2種類のμITRON仕様カーネルを用意している例も ある (表-12)．この表の中でタスク切替え時間とは，タスク起床を行うシステ ムコールを発行後，起床されたタスクが動作を始めるまでの時間をあらわす．

ここで挙げた 2種類のμITRON仕様カーネルの内，シングルチップ用のカー ネルでは，同時に動作しないタスクどうしでスタック領域を共有する機能を用 意するなど，メモリ使用量の一層の縮小を図っている [5]．

一般的に，RISCプロセッサはコードサイズが大きいと言われているが，組み込 みシステムではメモリ容量は限られているため，リアルタイムカーネルには， 性能だけでなく，コンパクトさも求められる．

RISCプロセッサ用のμITRON仕様カーネルの例としては，SHシリーズ用の HI-SH7，SPARClite用の REALOS/SP が製品化されている．HI-SH7 は，コード サイズが最小 2.4Kバイトから最大 11Kバイトと小さく，データ領域も前述し たタスク間でのスタックを共有機能を持たせるなど使用量の削減を図っており， MCU 内蔵のメモリだけでシステムを構築可能としている．

また，レジスタウィンドウを持つ SPARClite 上に実装された REALOS/SP は， タスク切替え時にレジスタウィンドウ上にあるアクティブなレジスタのみを保 存/復帰する，システムコール処理中はレジスタウィンドウを回転させないな どの工夫を行うことで，タスク切替え時間 13.0μS (2ウィンドウ)〜 17.9μS (8ウィンドウ)，最大割込みマスク時間約4μS の性能を実現し ている (測定条件: SPARClite評価ボード MB86930-EB使用，クロック40MHz， メモリ 0wait 動作時)．

そこで，すでに紹介した最新のμITRON仕様であるμITRON3.0仕様では， μITRON仕様カーネルを持ったノードを疎結合ネットワークによって相互接 続した分散システムをサポートするための機能を追加した．具体的には，通常 のシステムコールを使って，他のノード上のタスクやセマフォなどを直接操作 することができる．この機能を，接続機能と呼んでいる [3]．

μITRON3.0仕様の接続機能は，あくまで 1つの機器ないしはシステムを制 御するためのものであるため，ネットワークの構成はシステム構築時に静的に 決める必要がある．次のステップとして，別々に設計された機器が相互に接続 できることが重要となる．また，ネットワークの構成が動的に変化する状況に も対応しなければならない．この段階の仕様を IMTRON と呼び，次の世代の ITRON仕様と位置づけている (図-11)．

分散システムを構築する上で，各種の機器に同じ仕様のカーネルが使われてい ることで，機器間の通信インタフェースを単純化でき，実行時性能や開発効率 の向上につながる．つまり，分散システム環境の下では，μITRON仕様とい う標準カーネル仕様は現在以上に大きな意味を持つものと思われる．

その他の検討課題として，共有メモリマルチプロセッサシステムへの拡張であ る ITRON-MP仕様の検討 [6] や，ITRON仕様カーネル上のソフトウェアの開発 を支援する開発環境の標準化も，重要な課題と位置づけて取り組んでいる．

我々は，今後もトロン協会 ITRON専門委員会を中心に，μITRON仕様をさら に発展させていく方向で検討を続けている．