IoTシステム技術検定 試験対策⑥

IoT技術テキスト -MCPC IoTシステム技術検定 対応

今回はIoTシステム技術検定の試験対策として「第7章 IoT情報セキュリティ」を中心にまとめます


SHODAN:
モノのインターネット(IoT)デバイスを探す検索エンジン。企業のネットワーク管理者はこれらを利用して外部から脆弱性がないかどうか確認を出来る。

CENSYS:
SHODANと同じく、モノのインターネット(IoT)デバイスを探す検索エンジン。

耐タンパー性:
物理的にデバイスを盗まれたときに、内部のデータを解析困難にしていること。

セキュアブート:
デバイス電源投入時にデバイス内のソフトウェアが正規品であるかどうか検証してからソフト実行する仕組み。

WAF:
Web Application Firewallの略。WEBアプリにおいてHTTP通信等を解析して攻撃を検知・防御する。

CSMS:
組織の産業用オートメーション及び制御システム(IACS:Industrial Automation and Control System)を対象として、その構築から運用・保守に渡ってサイバー攻撃から守るためのセキュリティ対策を実施し、システムを運用するもの。

oneM2Mセキュリティ規格:
サービス層におけるIoTプラットフォーム標準化を推進する団体。セキュリティ機能は共通サービスエンティティ(CSE)の1つとして提供される。

IoTシステム技術検定 試験対策③

IoT技術テキスト -MCPC IoTシステム技術検定 対応

今回はIoTシステム技術検定の試験対策として「第3章 IoT通信方式」を中心にまとめます


高周波の電波のメリット:
・情報伝送容量が大きい
・アンテナが小さくなる

高周波の電波のデメリット:
・伝搬損失が大きい(周波数と距離2乗に比例)
・障害物を回り込みにくい
・ガラスなどの透過損失が大きい
・伝送距離が比較的短い

ISMバンド:
産業で容易に利用してもいい周波数帯。日本では2.4GHz(無線LAN、Bluetooth)や920MHzが広く利用されている。

スター型:
ゲートウェイは常に稼働している必要あり。ゲートウェイに複数センサが繋がるので、データが衝突しないように送信順番を制御する必要あり。中央集権なので信頼性の低いネットワークになる。

ツリー型:
階層構造によって多くのセンサをゲートウェイに接続可能。上位のノードにデータが集約されるため、一定のスペックが求められる。混信しないようにデータ送信純の制御や周波数帯域の使い分けが必要。

メッシュ型:
到達ルートが複数あるため信頼性の高いネットワークを構築可能。ただし通信が混線しないように周波数を使い分ける必要あり。ノードが常に受信待機のため稼働していないといけないので電力面にデメリットあり。

BLE
通信可能距離はBluetoothよりも短い。通信速度も低速。低消費電力に特化させた通信。

ZigBee:
周波数帯 2.4GHz
通信速度 250kbps
通信距離 100m
マルチホップが特徴。センサネットワーク形成に用いられる。

Wi-SUM:
周波数帯 920MHz
通信速度 1Mbps
通信距離 2km
マルチホップが特徴。屋外長距離通信に用いられる。

RFID:
無線通信機能を持ったタグ。電池内蔵で自らデータ送信するアクティブ型と、受信電波をエネルギー源として電波を返送するパッシブ型がある。

トランスファージット:
近距離無線転送技術。4.48GHzで560Mbpsという高スペック。KIOSKでの広告等コンテンツ配信に用いられる。

Z-Wave:
1GHz以下で無線LANなどと混線することなくフルメッシュネットワークを形成する。

EnOcean:
低消費電力性に注力した928.35MHzの通信技術。確認信号であるACKを使わないことで低電力化、その代わりに1回の送信でランダム間隔に3回データ送信する。

DustNetwork:
「きれない無線」を目指したメッシュネットワーク。時間をスロット分割して、割り当てられたタイムスロットで送信させることにより衝突が発生しない。

LAPI(low access priority indicator ):
携帯電話などと比較して、IoT機器はネットワーク接続の優先順位を下げる仕組み。

報知情報:
ネットワーク混雑時にIoTデバイスにアクセス不可な旨を報知情報として届ける仕組み。これによりIoTデバイスは接続要求すら出さないので回線制御信号までも控えることが出来る。

IoT最適な標準化:
無駄なスペックをひたすら省こうとする試み。NB-IoTと言われるように最小限の帯域しか割り当てず、最低限の通信速度しか持たせない。

IoTとプロトコル(HTTP):
暗号化やプロキシといったセキュリティ面で強いが、ヘッダ情報が大きいため無駄なデータ伝送が多くなる。

IoTとプロトコル(CoAP):
そんなHTTPの欠点を改良したものがCoAP。軽量版HTTPと思っておけばだいたいOK。

IoTとプロトコル(MQTT):
パブリッシャーとサブスクライバーという構成が特徴。トピックの一致をもってデータ送受信がなされる。HTTPなどよ比較してヘッダサイズが1/10以下。

IoTとプロトコル(WebSocket):
ベースはHTTPと似ているが、1度確立したセッションをそのまま維持し続ける点が特徴。TLSに対応しているためセキュリティにメリットがある。さらにリアルタイム性も強い。

プロトコルバインディング:
アプリ層やトランスポート層などでプロトコルが異なる場合に、その差を吸収する仕組み。

 




IoTシステム技術検定 試験対策②

IoT技術テキスト -MCPC IoTシステム技術検定 対応

今回はIoTシステム技術検定の試験対策として「第5章 IoTデータ活用技術」を中心にまとめます


Hadoop
大規模データの蓄積・分析を分散処理技術によって実現するフレームワーク

MapReduce
データを分類・仕分けするのがMap処理、仕分けされたデータごとに処理を施すのがReduce。

CEP
複合イベント処理。時系列に生み出されるデータを次々とリアルタイム処理する方式。

NoSQL(Key/Value型)
保存するデータをValueとして、ペアとなる一意のKeyを使ってValueの追加と呼出しを行う

NoSQL(ドキュメント)
JSON、XMLなどのフォーマットで記述されたデータを管理する。

NoSQL(グラフ)
データ間の関連性を管理可能。グラフ理論に基づくNoSQL。SNSなどの「ある人の友だちの友達」など互いの関連性を管理するときに利用されている。

Spark
Hadoopの後発として期待されるビッグデータ処理基盤。分散処理フレームワーク。

1人でもアンチがいたら周囲からの評価が下がる?

たまには専門外の論文を読んでみるのもいいなと思い、今回は『心理学研究』の論文を漁ってみました。

今思えば大学時代は一般教養科目で妙に人気だった心理学、いったいどんな論文が投稿されているのでしょうか・・・

今回は優秀論文賞を受賞したものから「表情の快・不快情報が選好判断に及ぼす影響」という論文を読みました。

https://www.jstage.jst.go.jp/article/jjpsy/advpub/0/advpub_87.15043/_article/-char/ja/


要約

内容①:対象物Xへの選好判断は、周囲の人物から対象物Xへのシグナルにより影響を受ける。

そりゃそうだって感じですね。みんなが好きなものは好きになってしまうのが日本人。行列があれば並びたくなるのが日本人ですからね。

内容②:他者が示すシグナルによる選好判断への影響を調査する。
内容③:無意味図形を好感度評価の対象として実験を行う。

無意味図形を使うというのは面白いですね。理由は好きや嫌いの事前情報が存在しにくいため。食べ物や芸能人だったら他人が示すシグナルに影響を受けようが「好きなものは好き!」となってしまいますから。

内容④:無意味図形を表示後に他者の表情を変化させて実験する。

むむむ、このあたりから怪しくなってきた・・・。つまり無意味図形の周辺に何人かの顔画像(無表情)が表示されて、図形表示後に喜んだり嫌悪感を示したりするということ。これで問題設定がきちんとモデル化できてるのか少々疑問です。

内容⑤:周囲が喜びを示すと、対象物に好感を抱く場合が多い。

なるほど、ここまでは直感と一致した結果ですね。

内容⑥:参加者のうち喜びを示す割合が多いほど好感を抱きやすい。
内容⑦:好感度の上がり具合には、喜びを示す絶対数ではなく割合が重要。

これは予想外。つまり50/100よりも6/10のほうが好感度の上がり具合が大きいということ。まぁたしかにファンが何人いるかということよりも、誰もが好きって方が説得力を感じなくもないですね。

内容⑧:嫌悪を示す人がいると好感度は下がる。
内容⑨:割合に関係なく1人でも嫌悪を示す人がいると好感度は下がる。
内容⑩:好感度の下がり具合は人数と関係なく、1人でも10人でも同程度下がる。

これですよこれ。つまり1人でもアンチがいればそれだけで好感度を下げうるということ。好感度を上げるのはあんなに大変だったのに。

これも直感通りと言えば直感通りかもしれません。火の無いところに煙は立たないというように、1人でもアンチがいれば「ひょっとして…」と思うのが人間の心理なのでしょう。Amazonレビューでもそうな気がします。


まとめ

おおむね直感通りでしたが、無意味図形を用いるなど実験環境の問題設定だったり、他要因の排除だったりに工夫を感じる研究でした。

Bluemix で LINE Bot するときに詰まったところ

UIの評判が高いLINE。クラウドと組み合わせることで様々なアプリが期待できます。

と、いうわけで、今回はベース部分を作ってみました。

AWSが人気ですが、今回はあえてBluemixでチャレンジします。理由はありません、私が天邪鬼なだけです。ちなみにいずれも無料枠の範囲内で作れます。

今回はベース部分だけを作るので、話しかけると定型文を返すだけのBotです。


開発用LINEアカウント取得

LINE Bot 制作前に、コチラの記事を参考にアカウントを取得してください。

 


つまったところ1

Access to this API denied due to the following reason: Your ip address [***.***.***.***] is not allowed to access this API. Please add your IP to the IP whitelist in the developer center.

対策:
LINEアカウント側でWhiteListの設定をしてください。

 


つまったところ2

“message”:”The request body has 1 error(s)”,
“details”:[{“message”:”May not be empty”,”property”:”messages”}]}”

対策
POSTするときのpayloadでMessagesを配列形式で定義してください


NodeRED用のソース。

クリップボードに以下を張り付けて、トークンだけご自身のアカウントのものに差し替えればOKです。

 

以上

未来志向は『So what?』、5W1Hでは思考が止まる

ビジネスを進めるときに5H1Wという思考を用いますが、これらは現在または過去に考えをはせるための思考法です。

未来を考えるには『So if ?(もし~ならば)』という思考が適切。

 

となると、酒を飲みながら無邪気に妄想したり、仮定の元で議論するというのは非常に良いのではないかと思った。

以前に『情報は光の速度でしか届かない。それが問題になるシーンは?』というタイトルで遊びの議論をしたことがある。こういうのが重要・・・なのかもしれな。

 

以上、簡易メモでした

電力事業とIT技術

最近、とある学会誌で電気事業とIT技術による将来像をまとめた記事を読んだ。面白かったのでメモしておく。


国内エネルギー消費量が減少する

消費エネルギー量
= 人口
× 1人あたりのGDP
× GDPあたりのエネルギー消費量

この3項のうち、人口が減少していくのは間違いない。2050年までには現在の70%程度まで人口減少するという予測もある。

そして、GDPあたりの消費量も省エネ技術の進歩によって減少の一途をたどる。これらを踏まえて、トータルで消費エネルギーは少なくなっていく。つまり「日本はそんなにエネルギーを使わない」という状況に徐々になっていく。


IT技術による電力システムの自由化と分散化

太陽光発電や蓄電池の技術普及によって、一般ユーザも電力利用をコントロールしやすくなった。ここから活躍するのがIT技術。

1つ目はデータ分析による最適化。本日の発電量、消費量、余剰電力を事前のデータ分析によって予想すれば、不足分だけ必要最低限に購入したり、余剰分を売買することが可能になり、『無駄な電力』がどんどんなくなる。

2つ目は市場形成。高セキュリティな電力売買取引の実現や、売り手と買い手の最適マッチングである。

これによって、それぞれのユーザが分散的に発電&蓄積して、電力を自由に売買するようになる。


おわりに

電力のやり取りが、まるで農村地域の「畑の野菜が沢山とれたからおすそわけ」といった感覚でやり取りされるようになれば、生活にかかる費用がグッと下がる。

田んぼや畑があれば食料には困らない。初期投資は重いけど、発電設備(太陽光パネルなど)と蓄電池があればエネルギーにも困らない。あとは家さえあれば、地域で助け合うことで暮らしていける、そんな時代に戻るかもしれない。

実写映画『ジョジョの奇妙な冒険 ダイヤモンドは砕けない 第一章』の感想(ネタバレなし)

実写映画『ジョジョの奇妙な冒険 ダイヤモンドは砕けない 第一章』を見てきました

https://warnerbros.co.jp/movie/jojo/index.html


というか今更ネタバレも何もないですけど、映画オリジナル展開も混ぜられてるのでそこは控えめにしつつ感想を綴ります。。。

ストーリー再現度:☆★★

仗助のじいちゃんがどんな人柄か、息子にどんな影響を与えたのか、それを引き継いだ仗助の姿、そのあたりが特に時間をかけて丁寧に描かれていました。

アンジェロや虹村兄弟との戦闘シーンはわりと原作通りで省略部分はあまりなし。省略が多かったのは主に戦闘以外の部分ですね。

「おまえは一枚のCDを聞き終わったら キチッとケースにしまってから次のCD を聞くだろう? 誰だってそーする おれもそーする.」これがちゃんと再現されたのは個人的に嬉しい。

キャラクター再現度:★★★

良かったのは山岸由花子と虹村形兆。ふつうに可愛いしカッコイいし違和感も少ない。

まぁ、冷静に考えれば億泰や仗助に比べて髪型が比較的普通なので再現しやすかっただけかもしれませんが。

逆にイマイチだったのは承太郎さん。ガタイと迫力が不足、そしてもう少し若くてもよくない?という違和感がわいてしまった。(俳優さんごめんなさい)

スタンド再現度:☆☆★

そりゃCGだから再限度は高いですよね。よくできてました。

クレイジーダイヤモンドvsバッドカンパニーの戦闘が、ゴジラVS自衛隊の怪獣映画みたいでした(※けなしてる)

映画オリジナル要素の量:☆☆★

時間の都合で変更点がちらほら。時間の都合で仕方ないよね。

初登場のヤンキーに絡まれるシーンで、亀のくだりがカットされていたのは個人的に残念でした。

映画オリジナル要素の良さ:☆★★

仗助のじいちゃんが町を守ってるという描写に、原作よりも重きを置いていていました。高校生の仗助がこれから戦っていく決意をする理由として必要な要素ということもあり、このあたりの描写は良かった。

学校で仗助がひたすら女の子に「ジョジョ先輩♪」って呼ばれてるのには笑ってしまいました。

 

結論: おもしろくないので別にみなくて良いと思います。

ブロックチェーンの処理速度の計算式

こんにちは、ロードローラーです。本日はブロックチェーンの弱点といわれている処理速度についてまとめました。





現在のブロックチェーン仕様では最大7tps(取引/秒)

まず、ブロックチェーンのキラーコンテンツであるビットコイン仕様では最大7tps(取引/秒)とされています。これはどのようにして計算されているのでしょうか?

ポイントは以下3点です
・ブロック承認時間
・最大ブロックサイズ
・トランザクションの平均サイズ

ブロック承認時間
採掘者たちによってブロックが生成されるまでの経過時間。

採掘と呼ばれるブロック生成作業は、Nonce値を総当たりで変更しながらハッシュ計算を繰り返して、条件を満たすハッシュ値を見つけ出すというマシン処理性能にモノを言わせた単純作業です。そのため条件設定によって難易度を調節できます(例:ハッシュ値の先頭にゼロがX桁並ぶなど)。こうしてブロック承認時間を設定します。

ブロック承認時間は長すぎると取引がいつまでも完了しません。かといって早すぎると同時に採掘完了するユーザが大量発生してしまい、ブロックの正当性確認や合意形成のプロセスに時間がかかり過ぎてしまいます。これらの背景からバランスが重要と言われています。

最大ブロックサイズ
1つのブロックに格納できる取引データ量。

ブロック承認時間が10分だった場合に、10分間に最大ブロックサイズを超える量の取引が発生すると、ブロックに格納しきれず後回しにされてなかなか完了できない取引が出てきます。実際にブロックサイズ問題はビットコインで顕在化しており、ブロックサイズを大きくするための議論が何度もされています。

トランザクションの平均サイズ
1取引あたりのデータ量。これは特に説明不要ですね。


というわけで、現在仕様と照らし合わせてこれらを基に計算すると
・ブロック承認時間:600秒
・最大ブロックサイズ:1MB
・トランザクションの平均サイズ:250Byte
 
1,024 × 1,024(バイト)/(250(バイト)× 600(秒))≒ 6.99(取引/秒)
 
ただしトランザクションの平均サイズが300Byteとも言われていて、計算しなおすと
 
1,024 × 1,024(バイト)/(300(バイト)× 600(秒))≒ 5.83(取引/秒)
 

…………遅っ!!!

※ちなみにVISAカードの性能は最大45,000tpsと言われていて、このことからもブロックチェーンが比較的に遅いのがよくわかります。

 

ブロックチェーンの活用案として、開発用にユーザ情報やセンサ情報を取引するといったことが提案されていますが、そのためにはプライベートブロックチェーンにして仕様変更しないと難しいのかもしれませんね。。。

※ここでいう仕様変更とは
(1)最大ブロックサイズを増やす
(2)トランザクションのサイズを削減する
(3)ブロック承認時間を短くする

過去のブロックチェーン記事

Kabylake+Z270搭載ボードでUbuntuを立ち上げるとイーサネットが繋がらない

こんにちはロードローラーです。タイトルに記載した通り、開発用にGPU搭載マシンを購入したのですが、OSインストールを終えた時点でネット接続できないという問題がありました。どうやらイーサネット(NIC)が認識されていない様子。

試行錯誤の末に解決しましたが、非常に疲れた。。。。同じトラップによる被害者を減らすべくここに記します。


Intel公式サイトからドライバ(Linux用)をインストール

ドライバ
https://downloadcenter.intel.com/ja/download/15817/-PCI-E-Linux-

インストールされていることは以下コマンドから確認できます

 

しかし、ドライバインストールしたにもかかわらず繋がらない。のコマンドで確認したところドライバは入っているのに、、、なぜ??


問題はサムチェック

アレコレと試行錯誤を繰り返した結果、サムチェックが問題と分かりました。

まずダウンロードしたファイルから「nvm.c」を開きます。

次にサムチェック関数(e1000e_validate_nvm_checksum_generic)が動作しないように中身を空にします。似たような名前の関数がたくさんあるので注意してください。

 

編集が完了したらファイルを閉じて以下コマンドを実行。

これでイーサネット認識して無事にネット接続できました。