=========================================================================== セッションE1: 一般発表 事例報告 座長　：宮内新（武蔵工大） 会場　：B会場。横長に広く、机が縦6列、横10列。机は3人がけ。 参加者：25人程度 =========================================================================== ====================================================================== 「ネットワークプロセッサを用いたMobile IPv6高速パケットエンジン開発 　の紹介」 櫛下町 政隆○，武智 竜一，小野 英明 （富士通西日本コミュニケーション・システムズ，富士通研究所） （○：発表者） ====================================================================== * 高速パケットエンジンカードについて。 ブロードバンドの時代になり、インターネットのトラフィックが増大してい る。コアネットワーク、シェルネットワークの高速化が必要である。 L2 switch みたいにスイッチに特化することにより、性能の向上する方向に いっているが、また、ルータ機能も集約してきている。このとき、高機能、 高速なパケット処理が必要となる。 従来はパケット交換はソフトウエアで処理をしていたが、性能の限界があるの で、IPサービス、アプリケーションと連携した高速化のためのハードアシスト を使用したい。そこで、ネットワークプロセッサを搭載したパケットエンジン カードの開発を行った。（PCI long card, GbE port*2, Motorolaのネットワー クプロセッサを利用して実装を行った。） * 階層化mobile IPv6拡張方式 　階層ノードを必ず通るので、輻輳、非効率化がおこる。 　EN(eedge node)にパケットエンジンカードを適用し性能の向上をはかる。 * マイクロコードによる高速化ポイント 以下のような機能をネットワークプロセッサで行う。 　bindingキャッシュ検索 　パケットのカプセル化 　フレーム、v6 packetの解析 　ルーティング処理 * 性能評価 従来ソフトやっていた処理をハードウエアでやるようにした。カプセル化処理 が性能向上のポイントとなる。penIII 700MHzにおいて、softwareで実現した 場合は5万pps,ネットワークプロセッサを使用した場合には10万ppsくらいの性 能の向上がみられる。 * 能力向上施策 実際の処理能力の限界を見極めたい。フレーム解析、binding cache検索、ル ーティング情報検索(ここがおそい)、カプセル出力の処理がある。ルーティン グ情報検索はbinding cache検索と同時にすることができ、そのように実装を おこなったら40万ppsくらい性能が実現できた。 * まとめ ソフトウエアより格段あがり、またチューニングにより大幅に性能が向上す る。また、ネットワークプロセッサ上での実装なので、すべてハードで実装 する場合に比べ、ソフトウエアなのでチューニングしやすい。また、マイク ロコードで実現する内容により、いろんなノードに適用可能である。 開発環境は以下のとおりである。 　ネットワークプロセッサ Motorola C-5 DCP 　C-ware software toolset で C/C++で開発 工数は以下のとおりである。 　基本機能開発 4.6KLine / 17人月 　能力向上施策 0.6KLine / 3人月 Q&A Q:かなりしっかりしたルータを作れそうでよい。効率化のためにlookupをま 　とめてやるが、両テーブルのupdateタイミングが違うから、おかしくなり 　そうだが？ A:ライフタイムをきめてexpireしている。 Q:C-5 DCPにはどれくらいの規模がはいるか？ A:組込みだからあまりでかいソフトは入らない。限界がある。 Q:ソフトだけでやってるときにも高速化手法は有効？ A:有効。ソフトでもまったくおなじことがいえる。 Q:下位層でルーティングできないのか？ A:できない。 下位層でなんらかのタグをつけてやればできる可能性はある。 Q:ソフトとハードでテスト工数がどれくらいかわってくるか？ A:ソフトは半分くらいの工数でできる。ハードの電気的特性とか、実装上 　のテストがはいるから。 Q:FPGAとプロセッサでやるのはどちらがはやい？ A:FPGAのほうが早いだろうが、開発期間が長くなるので、トレードオフが 　必要だろう。 ====================================================================== 「組み込み制御向けオブジェクト指向設計手法とエレベータ制御への適用」 成沢 文雄○，本山 敦久（日立製作所） （○：発表者） ====================================================================== 保守性を向上させるために、クラスを用いて設計をしたい。従来の制御ではリ アルタイム制、信頼性が必要となり、さらに、セキュリティ、保守機能、カス タマイズが求められてきている。 ここで、OO設計手法が必要。ROOM, OCTOPUS, eUMLなどの手法があるが、実際 の製品にあまり適用されていない。移行の障壁が大きくてなかなかできていな い。それは、過去のソフトウエア資産があるからで、連続的に移行できるよう な仕組みが必要である。 エレベータは、かごが上下、ドアの開閉などがある。これらの運行を制御する のが、主な作業になる。地震管制、火災管制も必要となる。セキュリティー、 保守機能、カスタマイズが昨今はもとめられている。そこで、従来のリアルタ イム処理に加えて情報処理が必要となる。 従来のエレベータ制御はラダー図により仕様記述をおこなっていた。ラダー図 とはリレー回路をくむようにソフトウエアを記述する手法である。この記述法 は最悪実行時間を見積もりやすいが、構造化ができず、処理が見えない。 そこで、オブジェクト指向を導入した。 導入手順としては、まず、トップダウンに仕様を決めてボトムアップに従来の 設計をマッピングする。これを繰り返すことによって、移行していく。 シナリオを作成して、ユースケース分析を行う。アクタは乗客、エレベータ、 かご、ドアがある。実現すべき機能の全体像を把握するために、このようなこ とを行った。 この分析からおおきな８つのモジュールを切り出した。 　エラーチェック、モータ、運転方式、速度制御、運転制御、ドア、入出力、 　呼び登録データ である。これらからクラスを切り出した。 ドアのクラス図、状態遷移図のモデルを提示して実例をしめす。 オブジェクトモデルとラダー図のマッピングを行うことによって、従来のソフ トウエアとの対応付けをしたい。そこで、コイルと接点にオブジェクトを明示 するような拡張ラダー図を作成した。 開発内容としては、モジュール設計を導入し、オブジェクト指向実装、従来ソ フトウエアのモジュールかとリンク、シミュレータ上で動作確認した。C++/Cで ２ヶ月*４人で行った。エレベータプログラミングが得意な人が二人、OOPが得 意な人が2人という構成である。オブジェクト指向を導入した結果、仕様変更を 行うための手間が従来の50%以下で実装可能になった。 Q:今までアセンブラでかいていたが、C++でかくようになったのだから規模が 　だいぶ変わっているはず。いろんな付加機能がついて、さらに大きくなって 　いるが、実際どれくらい複雑になってきているか？: A:最近新しいマイコンにした。そのうえで、新しいソフトウエアアーキテクチ 　ャを作りたいという、背景がある。 　新機能としては、セキュリティ機能が一番大きい。マンションのエレベータ 　などで、そういう話が多くでてきている。 Q:安全性が必要であろうが、設計するに当たって開発、試験において注意され 　ているところは？ A:特別変わった手法はなくて、テスト項目を多くすることで対応した。テスト 　仕様書をきちっとつくっている。 Q:仕様に時間的要求がないようだが？ A:図にはかいていないが、実際はきまっている。ただ、数msecレベルでの話で 　はなくて、おもに順番に依存するようなシステムである。 Q:OOの導入には学習にかかる時間が問題であるが、実際にどんな感じで開発が 　進められたか？ A::OJT、徒弟制度で行った感じである。 Q:OOを導入してテストのやりかたがかわったか？ A:いまは同じやりかたで、やっている。クラス単位でテストを行うとうまく局 　所化できるのかもしれないが、まだできていない。 Q:データフロー図からラダー図へのマッピングをもう一度説明してください。 A:コイルとたいおうするクラスを主観的に人間がきめてやっている。機械的 　にはできない。 ====================================================================== 「計算機システム統合実験」 鈴木 貢○，河野 健二，楯岡 孝道，前田 洋一，阿部 公輝， 渡邊 坦（電気通信大学） （○：発表者） ====================================================================== LSIの集積度や設計技術の発展により、組込システムを全体として最適化する ことが可能になってきた。ハード、ソフトコデザインしたり、目的に応じてコ ンポーネントをカスタマイズ、必要な性能をより小さいコストや消費電力で実 現できるようになる。そのため、ハード＆アプリ屋のような枠にとらわれない 教育が必要になってきている。 電通大では、アーキテクチャは演算期作成、マイクロプログラミング、ネット ワークプログラミング、言語処理系の実装などを行っているが、関連性が薄く、 実際にどううごいてるかがわかりにくい。そこで、これらを組み合わせた統合 的な実験をおこなう。TinyIP(protocol stack), TinyC(compiler), MinIPS (processer)の実装をおこなうが、TinyCがおもな発表の対象である。 まず簡単に３つのモジュールを説明する。 MiniIPSはMIPSのサブセットで、浮動小数点などをぬいてほぼサポートしている。 TinyIPはIP, UDPをサポートし、階層化モデルと割り込みによる受信をサポート している。 TinyCはCのサブセットで、現実的なプログラムをコンパイルでき、学生がいじ りたくなるような内容であることを目標ににしている。C++の基本的な機能の みで記述しており、１パスであり、MIPSのアセンブリコードを出力するような コンパイラである。 オリジナルのTinyCではプロトコルスタックの実装が困難なので、拡張が必要 である。最低限の仕様を決める際には、大幅に違わないもの、ANSI Cにない機 能を付け加えないことを前提とした。16進数定数、論理、シフト演算、ポイン タの実装は最低限実装させることにした。 C実験のねらいと内容は、コンパイラの仕組みを理解し、緊張感、達成感、チー ムワーキングを経験させ、さらに、学生の自主性を引き出すことである。 実験の運営は、３時間、週２回。6めいずつのチームにわけ2名づつTinyIP, TinyC, MiniPISを担当させた。進捗表をかかせるようにしたら、学生の意欲が でるようになった。 実験環境としてはWinPC, SOPC, UnixPCの３台を使った。WinPCとSOPCはシリア ルでつながり、ホストとターゲットの関係がある。SOPC, UnixPCはネットワー クでつながっている。 実習の結果として17編のすべての学生が必修問題をクリアし、12編が自由課題 を実施してくれた。プロセッサにXORを実装した班が、コンパイラがXORを出す ように改良してくれたのがいちばんうれしかった。 感想としてあがったものとしては、 　ソースを読むのに強くなった。 　ミスがプレッシャーになった。 　中間管理職みたいでたいへんだった。 　プラモデル的でつまらなかった。 　C++の機能を最大限に活用すべき。 　、TinyIP, TinyC, MiniPSの関連がつかみがたかった。 というものがあった。 自己評価としては、 　字句解析からコード生成に至るまでひととおり理解できたが、レジスタ割付 　がからんだコード生成部の理解は難しかった。 　チームワーキング実施の意味があり、達成感を覚え、使わせてバグを発見、 　除去した経験がよかった。 　自由課題で自主性がでるように、自由課題をつくってよかった、 などがあげられた。 Q:当方でももやりたいと思ったが、学生の能力によらない教育は難しい、何か 　良い方法はあるか？ A:学生がみつけるのが難しい自由課題を、うまく与えておくのがよいのではな 　いか。今後、自由課題をねっていきたい。 Q:プロセッサはどこまでやったのか？ A:担当ではないので、詳しく説明できないが、できたプロセッサの穴埋め問題 　というような感じ。最初から全部作るのではない。これらの実習には授業が 　ついていて、まじめに履修した学生なら理解可能な範囲におさめた。 　イメージと実装のギャップが大きいので、それを埋める良い方法が無いだろ 　うか？ Q:(学生の)歩留まりはどれくらいを想定してるか？ A:Cが解っていれば、大丈夫ななように設定してる。実際、自分から勉強して 　る人はいい実装をしてきている。 　学部の３年生向けなのだが、ネットワークの授業は４年生にしかない。ネッ 　トワークの知識が無い学生向けなので、全部説明しなければならなかった。 　ネットワークアナライザの結果を見せてやると、イメージをつかみ易いよう 　だ。 Q:おもしろい発表でした。オープンコミュニティ的なものに参加して主体性を 　持ったものになるとおもしろい。 A:学生がそっち方向にいくとうれしいが、そこまでもっていくのは、われわれ 　の能力を超えている。 　しかし、そういうのに参加するのが怖くなくなるのでなないかと考えている。