一般発表2 セッション E1 「オブジェクト指向」会場　　　：B会場参加者　　：40人程度 ==================================================== オブジェクト指向組込みシステム開発におけるタスク分割 ==================================================== ==== 目的 ==== 並列実行単位とオブジェクト単位を独立して扱う開発の紹介 ================================ 制御モデルパターンと実際のモデル ================================ 制御モデルパターン (SWEST3-予稿集図1 制御モデルパターン pp.111参照) +----------+ +----------+ +----------+ | 制御入力 |----------| 制御体 |----------| 制御 + +----------+ * 1 +----------+ 1..* * +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ +----------+ △ ｜ +--------------┴---------------+ | | +----------+ +----------+ +---|論理制御体|-------------------|物理制御体| | * +----------+ 1 * +----------+ | +----------+ +----------+ | +----------+ +----------+ | | 1 | 1 +--------+ | 1 +----------+ | 制御出力 | +----------+ +----------+ +----------+ 例題システム : ラジコンカーシステム・コントローラは2chのスティック+2ボタン・スティックは操舵と速度制御ユースケース例デモユースケースシナリオシステム : ラジコンカー目的 : ラジコン操縦者事前条件 : 車が停止している事後条件 : デモ用制御プログラムが稼動している基本系列 : 1. アクタがデモボタンを押す 2. システムは車の停止を検出する 3. システムはデモンストレーションモードを実行する代替系列 : 1. アクタがデモボタンを押す 2. システムは車の走行を検出する -> このままシステムは何もしない停止ユースケースシナリオシステム : ラジコンカー目的 : ラジコン操縦者事前条件 : 車が走行している事後条件 : 車が停止している基本系列 : 1. アクタが停止ボタンを押す 2. システムは車の走行を検出する 3. システムは車を停止する代替系列 : 1. アクタがデモボタンを押す 2. システムは車の停止を検出する -> このままシステムは何もしないクラス図 (SWEST3 予稿集図3 クラス図 pp.113参照) シーケンス図移動 (SWEST3 予稿集図4 移動シーケンス図 pp.113 参照) 操舵 (SWEST3 予稿集図5 操舵シーケンス図 pp.114 参照) 停止 (SWEST3 予稿集図7 停止シーケンス図 pp.115 参照) デモモード (SWEST3 予稿集図6 デモモードシーケンス図 pp.114 参照) -> 3つの非同期メッセージ ========== タスク分割 ========== タスクは三つ必要 +--------------+--------------+--------------+ | T1 | T2 | T3 | +--------------+--------------+--------------+ |コントローラ: |車体: |操舵輪: | | 移動 | デモモード| 操舵 | | 操舵 |駆動輪: | | | 停止 | 移動 | | | デモモード| | | |車体: | | | | 移動 | | | | 操舵 | | | | 停止 | | | |駆動輪: | | | | 移動 | | | +--------------+--------------+--------------+ 駆動輪の移動はリエントラント車体駆動輪のデータメンバは排他制御が必要 ==== 特徴 ==== - 必要なタスクを最小化できる - 実装字に余分なコードが必要ないので、軽いプログラムとなる - 一つのオブジェクトを複数のタスクから参照するので、複数のタスク間でメモリ空間を共有できるシステムであることが必要 ====== まとめ ====== 制御モデルパターンと今回の例題システムのモデルを示したシーケンス図を通してタスクがメッセージの同期/非同期に対応して分割できることを示した ======== 質疑応答 ======== Q: メソッドが同期/非同期と決まっているのはなぜか A: 事前条件によってある程度予想可能。システムのハードソフトが見えて　くるあたりから、予測は可能になる。 Q: メッセージの同期/非同期という観点からタスク分割を想定するという　ことでよいのか A: その通りである Q: このようなやり方をすると、プログラム(コーディング)が難しくなるので　はないか A: C++やオブジェクト指向の理解は必須。書き方のパターンを覚えなければ　ならないということはないと思う。詳細に関しては、現段階では応用例が少ないので、検討・検証が必要。 Q: メンバの規模はどの程度か A: 3-4人程度 Q: C++でメソッド呼び出しをしたとき自動的にタスクがおきるようにした　方法は A: privateなメソッドをpublicなメソッドでラップすることで行なっている。実際に目的の動作をするのはprivateメソッドであり、publicメソッドでおきる命令を入れている。コメント: データ主体(Data Parallel)と処理主体(Control Parallel)の2つの観点がある。Dataの方はうまくいかなかったが、Controlの方はJavaやCORBAという形で生き残っている。 Q: 非同期メッセージを単一タスクで実現できるという意味なのか？ A: 非同期であるところはタスクであるべき。ただしタスクの数は減らしたい　という方針。 Q: メッセージを全てタスクにしようというのか A: アクティブパッシブに分割し、アクティブなものをタスクにすべきと認識　している。 Q: どこの動作がどのタスクに割り当てているのか図示する方法は考えているのか A: 現状では行なっていない。これは将来の課題である。 ====================================================== 組込みシステム向けオブジェクト指向フレームワークの開発 ====================================================== ==== 背景 ==== 大規模化複雑化 TimeToMarketの短縮 -> オブジェクト指向技術への期待 -> しかしうまくいかない上流工程における適切なモデル化の不備実装へ展開するときに伴う困難タスクとオブジェクトの直交性デバイスの多様性/変更蓋然性 ======== 問題分析 ======== タスクとオブジェクトの直交性タスク : 機能で分割オブジェクト : 概念で分割 -> 視点が異なる 3つの問題点 - 分析/設計時におけるモジュール分割単位の違い - 実装時におけるプログラミングパラダイムの違い - 設計/実装におけるタスクという概念の違いデバイスの多様性/変更蓋然性ドライバのインタフェースを提供するにはノウハウが必要ドライバ自体の実装も大変 =============================== マルチタスクフレームワーク(MTF) =============================== フレームワークの目的リアルタイムOSの効果的利用再利用性が高く効率よい部品を作る開発の動機論理に必要な並列処理単位スケジューリング上必要な並列処理単位 -> 区別して実装したい -> モデル崩壊の防止並列動作に必要なメカニズム -> 構造化利用を目的内部(抜粋) +----------+ |MTF::Actor|-----+---- キュー ----- RTOSキュー資源 +----------+ | | send() | | | run() | +---- タスク ----- RTOSタスク資源 | start() | +----------+ ====================== デバドラフレームワーク ====================== 目的デバイスの仕様に対するアプリの柔軟性を確保するデバイスドライバ自体を簡単に作りたいデバイスとユーザ定義制御文の間にコンポーネントを詰めてドライバを作る動機デバイスはもともとオブジェクトとして扱いやすい実装上の方を統一できるようにしたかったデバイスインタフェースはしっかり切ろう扱いデバイスがたくさんある出来ることはデバイス毎に決まっている低レベル部分は前もって用意できる DDF内部 +------------+ |DDF::polling| +------------+ | start() | +----------+ | onChange()|◇---------|DDF:ポート| +------------+ +----------+ △ +----------+ ｜ +----------+ +------------+ △ | 位置センサ | ｜ +------------+ +------------------+ +------------+ |位置センサ用ポート| +------------+ +------------------+ +------------------+ +------------------+ ======== 適用事例 ======== エレベータシミュレータ Windows上でのシミュレーションと同じコードが実機でも動いたモデル (SWEST3 予稿集図5 エレベータシステムのモデル pp.121 参照) ============================ クラス設計とタスク設計の評価 ============================ クラス間のイベントシーケンスを洗い出しイベントの動機/非同期を分類タスク分割を意識することなく、イベントから並行性の有無を特定無理なくクラス設計を実装へ展開 ======================== デバイス変更に対する評価 ======================== シミュレーション環境からボード環境への移行アプリケーション部の変更は皆無 I/Oポートを置き換える作業が大半 ====== まとめ ====== 分析/設計モデルから、実装に展開する際の問題を分析 MTF/DDFを開発し、適用事例で確認実製品開発にも適用し、効果を確認 ==== 今後 ==== 提供すべき機能の拡充上流の分析/設計手法の明確化 ======== 質疑応答 ======== Q: MTF/DDFの公開は行なわれているか A: されている Q: 実時間制約の緩い部分だけオブジェクト指向を導入し、そうでない部分の実時間制約を保証しやすくするという方法があるが、今回のようにシステムの全てにオブジェクト指向を導入するようなフレームワークでどのように実時間性を保証していくのか A: 特にオブジェクト指向にとらわれる必要はないのでは。設計の段階で本手法を導入すべきなのかを十分検討してもらう。 Q: タスク分割のやり方として時間制約を元にやる方法もあるが、本方式上で　やる場合の制約は A: がんばってやって欲しいという以外にない ==================================== 擬似状態メッセージによるROOM法の拡張 ==================================== ==== 背景 ==== 組込みとオブジェクト指向一般の組込みの開発スタイル機能分割, タスク分割(イベントドリブン, 並行性, デッドライン, パフォーマンスなど) オブジェクト指向の場合ユースケース分析クラス抽出抽象化、複雑な処理を扱えるレベルまで落とす保守性、再利用性を重視 -> この食い違いは実装の枠組みの強化で回避できるスレッドとオブジェクトの粒度の違いオブジェクト毎にスレッドを割り当てられない -> パフォーマンス, 排他制御上の問題複数のオブジェクトを1つのスレッドに載せるフレームワークが使用される -> ROOM, EPOCなど Active object : 論理設計要素 Thread root : タイミング設計要素 #Threadにobjectを差し込んで利用する -> 両者の独立性が重要 ==== 目的 ==== アクティブオブジェクトをプラグインする機構の強化 - 擬似状態メッセージコンテキスト認識同期自動タスク分割の提案 (Future work) - 時間制約のみからタスク分割を行なう 4+1ビューアーキテクチャ図データフロー図 ========================== タスク境界とタイミング境界 ========================== リアルタイム対応データフロー図異なる時間制約を持つ部分にタイミング境界がある -> これまでは起動周期によって(タイミング境界によって)タスク分割　を行なうスレッド境界パイプライン型速度差を吸収するバッファなどにスレッド境界があるタイミング境界と状態メッセージ起動イベントの時間差による境界 (スレッド境界とは異なる) スレッドの実装イメージ起動タイミングの異なるアクティブオブジェクトを一つのスレッドにバインドするスレッドの起動タイミングは全体の和集合となる同期メッセージによるタイミング分離 ROOMでは同一スレッド内に制限されるが、スレッド境界も越えてみたい非同期通信スレッドマッピングに関する規定はないキューイングベースではタイミング境界を越えられない擬似状態メッセージスレッド境界とタイミング境界スレッド境界はイベントメッセージでタイミング境界は状態メッセージで ====== まとめ ====== 擬似状態メッセージを導入することでスレッドマッピングの自由度を大きくしたコンテキスト依存セマフォの提案 ========== 今後の課題 ========== なぜ自由度を大きくしたのかオブジェクト : オブジェクト指向分析スレッド : 時間制約, RMA <- ここを自動化したい Virtual Taskの考え方複数に分割されたタスクがまるで単一であるように振舞うタイミング境界があってもVisual taskの考え方を生かしたい今後の方針スレッドプライオリティベースで自動タスク分割を実現できないか chg_priしなくていい既存の資産と共存しやすい ======== 質疑応答 ======== Q: データフローダイアグラムを使ってスレッド分割をした場合、データは何に　なるのか A: ここの変数やクラスなどに割り当てられるコメント : 時間制約を満たすだけの方法論を一辺倒に使って欲しくない Q: RMAがタスクにかけている制約条件はどうなっているのか A: 体系的にはわからないが経験的にどうにかなると思う Q: 解析結果の数値の評価はどうなっているのか A: デッドライン >= Responseであるなら大丈夫