「組込みシステムシンポジウム2010 (ESS2010)」参加メモ.
組込み分野における研究の最新動向の調査を目的に,
「組込みシステムシンポジウム2010 (ESS2010)」に
1日だけでしたが参加してきました.今回は,そのメモです.
http://www.ertl.jp/ESS/2010/index.php
1日でしたが,だいたい100名程度の参加者がいたように思います.
(論文発表,MDDチャレンジ合わせて)
- 講演メモ:
- 全体を通じて
- 投稿数は31稿.そのうち採択は実践論文7稿,研究論文ロング8稿,ショート8稿.ポスター12件.採択率75%であった.
- 優秀論文は加藤さん@茨城大.太田さん@農工大
- 優秀論文は普通は1本だが,甲乙つけがたく2本とした.
- 優秀報告賞:清水さん@日立オートモーティブ.稲森さん@豊田中央研
- [研究論文] SysMLモデルの制約妥当性検証に関する考察
- SysMLモデルの制約妥当性検証のために,SysML上で制約を記述,それをSMTソルバのYicesのフォーマットに変換する方法を開発したという論文.
- SysMLのパラメトリック図で制約表現ができるものの,制約が分散しがちとなるため,変換し,自動検証できるようにした.
- YicesはSMTソルバの一種.
- 流れとしては,SysMLモデル→Yices向けSysMLモデル作成→変換→Yicesで検証
- Yices向けモデルとしてステレオタイプの追加や制約式の線形形式での限定などがある.
- 論文中適用事例として,ETロボコンでも利用しているLEGOのロボットで特定ジャイロセンサ範囲内で,安定動作するかを検証している.
- 課題としては,t=0の時刻のみでしか検証していないこと.それ以外の時刻では外界からの影響やフィードバックなどを考慮するため複雑となる.また,非線形演算を含むシステムではYicesの制約上,線形演算への近似が必要となる.
- 今後の方針は,外界を含めた場合の実現および事例を増やすこと.
- [研究論文]共有メモリーシステムの性能評価のための粗粒度のシミュレーション手法
- マルチコア利用時のメモリアクセス競合による遅延を予測する方法に関する論文
- 基本的には調停時の処理時間と,代数方程式で求解する衝突確率をパラメタとして,遅延を予測している.
- 実際のアプリケーション動作との比較では誤差2, 3%程度.
- キューイングメソッドによる予測では,テストケースごとの速度がわからないため,提案手法を考案した.
- メモリアクセスはランダムに発生することと,CPU間のメモリアクセスのタイミングに相関がないことを仮定している.
- [研究論文]関数単位の振舞を考慮したプログラム実行トレースの特徴抽出
- 差分開発において,母体機種の性能およびトレースを利用して新機種の性能を予測する技術に関する論文.
- 関数の実行時間と呼び出し回数が可変であるか,固定であるかで4パタンに分類し,それぞれをモデル化する.
- 実行トレースサイズが膨大なので,トレースの抽象化が重要となるが,従来研究では関数種類数が減らないことなどが問題として存在する.
- 呼び出し回数が変動する関数は呼び出し回数をパラメタとして扱う.
- 実行時間呼び出し回数ともに変動する関数は別途詳細なモデル化が必要.
- 全体を通じて
以下は詳細&未整理メモ
■基調講演 10/28(木) 10:00-11:00
小惑星探査機はやぶさの開発と運用
萩野 慎二 (日本電気(株)) はやぶさPJマネージャー
- あけぼのPJ,ジオテイル,はるか担当
- 参加者数:80名位
- NECが日本発の人工衛星おおすみの通信機を作るということで衛星にかかわってきた.
- NECがシステムインテグレーターとして設計,製造,試験を行った.
- はやぶさのミッションはサンプルリターン技術開発のための探査機
- イオンエンジン惑星間航行
- 光学観測による自立制御
- 惑星表面採取
- 直接再突入
- はやぶさは,小惑星での,サンプルリターン,が新しい!
- 構成
- ほとんど燃料
- 宇宙用リチウムイオン電池
- 9個の分類からシステムを構成している.
- 開発における制約条件
- 質量の制約
- ロケットの能力の制約
- 探査機推進形の能力の制約
- 材料の開発,軽量化工夫.機器の絞込み.最小構成の追及.
- 軌道設計の工夫.運用の工夫.(地球でスイングバイ)
- ロケット能力と探査機質量の配分最適化(ロケット1段追加)
- 正解がわからないみちの小惑星
- 情報がない.
- 可能な限り地上からの観測.惑星科学の知見を集積.
- わからないことはできる限り地上で実証実験
- ワーストを想定しての設計条件(重力→運用設計,反射率・温度→熱設計,起伏・地形→知識結集)
- 新規技術,機器開発の実施
- 信頼性確保と実証.スケジュールキープをなんとかする.
- モチベーション・目標の共有
- 定期的な設計会議で全員が状況把握.共有.
- チームワーク
- できる限りの地上での実証試験.E2E試験
- 質量の制約
- 開発における技術課題
- 質量キープが最優先
- 最小構成からの出発
- 探査機のシンプル化
- 自由度を絞り込むことで検討をシャープにする.
- シンプルインタフェース化
- 運用がシンプルになった.その分,深く検討することができた.
- 全体を見渡せるようになった.
- 開発スケジュール
- 96年から開発
- 質量リソース制約から基本設計試作で多くのスクラップ&ビルドをした.
- 運用の概要
- タッチダウンリハーサルからナビやシミュレータを急遽新規開発することとなった.
- 1回目は障害物を検知して逃げようとしたが逃げなかったので,姿勢崩した.
- 2回目は障害物反応をきって,うまく降りれた.
- 1ビット通信(キャリアのH/Lのみ)で復帰当初はなんとかした.
- 帰りも新しい制御方式で.
- ターゲットから1kmくらいの精度で落下させられた.
- 分離までが運用のお仕事.
- あかつき:12月に金星軌道に入れる.
- イカロス:ソーラーセイル実験.
Q.ソーラーでどのくらい加速するの?
A.1g重くらい.ただ加速は明確.
Q.最初の方針で一番重要だと思っていたことと,結果として大事だなと思ったことは?
A.プライオリティでは質量.技術的にもなんにしても難しいものだった.40年間経験したことを備えとして持っていけたことが良かった.ものを減らすために,機能をロバストにしたことが良かった.
■論文発表
(*) ショートプレゼンテーション論文
10/28(木) 11:00 - 12:00 セッション1: 優秀論文賞セッション
- 参加者数:70名くらいかな.(前より減ってる)
□[研究論文] SysMLモデルの制約妥当性検証に関する考察
加藤 秀明, 上田 賀一 (茨城大学), 中島 震 (国立情報学研究所)
- パラメトリック図は可視表現できるため,属性の妥当性検証に役立つと期待される.
- 制約が分散するため確認が困難煮になる
- Yices(やいしす)で解析
- 振る舞い,要求図,構造図
- パラ目トリック図
- ブロック間の制約を可視化
- 属性の妥当性検証に役立つと期待
- Yices
- SMTソルバの一種
- TYPE, Vari, 演算子,式
- アサートで式評価可能
- SysMLモデル→Yices向けSysMLモデル作成→変換
- ステレオタイプの追加
- 制約式を線形形式での限定
- 適用事例としてロボコンロボ
- 特定ジャイロセンサ範囲内で,安定動作するかを検証.
- 検証対象にアサート分追加.制約追加
- 検査制約の否定で検査をおこなう.
- すべてのモデルでできるとは限らない.
- t=0のときのみでしか検証していない.それ以外のときはプラントとの関係が絡んでくる.
- Yicesは線形演算しか検証できないため,非線形演算を含む場合決定可能でないが近時できるならいけるかも.
- SysMLはさまざまな視点からいける.その点は優先度付けすればいけるかも.
- 今後
- プラント
- 事例増
Q.今回利用SysMLでできることは何か?
A.これというものは今思いつかない.
Q.パラメトリック図は制約?そうなら何にかかる制約なの?
A.関係間に関する制約.重量とか.モデル検査とはまた違う検査ができるかも.
□[研究論文] Dalvikアクセラレータ:Android端末におけるJavaアプリケーションの高速実行機構
太田 淳, 三輪 忍, 中條拓伯 (東京農工大学)
- Dalvik VM
- Java VMの高速化にJIT,AOT技術がある.
- Dalvik VM 2.2でJITがでてきた.
- Dalvikアクセラレータの開発
- 既存のHW実行としてARMのJazelleがある.
- Jazelleはオペランドスタックの上位を操作することが多い.そこを高速化で速く.
- Jazelle元に実装なので,MIPSアーキテクチャとなる.
- 固定長メモリフェッチから可変長バイトコードに
- 変換可能か命令の雛形
- 変換結果をデコードステージへ.
- デコーダの動作
- Opコードをチェックし,テーブルチェック.
- 2語目以降はテーブルの次を順次チェックし,実体情報を加え,MIPS命令を発行する.
- DRMTの追加
- 削減できるロードストア命令の評価
- 平均30%,最大40%の命令削減
- HWの実装はまだ.
Q.待ちおきない?パイプラインの空きがおきるのでは?
A.確かにおきるかも.
Q.Dalvik自身の性能は?
A.まだ評価されていない.
Q.NDKある環境でJava高速化はどのようなシーンでも求められるのか?
A.極力マルチプラットフォームにするソフトくらい.懸念事項である.
■10/28(木) 13:00 - 14:40 セッション2: ソフトウェア開発手法/性能評価
□[研究論文] 共有メモリーシステムの性能評価のための粗粒度のシミュレーション手法
河原 亮, 中村 健太, 小野 康一,
中田 武男 (日本アイ・ビー・エム(株) 東京基礎研究所),
坂本 佳史 (日本アイ・ビー・エム(株) グローバル・ビジネス・サービシズ)
- 目的:マルチコア実行時間の評価
- UMLは非機能要件が表現しづらい.特にアプリでどのくらいになるのかよくわからない.
- 2007のcortelessa:リソースもExecutableUMLで書くことで,評価できるようにしている.
- 課題:パラメータ.抽象度
- パラメタの与え方は研究済み.
- 今回は抽象度の与え方.
- 既存研究
- 高抽象度:キューイングメソッド.テストケースごとはわからない
- 仮定1:ひとつのステップ内のメモリアクセスはランダム発生
- 仮定2:CPU間でメモリアクセスのタイミングに相関がない.
- その結果,メモリアクセスの回数に依存せず計算が可能となる.
- 振る舞い情報(ステップごとの性能パラメター指定)
- アーキテクチャの情報(メモリを共有するCPU数の指定)
- 処理時間と衝突確率がキーパラメタとなる.
- アクセスの衝突による待ち時間は直後にアクセスがあるかないかで変わる.
- 衝突確率の数値的解法は基本はUの掛け算.ただし,調停による待ち時間を別途加えないと過小評価となる.
- 代数方程式となる.(例では反復法で収束計算で解いている)
- 処理時間と衝突確率がキーパラメタとなる.
- モンテカルロシミュレーションとの比較.
- 仮定が同じなので,似た結果となった.
- 実際のアプリ動作との比較では,2,3%.人工メモリアクセスのものでは19%くらい
- 人工メモリアクセスのパタンは最善・最悪パタンとなるため,
Q.バーストアクセスとかはどう扱う予定?
A.そのようなモデルを作って行う.
Q.メモリアクセス別にのパターンないか?
A.今回はラウンドロビンであるのでこれのみ.
Q.入力に依存してないか?
A.ある.今後の検討課題.
Q.多コアで代数方程式とける?(座長)
A.10コアくらいは問題ないけど,メニーコアになったらきついかも.
□[研究論文] 関数単位の振舞を考慮したプログラム実行トレースの特徴抽出
中村 健太, 小野 康一, 河原 亮,
中田 武男 (日本アイ・ビー・エム(株) 東京基礎研究所),
坂本 佳史 (日本アイ・ビー・エム(株) グローバル・ビジネス・サービシズ),
福岡 直明 (京セラミタ(株) 東京R&Dセンター)
- 組み込みシステムの性能評価を対象としている.
- 差分開発を前提としていて,どこが性能ボトルネックかを明確にして改良することを目的としていることが前提.
- 現行製品のリバースモデリングして,そのモデルの次期製品へ変更して,評価する.
- 現行製品を評価して,実行とレースを埋め込んでリバースモデリングする.
- 複写機でおこなっているみたい.
- 実行トレースサイズが膨大なので,効率よい取捨選択が必要
- そこでトレースの抽象化(捨象)が重要
- 従来研究:呼び出し元と先の関係による捨象
- 従来研究の問題点:抽象化の効率.抽象化の一般性.
- 関数種類数は減らないし,テストケースに依存してしまう.
- 従来研究の問題点:抽象化の効率.抽象化の一般性.
- 従来研究:呼び出し元と先の関係による捨象
- 実行時間に影響する要素
- ノード内が持つ情報から判断できる違い.
- コールツリーの構造から判断できる違い.
- 1.全体に影響を与える関数を抽出
- 2.テストケースによって異なる呼び出し回数の特徴から分類する
- 実行時間と呼び出し回数が著しく変動
- 回数は同じでも実行時間が異なる.
- すべてのテストケースで呼び出し回数が等しい.
- トレースデータから
- 呼び出し回数,呼び出しあたりの実行時間
- 変動する関数は呼び出し回数をパラメタとして扱う
- 実行時間呼び出し回数ともに変動する関数は別途詳細なモデル化が必要.
Q.利用したテストケースでもれることがあるのでは?
A.ある.今回のテストデータは普段使っているテストデータ.なので,もれている部分もあるだろう.トレースデータを効率よく特徴を取り出し,性能評価に利用したいという目的があった.
Q.パタンCはどうする?
A.パタンAと同じ.
Q.どこで使う
A.次期の性能評価
□[研究論文](*) 状態遷移構文とテスト構文を導入した組込みソフトウェア向けプログラミング言語の開発
岡山直樹, 片山徹郎 (宮崎大学)
- 状態遷移を多く持つときバグる.
- 特徴
- 状態遷移構文
- テスト構文
- 型チェックの効果
- 状態遷移構文
- アクション,ステータス,イベント
- テスト構文
- コンパイル時に自動シミュレーション
- テストシナリオと条件処理
- 型チェック
- すべての型宣言
- 型サフィックス
- 変数の値チェック
- 速度が遅い結果となった.変数の値チェックで処理が遅くなったと考えられる.
Q.変数代入の場合,オーバーフロー・アンダーフローはどうするの?
A.だめかも.【発表後の回答】オーバーフロー・アンダーフローは実バイナリに組み込まれ,リアルタイムにチェックされる.そのため,フローしたときにCPUのそこフローフラグ検知して止まる.3ビットの場合は値チェックでフローチェックする.
Q.実行バイナリ大きくなる?
A.テストに関しては,そうなることはない.
Q.アローの意味は?
A.実行
Q.どのフェースでテスト実行するの?
A中間コード時に分離して実行コードとテストコード生成する.
□[研究論文](*) 文書診断図を用いたソフトウェア開発文書の診断表現
藤田 悠 (長野工業高等専門学校),
山本 雅基 (長野工業高等専門学校/名古屋大学),
中澤 達夫 (長野工業高等専門学校/信州大学),
塩谷 敦子 ((同)イオタクラフト),
池田 貴一 ((株)ミマキエンジニアリング), 楡井 雅巳,
小野 伸幸 (長野工業高等専門学校)
- 開発文書の品質を計測する手法として文書診断法を提案する.
- 医療でいう診察・判定部分.
- テクニカルライティングとソフト開発の観点がある.
- 5つの診断種別とした.
- 技術:292件,ソフト:191件の 問題点指摘ができた.
- 改訂にどれ不だけ工数が必要か→指摘ごとに重み付け
- 複雑さに応じて改訂負荷係数を考える
- 意味と表記の問題に分ける
- 複雑さに応じて改訂負荷係数を考える
- 4つの領域で考える.
- 領域の改訂負荷→基礎的な能力を向上させる教育が必要
Q.大きさは強調されすぎるのでは.
A.ひとつの表現方法.
Q.改訂負荷の客観決定方法
A.試行の段階
Q.作業に時間かかるだろうが自動化はできるのか?
A.機械でできるところは自動化.支援ツールを考えている.
■10/28(木) 15:00 - 16:40 セッション3: 組込みハードウェア
□[研究論文] 中断可能な優先度継承キューイングスピンロックのハードウェア実装と評価
一場 利幸, 松原 豊, 本田 晋也, 高田 広章 (名古屋大学)
- マルチコア時のスピンロック要求あり
- ハードウェアで実装:PPIQL
- 楽チン
- 既存研究
- シングルロックではすでにある.
- ネストロック:2つのロックで(1)の要件を満たすものはあるが全要件を満たすものは存在しない.
- Totally FIFOをベースに拡張
- ただし,割り込み受付可能に拡張すると優先度逆転が発生することがある.
- そこで,優先度継承によって優先度逆転を低減する.
- PPIQL
- 割り込みが発生しなければTotallyと同じ
- ネストは2つ
- 2つで実装できるRTOSがあるため
- HW構成
- 優先度発行ユニット
- 優先度順スピンロックユニット
- 優先度継承はコア数が大きくないと効果が現れない.
- ソフト実装だと,1.59倍HWのほうが速い.
- 結構頻繁の例.
Q.OSのクリティカルセクション?APの方?
A.個人的に想定しているのはOS.
Q.APだとロックの数は想定しないのでは?
A.確かに.1つのロックで扱えるよう検討している
Q.優先度付けのところをロックしなくてもいいのか?
A.バスのHWまかせ.
Q.優先度比較するHWはコアが増えたときも対応できるのか?
A.アーキテクチャかわると再検討が要る.
Q.SWでもけっこういけてるんじゃ?
A.確かに.ただ,ハードリアルタイムのときに使えるのではないか.
Q.コアが増えるといいの?
A.いいはずなんだが,結果としてはよくなっていない.
Q.3コアがいいの?
A.動作パタンによるが,どれも速いととってもらいたい.
□[研究論文] デジタル/アナログ再構成可能プロセッサのアーキテクチャと設計環境
山脇 彰 (九州工業大学), 濱邊 真也 ((株)サニー技研),
芹川 聖一 (九州工業大学)
- GCCベースのオープン開発環境を用意する.
- MSRPアーキテクチャ
- 動的再構成とそのコントローラ
- FPAAとFPGA間に任意のスイッチをもうける.
- バスは自主的に行う
- FPAAからFPAA-Cライブラリへの変換は新規作成
- プロトではFPGA部にコントローラを実装し,FPAA含めた制御をおこなった.
- 試作におけるアナログ回路はローパスとADコンバータ
- 動的にデジアナ回路を切り替える例をしめした.
- 試作では精度は無視.
Q.OS/ドライバはどうなっているの?
A.メモリマップレジスタをほぼじか叩き.HostPCでセットアップして利用する.
Q.コンフィグを作っているように見えるが,実際やりたいことは?
A.今回はライブラリを用意する部分にフォーカスしている.FPAAコア上でのプログラムとかはこれからの検討課題.
Q.電力セーブはどういうこと?
A.使う回路のみ動かすので,最適な電力とできる.
□[研究論文](*) 組込みCPUへのHIGHMEM拡張の適用と評価
出原 章雄 (三菱電機(株) 情報技術総合研究所),
田原 康宏 (ルネサスエレクトロニクス(株)), 山本 整, 茂田井 寛隆,
落合 真一, 松本 利夫 (三菱電機(株) 情報技術総合研究所)
- 大量メモリ搭載によるAE機能を搭載するようになってきている.
- AEとは,仮想アドレスを維持したまま,物理アドレスを拡張するHW機能
- LinuxにはAEを扱うためのフレームワークHIGHMEMがある.
- 目的:試作SH-4Aで動作するHIGHMEM機能の開発
- 4GB, 128MB
- カーネル層:配置は新規開発
- ドライバ層,アプリ層:無効時同じ仮想アドレス空間にマップしている場合流用可能.
- 評価の観点
- ソフトの流用性
- HIGHMEN有効無効による性能差
- 数値演算とI/O
- 結果
Q.遅いのはLinuxで解決,ハードで解決.どっちがいい?
A.DMAはドライバの修正かな.Linuxもこれからからかな.
Q.32ビットはSATAの仕様?
A.今回使っているのが32ビット
□[研究論文](*) 組込みプロセッサ向け命令キャッシュ制御方式の検討
請園 智玲, 田中 清史 (北陸先端科学技術大学院大学)
- こんなことしたら,どうだろう論文.
- やる価値などの発表(ショートなので)
- 小規模命令キャッシュで何とかしないといけないが,クロックあがってもどうしようもなくなるのではないか.
- スラッシング緩和を目的とする.
- 同一インデックスに短時間集中アクセス
- キャッシュミスが続く.
- フィル制御の方式を考える.
- バッファに入れる.
- 命令バッファ
- FTSをもうける.
- 振り分ける.
- 命令キャッシュと同時に参照できる.
- FTSをもうける.
- バッファをもうけること,少なくとも入れたものをキャッシュヒットする.
- どのブロックを入れるか入れないかが肝となる.
- 一度実行させてプロファイルを採取する.その後,入れる入れないの評価をして,セットする.
- 平均で21%程度のキャッシュミス率削減実現
- 性能低下がない.
Q.容量は?
A.16バイト,追い出す.
Q.wayが増える感じなのになんで?
A.ループ
Q.ほか手法に対するアドバンテージは?
A.やってないのでこれから.勉強させてください.