IoT活用システムへのゴール指向要求分析の適用に関する考察
•Download as PPTX, PDF•
0 likes•598 views
2017年7月19日、SS,KBSE,IPSJ-SE合同の研究会で発表してきた内容のプレゼン資料と付録の資料、Ｑ＆Ａのメモです。
Recommended
More Related Content
Similar to IoT活用システムへのゴール指向要求分析の適用に関する考察
Similar to IoT活用システムへのゴール指向要求分析の適用に関する考察 (20)
More from Michitaro Okano
More from Michitaro Okano (20)
IoT活用システムへのゴール指向要求分析の適用に関する考察
- 2. はじめに：背景 • 研究課題 – 設計・実装等で必要な情報を要求分析で抽出する手法 • 要求以外にも必要な情報がある：制約など • IoT： – 多数のセンサーからのデータを収集し，予測・制御を行う • 多様なデバイスへの対応（多様性） • 実装しないと判明しない不確かな部分（不確かさ） • パターン化された再利用可能な部分もある – 無線を採用する際の考慮点など／ただし技術の陳腐化も激しい • 本稿の内容 – IoTの特徴・課題を挙げた上で – 設計・実装等で必要な情報を抽出する要求分析手法を考察 • ゴール指向要求分析（ＫＡＯＳ）やＧＳＮの活用 2
- 3. Agenda • ＩｏＴの特徴と課題 • ＩｏＴについて – 要求分析の視点からの位置づけ – 接続方式の視点から見た範囲 • 課題に対する提案 – アプローチ – 提案手法 – 事例 • 考察 3
- 4. ＩｏＴの特徴と課題 • ＩｏＴの特徴を示すため、２システムを比較 – IoT:センサーデータを取得し、快適な温度に制御 – 業務：受注入力 • ＩｏＴ – (1)入力の多様性と不確かさがある – (2)上記(1)に関する知識は再利用可能な部分もある • 陳腐化し、再利用できない部分もある 業務 ＩｏＴ 入力デバイス キーボード（＋ＲＦＩＤ等） ＋マウス名等限定 多様なセンサーと入力値 新たなセンサーも開発 入力値 正 確 な こ と が 前 提 （ エ ラーチェック） 誤差を含む。通信の場合、 届かないこともあり不確か 4
- 5. ＩｏＴについて： 要求分析の視点からの位置づけ • 企業の全体目標から見たＩｏＴの位置づけ – 全体課題 ↓ – コンピューターを利用した解決（/人による解決） ↓ – 人とコンピューターによる業務 ↓ – コンピューター処理／人 ↓ – 入力→処理→出力 （蓄積／フロー／連携） デジタルトランスフォーメーション／ モダナイゼーション キーボード等 →＋センサー 画面・プリンタ →＋ＶＲ・ＡＲ／３Ｄ ＲＤＢ→＋ＮｏＳＱＬ／ 分散トランザクション ※ＡＩは入力・処理・出力すべてに関連 通信 →＋ＩｏＴ →＋ＡＰＩ 5
- 6. ＩｏＴについて： 接続方式の視点から見た範囲 • IoT： – ”インターネットに多様 かつ多数の物が接続さ れ，及びそれらの物か ら送信され，又はそれら の物に送信される大量 の情報が円滑に流通す ること”[1] • 本稿では – 物と物の間をインター ネットだけで結ぶ場合 – インターネットの部分が ある（他の通信部分の 存在可） [1]特定通信・放送開発事業実施円滑化法,http://law.e-gov.go.jp/htmldata/H02/H02HO035.html 6 本稿では入力だけを取り上げ、 モーター等の出力は取り扱わない
- 7. ＩｏＴについて： システム要素：接続方式の視点から • クラウドへの接続 方式毎の機器 – 方式Ａ（すべてイ ンターネット） • エッジ • 通信 – 方式Ｂ（一部他プ ロトコル） • エッジ • ＧＷ • 通信 • 各機器で多様・不 確かさが存在 各種通信 プロトコル ＊インターネットと他通信プロトコルをつなぐには プロトコル変換機能を担うＧＷが必要 7
- 8. ＩｏＴについて：多様性 発生個所 多様性 選択に必要な情報 センサー 使用するセンサーの種 類 求められるセンサー出力値の 型（アナログ，２値等）・範囲・精 度，設置場所，設置個数 エッジ（ＧＷ含む） マイコン・通信モジュー ル・ＧＷの利用・未利用 設置場所，設置個数(センサー 出力値の型，通信形態，通信 プロトコル→他発生個所) 通信 形態 有線を利用するか，無 線を利用するか 有線が敷設可能か，無線通信 可能か，通信設備の設置場所 プロトコル インターネットか，その ほかの通信規約（多数 ある）か 伝送距離，伝送量，伝送頻度・ 間隔，伝送速度・通信帯域，通 信設備の設置場所 ※通信設備の設置場所:屋外・屋内・金属で密閉された場所か，温度・湿度・振動・ホコリ の有無，障害物や電気的雑音等の外乱の有無，設置する空間の広さ，電源が取得可能か否 か，保守（取り替え等）可能か等 ※※システム構成全体に影響を及ぼす情報として，費用と開発期間がある 8
- 9. ＩｏＴについて：不確かさ 発生個所 不確かさ 許容範囲を知るのに必 要な情報 センサー 誤差に伴う値の不確かさ →センサーの精度に起因 許容されるセンサーの精 度 エッジ（ＧＷ含む） データ伝送の不確かさ →ハードウェアに起因（故障） ハードウェア条件※ 通信 形態 データ伝送の不確かさ →通信に起因（通信エラー） 通信頻度・データ量・伝 送速度・通信帯域・許容 エラー率と再送必要性・ 通 信 設 備 の 設 置 場 所 ※※ プロトコル ※ ハードウェア条件：ハードウェアが置かれている設置場所の情報と， 許容される経年劣化，故障頻度，想定される監視・保守の頻度等 ※※「通信設備の設置場所」は前シートで説明済み 【本稿の目標】 ＩｏＴの多様性と不確かさを考慮するために「必要な情報」を明示 設計・実装を行う上で、再利用可能な情報を明示する方法の提案9
- 10. 課題に対する提案：アプローチ • 文について • 要求分析→要求仕様書の 文・図になる • 【関連研究】文について – Lamsweerde[1]の分類 • 設計は、以下を考慮する – ドメイン知識：法則・法律 • 例：2.5GHzは直進／サブギガは 回析 – システム固有知識 • 電源が取れない – 変更・陳腐化しやすい知識 • ＷｉＦｉの機種と価格等 – 要求 • センサーデータを取得する 顧客・ユーザー：要求を提示／ドメイン知識なし システム固有知識は何が必要か不明 設計者：ドメイン知識あり システム固有知識を示せば設計可能 ↓ 要求分析者：ユーザーから要求を聞き、 必要なシステム固有知識をユーザーから抽出 10 [1] Axel van Lamsweerde, “Requirements Engineering: From System Goals to UML Models to Software Specifications”,Wiley,2009
- 11. 課題に対する提案：アプローチ • ＫＡＯＳ ゴールを詳細化することにより、要求を抽出 ※ＫＡＯＳだけでは必要なシステム 固有知識は表現できない • ゴールを詳細化して 要求を抽出 • ゴール（Ｐ→Ｑと表現 したとき）の詳細化 – マイルストーン分割 • Ｐ→Ｍ、Ｍ→Ｑ – 要素分割 • Ｐ→Ｑ１，Ｐ→Ｑ２、 ｛Ｑ１，Ｑ２｝→Ｑ 11
- 12. 課題に対する提案：アプローチ • ＧＳＮ • ＧＳＮとは – 保証のための構造化さ れた議論の記述法 – 保証したいこと：ゴール • ゴールをサブゴールに分 解していく． – 分解する観点：戦略 – 議論時の条件等：前提 – 末端のゴール：エビデン スにより成立を保証 ＊必要な情報を「前提」に記述、エビデンスに値 温度の センサー の例 12
- 13. 提案手法 1. 前提 (1-1)従来行っている要求分析は行われている (1-2)設計のためのガイドラインを「接続形態の各観点」毎に作成済 2. トップゴールを「IoTシステムの入力値に関する情報が収集 されている」とする 3. 要求分析するシステムにおける入力に基づいて，入力ごと に要素分解する． 4. 上述３の各入力に対して，「接続形態の各観点」に基づき 要素分解する． 5. 上述４の「接続形態の各観点」に対して，「設計のためのガ イドライン」の「必要な情報」ごとに要素分解 6. 上述５「必要な情報」のゴールに対する具体的な値をエビ デンスに記述 13 【設計ガイドライン】 何を考慮して設計を 行うかを分析し、一般 化して記述したもの →再利用可能
- 15. 事例： 「接続形態の各観点」まで • ＧＳＮ １．トップゴールの 要素分解 ２．入力毎に要素 分解 ３．接続形態の各 観点毎に要素分解 ※紙面の関係上、「温度」「センサー」のみ分解 15
- 17. 考察 • 評価 – 設計等で必要な情報 • ＧＳＮのエビデンスに明記 – 再利用可能な情報 • 設計のためのガイドライン→「必要な情報」をここから抽出 • 今後の研究 – 設計ガイドラインの妥当性 • 自分が設計したときの経験をもとに書いている • 開発してみないと確認できない • 対象や時代によって変わる可能性がある – 例：電波法→各国によって異なる – 「接続形態の各観点」以外での分解方法 ポイント 要求分析で、要求のほかに 制約の抽出も必要→あらかじ め設計方法を分析して、設計 上「必要になる情報」を抽出 17
- 18. まとめ • 目標：以下の情報を明示する 1. ＩｏＴの多様性と不確かさを考慮するために「必要な情報」 2. 設計・実装を行う上で再利用可能な情報 • 提案手法 – 【関連研究】文の種類から • 要求分析で抽出すべき情報は「要求」と「システム固有情報」 – 要求は従来の方法で取得： • ＫＡＯＳを利用し、必要な入力までを分析 – 必要な情報は、ＧＳＮで表現 • あらかじめ（再利用可能な）設計方法を分析（設計ガイドライン）し、 「必要となる情報」を確認 • 必要となる情報がＧＳＮのエビデンスに書き出される • 評価 – （１）必要な情報は、エビデンスに書き出される – （２）再利用可能な情報は設計ガイドラインに記述 18 設計・実装 等に必要と なる情報 【ポイント】 設計者を分析 することで、必 要なシステム固 有情報が判明
- 21. センサー決定に関して－１ • センサー – 測定したいモノを電気的な量（電圧・抵抗・電流）に変換 • 抵抗値が変わる場合、電源がないと、電気を流して測定でき ないので注意 • 測定したいモノが測れるセンサーがないと、開発できないので 注意（センサーの種類が書ける程度の情報必要） – 値は、２値の場合、アナログの場合あり • ここでは、２値かアナログかを「型」と呼ぶことにする • アナログの場合、取得できる値には範囲がある • センサーの精度により、価格が違うので注意！ – センサーから常に値が送られてくるものと、何かのアク ション（問い合わせ）を取り、値を取得する場合がある 21
- 22. センサー決定に関して－２ • センサー設置場所：注意が必要 – 屋内／屋外（屋外の場合、防水が必要） • 湿度、温度、ホコリにも注意 – 電源が必要な場合、電源の確保 • エナジーハーベスティングを行うとき、電気が生成する か確認（例：太陽光発電→夜間に送信？） – 幅、設置する高さ（設置可能・取り外し可能？） • 特に高さは、電池交換する場合に注意 – 電気的、磁気的にノイズが発生するか • 逆に遮蔽されて電気・磁気が外に漏れない場所か？ 22
- 23. センサー決定に関して－３ • センサー設置台数と範囲(距離)：注意が必要 – 設置台数によっては、費用や電源の問題が出る – センサーからのアナログ電気信号が届く範囲に は限界がある（１ｍ以内で考えたほうがよい）。そ の範囲内にエッジ（マイコンまたはＧＷ、通信モ ジュール等）を置く – センサー間の距離によっては、結果が影響する （２つのセンサーが反応する）ので注意 • 測量等で、わざとそうすることもある 23
- 25. エッジ処理に関してー１ • エッジ – センサーの信号は微弱で通信プロトコルもインター ネットではないので、クラウドにセンサーデータを送る ために用いられる – エッジの構成は、マイコンを使うor使わない／ゲート ウェイを使うor使わない／マイコン～“ＧＷないしはク ラウド間”の通信モジュールを使うor使わないの組み 合わせがある • これらの組み合わせはセンサーデータの型や通信形態・通 信プロトコルで決定する。詳細は後述 • センサーにエッジ処理部分がついているものもある（例：I2C の温度計、スマートフォン） 25
- 26. エッジ処理に関してー２ • エッジの構成に関して – センサーが通信装置を内蔵・接続（スマートフォンや Raspberry Piのインターネット・WiFi等）していない場合 は、通信モジュールが必要（＝以下これらをまとめて 通信機器と記述） – 通信プロトコルと距離に応じて（プロトコルが変わる 場合）ＧＷ，（プロトコルが同じ場合）中継器が必要 – 通信機器に直接センサーがつけられる場合もある – そうでない場合は、マイコンが必要になる • センサー→マイコン→通信機器の構成になる 26
- 27. エッジ処理に関してー３ • エッジ間の接続に関して – センサー→マイコン間は、 • ２値の場合、センサーの線をマイコンのＧＰＩＯに • アナログ値の場合は、アナログポートに接続する • どちらも、プルアップ／プルダウン抵抗が必要な場合がある（抵 抗値は慣習で決める。厳密でなくてよい） – マイコン・通信機器間は • 通信プロトコルによる • ＵＡＲＴ、Ｉ２Ｃ、ＳＰＩ等のシリアル通信が考えられる – メーカーにより名称が異なる（ＵＡＲＴと言わない）ので注意 • 端子間で電圧が異なるとき、変換が必要 – 高い→低い（５Ｖ→３．３Ｖ）：抵抗分圧 – 低い→高い（３．３Ｖ→５Ｖ）：オープンドレインを使う（プルアップする） 27
- 28. エッジ処理に関してー４ • エッジ処理での注意事項（１） – 無線の場合、無線モジュールが技適を取得済みかど うかを確認すること • 取得していなければ、免許不要の周波数・変調・プロトコル でも免許なしで使えない – ハードディスクを使用する場合 • 振動が起こる場所でないか、チリ・ホコリはどうかを確認す ること – ＳＳＤを使用する場合 • 書き込みが多いと壊れる（Raspberry PIでswapを使っている 場合等）。その場合、取り替え可能な場所か、保守は可能 か確認する 28
- 29. エッジ処理に関してー５ • 電源が取れるか確認すること – １００Ｖ ＡＣ電源が取れる場合 • ＡＣアダプタを利用する • PoCの場合、安定化電源でも可 • 電源回路を設計する – １２Ｖまたは２４Ｖ ＤＣ電源が取れる（例：車） • 12(24)Vから5(3.3等)Vに変換する必要がある – 乾電池・バッテリーを利用する場合 • 交換可能かどうか・保守はどうするか確認する – 電源が取れない • エナジーハーベスティングを検討する（太陽光・振動等） • ＵＳＢで送れないか？ 29
- 30. エッジ処理に関してー６ • エッジ構成全体に関して – センサー・マイコン・通信モジュール間の距離は 適当か確認する（距離が長いと電圧降下する） – 温度・湿度・水分・チリ・ホコリ、電気的・磁気的な 影響について確認する • 場合によりケース（金属・プラスチック）が必要になる – 幅、高さ、交換可能か、保守可能かの確認をする • 経年劣化するセンサーの場合、交換が必要になる • 電池の場合は、交換必要 30
- 32. 通信形態に関して－１ • 通信形態について – 本ガイドラインでは、有線・無線のことを指すもの とする – 無線は切れることがあることを想定して設計する • 有線のほうが、確実性がある – 無線で高い周波数帯を利用する場合、電波が回 折しなかったり、水に吸収される場合がある • 無線はとくに現場での確認が重要 – 有線の通信敷設、電源工事は高価になることも 32
- 33. 通信形態に関して－２ • まず「有線が敷設可能か」確認する – エッジ→ＧＷ・中継器→社内ルーターまで通信線が引ける か確認する • その際、電源も引けるか確認する • 線が切れたらどうするか・どうなるか（どこまで影響するか）確認 する – 通信プロトコルによっては、ネットワークの形状に制限が ある（ＲＳ－４８５等）場合があるので注意 • 自分が使おうとするプロトコルで許される形状で、敷設が可能か 確認する – 中継器・ＧＷを使う場合、それらの設置場所にも注意する （固定する必要性の有無、場所は確保可能？） – 敷設は可能だが、（ケーブル等の）費用が膨大になり事実 的に無理というケースもあり得るので注意 33
- 34. 通信形態に関して－３ • 無線通信が可能か確認する – 完全に金属でおおわれると通信できないが、一部お おわれていない部分があると、通信可能なこともある （ただし、送信電力を多く使う可能性あり） – 公共の通信設備（気象レーダー等）がある場合、通 信が（一時的含む）できない可能性あり – 医療機器やペースメーカーを入れている人、精密機 器がある場合などは無線に適さない箇所がある場合 がある – 同じ周波数帯で利用者が多い場合、混信したり、競 合したりして、事実上通信にならないことがある 34
- 35. 通信形態に関して－４ • 通信設備の設置場所を確認すること – 屋外・屋内：屋内の場合、上（天井）・下（床） – 金属で密閉された場所か：無線の場合問題 • 温度・湿度・振動・ホコリの有無により、ケースの有無を考 える。金属ケースを使う場合、密閉される – 障害物や電気的雑音等の外乱の有無 • 障害物は、無線の高周波数帯で問題、外乱は有線・無線を 問わず問題 – 設置する空間の広さ：広いと有線の場合コスト高 – 電源が取得可能か否か：電源が確保できない場合は、 無線の送信出力を小さくするか、寝かせる – 保守（取り替え等）可能か：電池の利用 35
- 37. 通信プロトコルに関して－１ • 有線は、どのようなプロトコルでも理論上可能だ が、インターネット（ないしはEthernet）またはシリ アル(RS-485,RS-232C）の利用が多い – ＲＳ-４８５の場合、メッセージの構成等は異なる – インターネットはＨＴＴＰ／ＲＥＳＴ ＡＰＩ（結果をＪＳＯＮ で受け渡し）が開発しやすい • 無線はプロトコル、周波数帯は、法律その他の 規約で決まっている部分がある – 伝送したい内容をもとにプロトコルを選ぶ – 免許不要の場合、技適の取得が必要になる – 免許は、製品に対してだけでなく、開発中も必要 • でないと、電波暗室で開発することになる 37
- 38. 通信プロトコルに関して－２ • 初めに必要な帯域と通信距離を確認する – 必要な帯域は、１回あたりの通信量と通信頻度（間隔）を もとに計算できる • そうすると、無線の場合は「利用できない」通信プロト コルが見えてくる – 無線の各周波数帯の特徴は次シート以降に記述 • 許容される転送エラー率、再送の必要性を確認してお くこと – これがシビアな場合、無線よりも有線に向く • 費用的には、優先のほうが安い • 低電力はEnOceanのほか、Deep sleepを検討する 38
- 39. 通信プロトコルに関して－３ • 無線の各周波数帯の特徴から通信プロトコルと 通信速度（選択可能時は周波数帯）決定 – サブギガ帯(920MHz)のＬＰＷＡは、ある程度遠くまで 飛ばせるが、通信量は限られる。またＡＲＩＢの送信 規制がある。 • むしろ、飛びすぎによる混信に注意 – ２．５ＧＨｚ帯のＺｉｇＢｅｅ、ＢＬＥは少ない通信量で多く の端末がある場合、向いている。しかし周波数帯が 高いので、距離や障害物（回折しにくい）に注意する • 現場での確認が必要な場合も • ＢＬＥとbluetoothは接続できる端末数等で大いに異なる 39
- 40. 通信プロトコルに関して－４ • 無線の各周波数帯の特徴（つづき） – 2.5GHz帯のＷｉＦｉは多くの転送が行えるが、以下の点 に注意する • 確保できるチャンネル数＊通信帯域／同時接続数で１人 当たりの帯域がわかる。動画だと、帯域が足りないことがあ る。この場合５ＧＨｚ帯のWiFi利用を考える – ５ＧＨｚ帯ＷｉＦｉは以下の規制がある • 屋外で使用できない周波数帯がある • 気象レーダーなどと干渉した場合、送れない。そのため、 チャンネルを固定してしまうと、停波してしまうことになる – 2.5,5GHz同時につかうこともある – WiFiモジュールを利用する場合、コストを確認重要 40
- 41. 通信プロトコルに関して－５ • 無線の各周波数帯の特徴（つづき） – ３Ｇ、ＬＴＥ • 遠くまで飛ばせる、帯域も広いという点ではよいが、パケッ ト代がかかる（ランニングコストがかかる） • たしかに帯域は広いが、動画を送ると、思ったほど転送で きないこともあり得るので、転送できるか確認が大事 • 通信エリア外の山奥に送る場合、人工衛星を利用するとい う手も実証実験レベルではある模様 – EnOcean • エナジーハーベスティング、ローパワーでの動作のときに考 慮する（とはいえ、限界があるので注意） 41
- 42. 通信プロトコルに関して－６ • 無線で問題ある場合、有線の利用を考える • 有線はシリアルの場合とEthernetの場合あり – 通信モジュールのコストが違う（シリアル安い） • シリアル系 – ＲＳ－２３２Ｃ：１対１の通信で主に使う – ＲＳ－４８５：１対多も可能。遠距離も可能 • Ethernet – 一般的には、インターネットだが、自動車の場合は EtherCATなどもある • その他 – 自動車のＣＡＮ等 42
- 44. システム構成全般に関して－１ • 全体費用・開発期間をまずは確認する – 費用によって、システム構成は変わる • 構成要素が多い場合、１つの構成要素（センサー等） にかけられる金額がシビアになる – 開発期間が短い場合、人を投入しても、工数を増 やすには限度がある（現地調整が必要な個所は それなりに時間がかかるため） • この場合、開発するスコープを狭くする • PoCを作ることで、リスクを減らすことができる – 予算との見合い 44
- 46. Ｑ＆Ａ 付録２ 46