組込みシステム用  バージョン  対応  プロトコルスタック   （第回   アワード応募書類 特徴の説明書）
阿部 司

吉村 斎

稲川 清

苫小牧工業高等専門学校 情報工学科
ラザ及び北海道立工業試験場でも実施されている。

  の概要



現在インターネットで主に使用されている バージョン （ ）は、アドレスの枯渇等の問題があるため、  バージョン （ ）の開発が進められており、実験段階を終えようとしている。今後は、  から  への移行が本格化することが予想され、組込みシステムにおいても、  への対応が必要となる。  のアドレスが  ビットに対して、  のアドレスは  倍の  ビットとアドレス空間を大幅に拡大したほか、  ヘッダ長の固定化やアドレスの自動設定など、  の欠点を改良している。このため、これらの処理に伴いプロトコルスタックのメモリ必要量の増加が予想されるが、組込みシステムのメモリ容量には厳しい制約あるため  、その対応が必要である。
  プロトコルスタッ
組込みシステム用のは、昨年第  回   デザイクである
ンアワードの  賞  を受賞した時点で、リリース（）であり、  のみの対応であったが、リリース （）からは  にも対応した。メモリ必要量に関しては、
で、ネットワーク層として  を組込んだ場合は、
 のメモリ必要量が約  バイト、 のメモリ必要量が約  バイト、メモリ必要量の合計では、約  バイトである。これに対して、実装方法を工夫することで、  を組込んだ場合でも、 のメモリ必要量が約  バイト（増）、 のメモリ必要量が約  バイト（増）、メモリ必要量の合計では、約  バイト（増）と  のメモリ必要量の増加は大きいが、より制約の厳しい  のメモリ必要量の増加を低く抑えることが出来た。
は、幅広く誰でも自由に利用・変更・配布できるように、オープンソースで配布している。
また、名古屋大学情報連携基盤センターで行われている名古屋大学組込みソフトウェア技術者人材養成が教材としてプログラムの中級コースで、使用されている。同様の研修は、福島県ハイテクプ

 実装方法 に関しては、 のベースとなった

! の  プロトコルスタックに実装されている各種アルゴリズムは、長年のインターネットにおけるプロトコル開発の成果が反映され、枯れたソフトウェアとなっており、事実上、他のシステムの見本となっている。そのアルゴリズムは  プロトコルスタックの組込みシステムのベースとしても最適であるが、動的割当て構造体とリスト構造を積極的に使用しており、メモリ容量やリアルタイム性の制約から、そのまま組込み  プロトコルスタックに適用すシステムのることは適当ではない。このため、われわれは、動的割当て構造体とリスト構造を使用しないように、!の  プロトコルスタックを改良  プロトコルスタッ
し、組込みシステム用
 を実装した。
ク
一方、  に関しては、 プロジェクトによる  ソフトウェアは、実装方法に関してフィールドで十分な検証がなされており、組込みシステムの  実装のベースとしても最適である。
しかし、やはり動的割当て構造体とリスト構造を積!の  プロ極的に使用しており、トコルスタックと同様の問題がある。
また、 " プロジェクトにより、非  系ディジタル機器への適用に向けた  最小要求仕様の検討  が行われ、組込みシステムの  への対応方法として参考となる  最小ホスト仕様を規定している。
 をベースとしそこで、われわれは、!の  プロトコルスタックをて、改良した同様の方法により、 プロジェクトによる  ソフトウェアを動的割当て構造体とリスト構造を使用しないように改良し、  最小ホ  プロトコルスタックスト仕様に適合する を実装した。

½ 名前の由来は、  の略称である

  の特徴に、インターネットのを組合わせている。

 最小ホスト仕様の概要（）メモリ容量は、 が  バイト、が  バイト程度で、メモリ管理ユニットなし。また、組込みシステム用プロセッサの現状では、 容量には比較的余裕があるが、 容量はあまり余裕がなく、 容量の制約への対応が重要である。
  の各ヘッダは、 ビット単位で処理す（）ると効率が良いため、 言語の ()* が  ビットで、レジスタと  も  ビットが望ましい。

 最小ホスト仕様では、  最小ホストを以下のように定義している。

¯ ルータでないホスト¯ 拡張ヘッダの付いたデータグラムを送信しない¯ ネットワークインタフェースを  つだけ持つ
また、  最小ホスト仕様の概要を以下に示す。
（）  基本仕様（ ）拡張ヘッダのついたデータグラムを送信しない。受信に関しては、  に定められている最低限の処理を行う。特に、メモリ容量の制約から、断片化されたデータグラムの再構成処理は最も省きたい機能であるとしている。
（）  近隣探索（ ）以下に示すルータ用の機能を省略できる。
¯ ルータ通知メッセージの送信¯ ルータ要請メッセージの受信¯ 向け直しメッセージの送信（）  アドレス自動設定（ ） 最小ホストであっても、ルータ用を除く近隣探索機能は必須なので、アドレス自動設定機能は原則として全て実装すべきである。
（） （ ）ルータでしか使用しない機能は省略できる。

動作環境と使用したツール

実装ターゲットに関して、プロセッサは、（株）ルネサステクノロジ製 " " シリーズの " 'である。" " シリーズは、 ビット  であるが、レジスタと  が  ビットである。ただし、内蔵  容量に余裕はあるが、内蔵 容量は " ' でも  バイトと小容量のため、現在は外部  を増設している。また、ネッ 互換のイーサトワークインタフェースはネットである。
 自体の開発に関して、われわれの開発環境では、+()&,-.  ! 上で動作する /01-()と、クロス開発用ツールである 2コンパイラ
バイナリツール等を使用しているが、#と2カーネルと同じ開発環境であり、()34 等の開発環境で開発を行うことも可能である。

 リアルタイム  とネットワーク が現在対応する組込みシステム用リア
ルタイム  は、   プロジェクトで開発された # カーネルである。# カーネルは、μ  仕様のスタンダードプロファイル  準
拠で、高い実行性能と小さいメモリ使用量を特徴とし、オープンソースで配布されている。
また、応用プログラムとのインタフェースとなる には、   を実装した。
 
本仕様は、
（社）トロン協会の $%&&&技術委員会により策定され、  専門委員会により '' 年  月に認定された。しかし、本仕様の策定時には、  に関する仕様が完全にフィックスしていなかったため、  への適用方法は別途検討することになっており、 年  月より検討を開始する予定である。このため、われわ  （バージョン ）
れは、暫定的に
 仕様を規定し、この仕様に従って実装を行った。

開発の経緯
われわれは、 年  月より、研究・教育に使用  プロトコする目的で組込みシステム用のルスタックの研究・開発を開始した。その後、
年  月からは、「組込みシステム・オープンプラットフォームの構築とその実用化開発」プロジェクトに   仕様に規参加するとともに、 定されている基本機能の全ての実装を開始した。そリリーの実装が完了した  年  月に、ス  の公開を開始した。さらに、 年  月に、リリース  を公開し、 年 '改良した
月には、  対応のリリース  を公開しており、 年  月末までに、約 5 件ダウンロードされている。また、複数の企業が採用予定であり、「組込みシステム・オープンプラットフォームの構築とその実用化開発」プロジェクトにおいてを採用しており、そも、 企業、 公設試での波及効果が期待されている。



対象とする組込みシステムの規模
組込みシステム用プロセッサの規模には幅があるが、あまりにリソース制約の厳しいプロセッサに、
  プロトコルスタックを実装することは現 は、以下に実的ではない。このため、示す規模の組込みシステムを対象としている。

  の実装
 ネットワーク階層構成 のネットワーク階層構成を図  に示す。上は応用プログラムインタフェース（ ）から、下はイーサネット・ディバイスドライバま で実装した部分である。
での太枠内がは、機種依存性をできるだけ排除し、多様（） 仕様のスタンダードプロファイ
ル準拠のリアルタイム  が動作するプロセッサ及びシステム。
応用プログラム
応用プログラムインタフェース（

        ユニキャスト  アドレス）

近隣探索





   

汎用イーサネット制御

 カーネル

イーサネット・ディバイスドライバ

プロセッサ、イーサネットインタフェース図  （ ）のネットワーク階層構成

図

アドレス有効時間
フラグプレフィックス長    マルチキャスト  アドレス 

 ネットワークインタフェース構造体 ! "# メモリ容量の制約への対応（） 必要量の抑制な組込みリアルタイム  に対応するため、リアル の制約に比べると  の制約が厳しタイム  と応用プログラムの中間のミドルウェアいため、 が必要なアルゴリズムの使用はとして位置付けており、もリアルタイム避け、 に割当てられるプログラムによる の各種サービスを利用して動作している。
処理を優先した。以下に、例としてプレフィッ  最小ホスト仕様への対応
クスに関する実装方法を示す。
（）拡張ヘッダ¯ 経路選択等では、  アドレスのネットワー拡張ヘッダ付きデータグラムを送信しない。
ク部を取り出すために、プレフィックスマ受信に関しては、  に規定された最低スクを用意しておく方法がある。しかし、限の処理を行うが、メモリ必要量に影響しない では  バイトのメモリが必要となる範囲で、送信者に  エラー通知を行っていため、必要時にプレフィックス長からプレる。以下に各拡張ヘッダの処理方法を述べる。
フィックスマスクを生成する方式とした。
¯ 中継点オプションと終点オプションは、パ¯ ネットワーク部の比較に関して、プレフィディング以外のオプションを全て未知オプックスマスクで取り出したネットワーク部ションと見なし、オプションタイプの指示を比較する方法がある。この場合も、マスにより後処理を行う。
クしたアドレス  個分の  バイトのメモ¯ 経路制御ヘッダは無視する。
リが必要になるため、プレフィックス長だ¯ 断片ヘッダ付き  データグラムは全て破けアドレスを比較する関数を設けて、メモ棄し、最後の断片ヘッダ付き  データグリを不要としている。
ラム受信時に、エラーを送信者に通知する。 （）  アドレスの制限¯ 認 証ヘッダと暗号化 ヘッダの付いた 
割当て可能なアドレスを、リンクローカルアデータグラムは破棄する。
ドレス、サイトローカルアドレス、グローバル（）近隣探索
アドレスの  個に限定し、静的に割当て、プレ では、以下の機能を実装した。
フィックスリストの管理も簡略化した。
¯ 近隣探索要請メッセージの送受信（）構造体の静的割当て¯ 近隣探索通知メッセージの送受信
以下に示す構造体は、個数を限定し構造体配¯ ルータ要請メッセージの送信列で静的割当てしている。
（）内は、個数と  エ¯ ルータ通知メッセージの受信ントリのバイト数で、個数が 2 となってい（）アドレスの自動設定
る構造体は、コンパイル前のコンフィギュレー
 では、以下の機能を実装した。
ションで割当て数を決定する。
¯ リンクローカルアドレスの自動設定¯ 近隣アドレスキャッシュ（ 2、）¯ アドレスの重複検出¯ 重複アドレス検出情報（、）¯ ルータ要請メッセージの送信¯ ディフォルトルータ（ 2、）¯ ルータ通知メッセージの受信¯  アドレス（、）（） ¯ マルチキャスト  アドレス（、） では、ルータでしか使用しない¯ マルチキャスト  アドレス（、）
機能と、ノード情報照会・応答機能及びマルチ一例として、ネットワークインタフェース構キャスト受信者照会・報告機能を省略した。
造体  を図  に示す。ネットワークイ
表機能
近隣探索
%
. 共通

汎用通信機能イーサネットバッファ管理通信機能計
応用プログラム
カーネル合計$% バイト

バイト

$ と  のメモリ必要量の比較%&
増減率
$ 増減率バイト

'  '  () *'+$*',' ) $',++$ )' )($,* '$($$* ) ' *'+'+) ' $' -* '($ ,-) -'$(-'+$ -'+$ )*'-- '(+*) $ '+',('*(* ) -'$+'-(* +'$ $) - '+'+ -'+$ --) ( '$+バイト

(',*$$-)$',(*)' ('* $-()-'- $  )$' $$)'* , )-'(($$$)*)-'$ -++)-', $)- '+$$ )*'- *$)

計

$

バイトバイト-' $*+'**

'
($
' ,
'*-',,
+' *
-',(
+ '*-
'*- '( *-'(,*増減率- '($$$)+'((*)'$$'* $-()-'- $  )$' + **)-'( *+-)'**,)-',(),-'($ - )'  )- '( $ )- '+ $+$)

ンタフェースは  個だけであるため、構造体で、近隣探索処理におけるメモリ必要量の増 も  個だけ静的割当てしている。ま加が大きい。また、 のメモリ必要量の増た、アドレスも、リンクローカルアドレス、サ加も大きく、 全体のメモリ必要量における増加量の合計は  バイトであり、近隣探イトローカルアドレスおよびグローバルアドレ索処理による増加が、 バイト（増加合計のスの  個に限定したため、構造体  内）になった。近隣探索は、  の特徴的に、配列   として静的割当てした。
これらにより、 による  の実装でな機能であるが、 と  のいずれも、は  バイトを超えるメモリを必要とする構造他の階層に比べて最もメモリ必要量が多い。
体  のメモリ必要量は  バイトとな （） り、大幅にメモリを節約した。
 の必要量の増加率は 'であるが、 の機能を省（）ディフォルトルータの制限ルータでしか使用しない複数のルータからのルータ情報を受信可能
略したことにより、 のメモリ必要量の増加はなく、 のメモリ必要量の増加も であるが、個数はコンパイル前のコンフィギュバイトで、増加を低く抑えることができた。
レーションで決定し、超える場合は、有効時間
（）を考慮してルータ情報を入れ替えている。
 のメモリ必要量が増加しているが、こ  と  のメモリ必要量の比較
れは  において、アドレスの比較やコピーネットワーク層として、  と  を選択しが単純な演算ではない事や、拡張ヘッダをスた時のメモリ必要量の比較を表  に示す。ネット
 ヘッダを探索する処理等に起キップしてワークインタフェースはイーサネットで、応用プロ因するものである。
 エコーサーバとクライアン
グラムとしては、（） ト、及び  エコーサーバとクライアントを実装
 のメモリ必要量の増加が と大した。以下に、  に対する  のメモリ必要量きいが、基本入出力部はそれほど増加はなく、の増加を考察する。
拡張ヘッダの入出力処理による増加が大きい。
 に関する  のメモリ必要量の を、（）全体的なメモリ必要量の増加
この拡張ヘッダの入出力処理が占めている。
全体的には、 のメモリ必要量は  バ  共通機能（）イト増加し、増加率が であり、 のメ  共通機能も、 のメモリ必要量モリ必要量は 5 バイト増加し、増加率がの増加が多い。これは、  のアドレス管理である。メモリ全体では、5 バイトや汎用アドレス操作関数による増加である。
増加し、増加率が  であるが、対象とする（）イーサネット
規模の組込みシステムのメモリ容量の制約を満イーサネットでは、 のメモリ必要量のたしている。特に、 のメモリ必要量の増増加は  バイトで、増加合計の となっ加を極めて低く抑えることができた。
た。これは、図  のネットワークインタフェー（）近隣探索
ス構造体  による増加である。また、
 全体のメモリ必要量における増加量の で必須になったマルチキャストアドレス合計は 5 バイトであり、近隣探索処理ににより、 のメモリ必要量が増加した。
よる増加が 5' バイト（増加合計の '）表機  の %  のメモリ必要量
能

近隣探索


. 共通
汎用通信機能バッファ管理イーサネット
通信機能計

固定部分

-

-*


$*-

-


変動部分

' *'$'$-'+$
 $
'--

また、ネットワーク環境が異なるが、 エ コーサ ーバを、6. ! 環境で同じクライアントと接続し、同様の計測を行った結果は ' 秒であった。従っ の実て、汎用計算機に比べても極端に行性能が劣るわけではない。
 上 に実装し た同様 の計' '
++$$*'+-'+$'($'(-今後の課題（）断片ヘッダの実装
 最小ホスト仕様に対応するため、断片単位はバイトヘッダの実装は行っていない。しかし、 の 相互接続性を保 障する  6&0 ,1,,16$ では、断片ヘッダの実装が必須であり、  6&0 ,1, 取得のために、断片ヘッ
表 -    の実行性能
ネットワーク層
平均セグメント数
平均転送時間ダの実装方法を検討中である。
$,* $-*-*（） のメモリ必要量の削減($ +$ ,*
表  から、ネットワーク層が  又は 
時間単位は秒のいずれの場合も、応用プログラムを除いた のメモリ必要量は、約  バイトである。今回実装ターゲットとした " ' の の容量は  バイトであり、以下内蔵
表  の  のメモリ必要量は、表  に示すよ を不要に出に示す改良により、外部増設
うに、応用プログラムの構成やネットワーク負荷と来る可能性がある。
は無関係な固定部分と、関係する変動部分からな¯ スタックサイズの最適化る。表  の固定部分は、これ以上削減することは¯ ネットワークバッファ長と個数の最適化困難であるが、変動部分に比べて非常に小さい値で¯ クライアントにおける 受付口の省略あり、この程度であれば、対象とする規模の組込み¯

受付口、
通信端点、
 通信システムでは問題はないと考えている。変動部分に端点の動的な生成と削除
 受付口、
 通信端点、  通信端点、は、¯ ネットワークインタフェース構造体に設定内部で使用して近隣探索キャッシュ、及びする  アドレスいるタスク用スタック等が含まれており、応用プログラムの構成やネットワーク負荷により、ターゲッ の研究・開発は、「組込みシステ謝辞
トの組込みシステムの  容量に適合するようム・オープンプラットフォームの構築とその実用化に調整し削減可能である。
開発」の一テーマとして、経済産業省東北経済産業



局様 （委託先管理法人7 財団法人みやぎ産業振興機構様）からの委託により実施しました。この場を借りて、各関係機関の皆様に感謝いたします。

実行性能 は、少ないメモリ必要量で実装することを第一目的としているため、実行性能を指向し
た実装は行っていないが、参考としての実行性能を示す。
 エコーサーバを実装した実装ターゲット（" '）を 6. 環境で、クライアント（    互換機、プロセッサ7)*(3$2"8、7  '）と接続し、実装ターゲットに対して、クライアントから
5 オクテットのデータを送信して、全てのデータのエコーバックが完了するまでの時間を、 と  のそれぞれで計測した。
結 果を表  に 示す。  の 平均転送時間は、
 に比べて  秒（'）遅くなっている。これは、  ヘッダ長が  オクテットから、 オクテットに増加し、その分、 データグラム当りのペイロード長が短くなったことにより、平均セグメン
ト数が '増加していること、  部と近隣探索部での処理量の増加が反映されていることが原因である。しかし、わずかな差であり、  とほぼ変わらない性能となった。

参考文献
9: 高田広章7

組込みシステム開発技術の現状と展
望5 情報処理学会論文誌5 ;,< 5 == '>'?@9: 阿部司5 吉村斎5 稲川清7

オープンソースの組  プロトコルスタック7
込みシステム用5 第  回 
 デザイン・アワード受賞論文 ?@9: 岡部宣夫5 石山政浩5 井上淳5 筬島雅之5 坂根昌
一5 左治木次郎5 野口敬5 宮田宏7 非  系ディジ
タル機器への適用に向けた  最小要求仕様の検討5 情報処理5 ;,< 5 == '>' ?@ 
9: 坂村健（監修）5 高田広章（編）7
仕様 5 トロン協会 ?@9: 高田広章（編）7
   仕様5 トロン協会 ?''@