Recommended
More Related Content
Similar to 中小規模のIoT
Similar to 中小規模のIoT (14)
More from Michitaro Okano
More from Michitaro Okano (18)
中小規模のIoT
- 2. ゴールとアブストラクト • ゴール：以下の雰囲気を感じられる – 大がかりなＩｏＴが騒がれているが、現実には、中小 規模のＩｏＴが取り組みやすい（特にアミューズメント） – 中小規模のＩｏＴは、夏休みの自由研究や部活動には 向いている。しかしプログラミング教育としてＩｏＴを授 業で行うと・・・ • アブストラクト：自己紹介の後 – 中小規模のＩｏＴとは – イマドキのＩｏＴシステムの全体像 – ＩｏＴの授業は可能？ 2
- 3. 自己紹介 • 筑波大学大学院ビジネス科学研究科 – 社会人大学院：仕事を持っているということ • 某ソフトハウスで研究開発（非正社員） – 困ってしまった案件をどうにかするのが担当 • ２点と半径を入力とし、円弧を描くためのＸＹ座標を出 力するプログラム • ある条件下におけるトーナメントの組み合わせ ： （以下省略） – そして、今・・・ＩｏＴ 3
- 5. 一般的なＩｏＴ • モノのインターネット – センサーをインターネットにつないで – センサー情報をクラウドでビッグデータ解析をして – 予測(BigData解析）・機械制御等を行う • 例えば・・・ – ビル管理システム(BEMS)、スマートハウス(HEMS) – ヘルスケア：ウェアラブル – 工場での制御、連携(Industry4.0)、農業IoT • 大規模なものが多い→お金儲かる? 5
- 6. 中小規模のＩｏＴ • もっと小規模（１部屋程度）の方が実現性大 • 例えば・・・（以下、他社の事例を含む） – トイレが開いているか（ドアにセンサ＋無線） – 交通量調査：ドップラーセンサー – 心拍数の計測 – 電気使用量表示（エネルギー消費の見える化） • 特に電子工作・アミューズメントと組み合わせ – Perfumeの紅白：ライゾマティックス – 暗くなったらＬＥＤ点灯（イルミネーション） – たたいたら光る（楽器） – 電子百葉箱：ＩＦＴＴＴを使って気温・湿度をつぶやき • 夏休みの自由研究でも扱える？実は難しい 6
- 7. 余談：ＩＦＴＴＴ（いふと）とは • Twitter,FaceBookなどのサービスを、簡単に使えるようにし てくれる • Makerというサービスがあり、ここにデータをHTTP形式で送 ると、Twitterでつぶやいたり、Gmailで何かをメールしたり できる • ということは、Raspberry Piからセンサーデータをmakerへ HTTP経由でデータを送れば、データ内容に応じてTwitter でつぶやける ＩＦＴＴＴのサイト https://ifttt.com/ 使い方：http://hoomey.net/ifttt_study_1/ 7
- 8. ＩｏＴのイメージ • 何が難しい→そもそもＩｏＴのイメージって… – インターネットでクラウドに持っていくんでしょ！ – 時代はRaspberry Pi＋ＷｉＦｉだよね！ 8
- 9. 現実のＩｏＴ • このシステム構成はあまりない。 – 一般的には問題がある – Raspberry Piは人気は有るが、実はArduino,mbedの方 がアナログ端子有り、GPIOピン電圧が５Vで扱い易い 9
- 11. システムの全体像 • センサーデータを安価なマイコン(PIC等)で収集 – マイコンにArduinoを利用可能（高価になるけど・・） – 遠距離に飛ばす場合は、通信モジュールを使う • マイコンからゲートウェイ（GW)でデータ収集 – GWにはRaspberry Piや、市販のものを使う – 有線または無線（ZigBee,BLE,サブギガ帯） • ＧＷからクラウド（サーバー）へ – インターネット・Ｇ３／ＬＴＥ回線 • サーバーデータを基に表示する ※πduinoは、センサー～GW(又はサーバー）まで包括したものなので、 機能的問題は解決しているが、費用と電源の問題は残る 機械制御の場 合はマイコン以 外にPLC等も 照度セ ンサー の例 [1] 11[1] http://ameblo.jp/smeokano/entry-12240624461.html
- 12. システムの現実１：センサー部 • センサーデータを取得して、ゲートウェイに – センサーデータを取得（アナログ・デジタルデータ） • ゲートウェイから指示がある場合と自主的に計測するケース – マイコンで、通信データを作成する • 近距離間通信：Ｉ２Ｃ、ＳＰＩ、ＵＡＲＴ – 遠距離に飛ばす場合、通信モジュール • 無線：WiFi，BLE，ZigBee，サブギガ帯用（様々） • 有線：インターネット、ＲＳ－４８５ – ゲートウェイはセンサーデータを受信してサーバーへ • 無線：３Ｇ・ＬＴＥ、有線：インターネット • センサーが少ない場合、GWは省かれることもある 12
- 13. システムの現実２：サーバー部 • ゲートウェイからデータを取得し、保存する – ゲートウェイにデータ取得を指示するか、または○ゲートウェイから（一定時 間毎に計測）、データが送られてくる – 受け取ったデータをサーバーは保存する – 表示部へデータを送りつけるか、または○表示部からの要請に応じて、デー タを返送する • ○を付けた方法の方が、作りやすい – HTTPサーバーを使ってサーバー部分を開発できるため • 世間は、ここは「クラウド」押し – そしてビッグデータを使い、 – 機械学習など言っているが・・・ • 中小規模であれば、単にサーバーを置けば十分 13
- 14. システムの現実３：表示部分 • データを「見える化」する – サーバーからデータが送られてきたら、または○一定時間ごと にサーバーからデータを取得 – 取得したデータをグラフ表示等する • JavascriptとＡＪＡＸにより、動的に画面を作成できるように なった – ＨＴＭＬが基本 • 近年、開発が容易になった – REST APIというデータ交換手法 – JSONというデータ表現方法 14
- 16. 開発の進め方 • ＰＯＣの後に試作、量産化設計、製造と続く – ※POC:Proof of Concept 主要要素技術の確認等 • ＰＯＣの進め方としての一方法（あくまでも一例） – 利用場面のストーリー（ユースケース）を作成 – ストーリー中、人やモノの結びつきをチェック – 結びつき＝通信の手順を決定 – 役割を決めて、ＰＯＣを実装する • ＰＯＣまでは、プログラミング思考の前にシステム＆デザイ ン思考のほうが大事？ – システム（要求をまとめる）思考→要求仕様作成に必要 – デザイン（発想を広げる）思考→企画を広げるのに必要 • プログラミングよりデザイン思考のほうが盛り上がる 16
- 17. 利用場面のストーリーを作る • エンドユーザー（利用者）の使う場面（ユース ケース）をシナリオとしてまとめる – 最終的に、いくつかのユースケース図（コンテキスト ダイアグラム）ができ、時系列に並べられる：理論上 • 一般的にはヒアリングで情報収集する – ただし、利用者に直接聞かず、結局は発注者に将来 像を聞くことになるので、ヌケは当然。矛盾も • インターンでは（多分授業でも）、ブレインストーミ ングでまとめていったほうが盛り上がる – カスタマージャーニーマップ 17
- 18. 人やモノの結びつきをチェック • 結びつき：主にデータの関連 – ユースケースの入出力に対して、具体的な「入出力 データ」を決める – 出力データに着目：その出力データを作成するには、 どんな入力データが必要で、「何をすべき」か考える • 「入出力データ」はＥＲ図で表現できる – ・・・が図に、こだわらなくても・・・ • 「何をすべき」から業務流れ図、アクティビティ図 が作れる。もちろんＤＦＤも作れる 18
- 19. 通信の手順を決定 • どのような順番でデータをやり取りするか – 登場するシステム・人物を挙げる • ＩｏＴの場合、センサー・ゲートウェイ・サーバー・表示 （ユーザー） – 業務プロセスごとに、入力から出力までデータが システム・人物の間をどのように流れるか決める • 通信手順（プロトコル）が決まる • ここで、シーケンス図が作成できる – シーケンス図より、送受信データフォーマットのほ うが重要ですが・・・ 19
- 20. それぞれの役割を決めて実装 • 通信手順が決まると、各システムの入出力が決まる ので、その入出力が行えるように、プログラムを実装 する – マイコン（ＰＩＣ等）はＣが多い • ArduinoはＣに似た言語 – ゲートウェイはＣ、またはＰｙｔｈｏｎ • 例はRaspberryPi上でCで記述（ｇｃｃでコンパイル） – サーバーはＪａｖａ、Ｐｙｔｈｏｎ、node.js・・・ • 例はJavaでフレームワークにSpringBootを利用（REST API) – 表示はＨＴＭＬ＋ＣＳＳ＋Ｊａｖａｓｃｒｉｐｔ • 例はHTML+Javascript(JQueryを使用） • 現状では色々な言語を使って実装している – 様々なフレームワーク、様々な開発環境を使う 20
- 22. 実装の現実から推測するＩｏＴの授業 • うまくいくはずが・・・実際にはうまくいかないこと 続出になるのでは？ – Arduinoに書き込めません・・・ – 通信がつながりません・・・ – どこがおかしいんだか、良くわかりません • 部品点数が増えるほど、トラブルも増える • トラブルを避け、時間内に終わらそうとすると・・・ – サンプルを用意することになる • コピペして、変数を変えて・・・ 体験は可能 学習は？ 大規模は難しい 中小規模○ 22
- 23. 余談：ググってコピペはプログラミング？ • 動けば・・・「問題ない。大丈夫だ」 • 動かなかったら、どうなる？ – 実はリスキーなプログラミング方法 – そのリスクに気づかず、後で代償を払う • リスキー、でも避けられない – 自動化の流れと同じく、避けられない • 機械化（作業の効率化） • →自動化（業務の効率化） • →AI（思考の効率化） – 定型のものは自動化できる • 設計以降では自動化が進展といわれている • ＩＦＴＴＴも、プログラムを書かない 体験による感情の部 分は残る→カスタマー ジャーニーマップ 23
- 24. まとめ まとめ • 大がかりなＩｏＴが騒がれてい るが、現実には、中小規模のＩ ｏＴが取り組みやすい • 中小規模のＩｏＴは、夏休みの 自由研究等には向いている。 • しかしプログラミング教育とし てＩｏＴを授業で行うと、失敗す る可能性も高く（50分程度で はリカバリーも効かない）、「コ ンピューターはやっぱり難し い」という印象を与えてしまう のではないかと懸念する どうして、こんなことになるのか • ＩｏＴとエンタープライズの違い • コンピューター教育は抽象化 が中心だった？ • ＩｏＴは抽象から現実への流れ もある：現実の環境は動く 現場の大人はこれを伝えられ るが学生に接する機会ない 現実のゴールが分 からない 24
- 25. 付録：「ＦＰＧＡ」について • 発表中にＦＰＧＡというものが出てきました。 • これは、「後からでも回路の書き換えが可能なロジッ ク・デバイス」[1]です – 例えばゲーム機等に入っているＩＣは、ゲーム用にロジッ クが組まれ、ハード的に焼きこまれているものが多いと思 います。これをＡＳＩＣといいます – ＦＰＧＡは、言語（ＶＨＤＬやVerilog）でロジックを記述して、 後からハード的に焼きこむことができます。 • 私のブログでは以下で取り上げています – http://ameblo.jp/smeokano/theme4-10072237571.html – 順番が逆になっています。最後の記事から始まります – （ＦＰＧＡを購入するところから書いています） 25 [1]https://www.altera.co.jp/products/fpga/new-to-fpgas/beginner.html