AWSサポートとは？サポート範囲や問い合わせ方法について徹底解説
本コラムでは、AWSのサポートプランの概要や使い方、費用をかけずに技術面の相談ができるサービスの紹介などについて、徹底解説いたします。
COLUMN
スマホを持ち歩くだけで、職場についたら自動勤怠報告してみた-AWS IoT-
クラウド活用に関するさまざま情報をお届けするメルマガを毎週配信しておりますので、ぜひこの機会にご登録ください。
 |
こんにちは！奥田です。 |
|---|
今回はAWSをつかったIoTシステムの構築の評価もかねて、スマホをもって職場に近づくだけで自動で勤怠報告ができるシステムを簡易的に作ってみました。
1. 持つだけ!?自動勤怠報告の構想
現在自担当内のツールとして、日々の勤怠開始と終了をWEBUIから登録しているのですが、これがめんどくさい。特にたまの出社の時に忘れがちです。
これを解消したいので自分が職場フロアにいるかどうかで自動に登録したいと考えました。
基本的にはよくあるBLEビーコンの接近をもとに判断する形式としていますが、専用にBLEビーコンデバイスを持つパターンですと持ち運びそのものを忘れがちなので、自身のスマホをそのままビーコンに転用し、かつデバイスの運用も楽なモデルを考えてみました。
（あくまでテストなので細かい実装は雑になっていますのでご了承を、、、）
まず早速ですが下記が構成イメージです。
各専用アプリをインストールしたユーザが自身の業務エリアに到着すると、接近を検知し勤怠開始として通知されます。
退出に関しては、各ユーザごとの最後の検知時間をもとに判断しますが、お昼休憩なども含めて1時間の未検知で退勤ということにします。
詳細は後述しますが、各ポイント概要は下記です。
スマホ：
専用アプリをインストールする運用イメージですが、今回は簡易的にnRF Connect for Mobileというアプリを使います。
IoT GW：
株式会社ぷらっとホームのIoTゲートウェイ『OpenBlocksIoT』を使用します。各種センサを各種環境に転送するIoT GWとしての機能が充実しており簡単に・楽に本格的な環境を準備できます。
AWS：
IoT Coreをデータの受け口、IoT Eventsをデータ処理と入室,退室の判断ロジックに使います。
完全にプログラムレスで作り上げることができました。
2. ユーザのスマートフォンについて
各ユーザのスマートフォンは下記の要件で動作することが求められます。
- 自端末からBLEビーコンを定期的に発信し続けるため、アドバタイズモードでペリフェラルの役割を担う。
-
BLEビーコンとして発信されるアドバタイズデータは下記を満たします。
→この勤怠アプリからの発信であることがわかる。
→どのユーザからの発信かというのを特定できる。
nRF Connect for Mobile
上記のアプリケーションを作ることも考えましたが、今回は簡易的にテストするため 「nRF Connect for Mobile」というアプリを利用しました。
このアプリはスマホを利用してBLEのデバッグを行うことができる機能を有しており、BLEビーコンのスキャン解析だけでなく、自端末自身をBLEビーコンの発信を行うアドバタイズモードとして動かすことができます。またそのアドバタイズデータに含めるデータも自由にカスタマイズ可能となります。
アドバタイズデータの要件を満たすために下記のようにカスタマイズしました。
今回はiBeaconフォーマットに則っとるため、Manufacturer Specific Dataをibeacon仕様にそろえて設定します。
- Company Identifier: 0x004C （Appleの固定値）
- iBeacon Indicator: 0x02 （固定値）
- iBeacon Length: 0x15 （固定値、21バイト）
- UUID: XX-XXXX-XXXX-XXXX-XXXXXXXXXXXX （自由に設定することができるので勤怠アプリケーションとして共通的に同一の値にする）
- Major: 0x0001 （自由に設定可能なので各ユーザごとに固有の値とする）
- Minor: 0x0002 （自由に設定可能なので各ユーザごとに固有の値とする）
- Signal Power: C5
3. IoT GWについて
IoT GWとしての要件は下記を設定しました。
- BLEのビーコンをフィルタをかけられる。
- ビーコンデータの一次処理を行える
→GWの情報付与や、重複排除等 - すべての設定が簡単に行える
OpenBlocks IoT FX1
株式会社ぷらっとホームのOpenBlocks IoT FX1を利用しました。
”IoTデバイスやクラウドとノーコード接続堅牢・高速・低電力消費の最新IoTゲートウェイ”となっています。
様々な制御が行えるモジュールが用意されていますが、基本的な流れとしてはセンサデータの受信→(必要であれば制御処理)→クラウド等上流への送信という流れになります。
OpenBlocksシリーズにおいては“サービス”という形で各種設定を簡単にしてくれるパッケージが配布されており、簡単に
AWSへの接続認証を設定できたり、簡単にカメラ映像の転送などを実現できたりします。
今回利用するなかで、IoT GWとしてこれは便利という機能があったのでいくつかピックアップします。
3-1. データフィルタ
アドバタイズデータの冒頭プレフィックスでフィルタリングすることができるので勤怠アプリに関するデータのみに絞ることができます。
3-2. 重複制御機能
同一のデバイスIDのビーコンデータの指定期間内の重複の制御を行います。
3種類のモードがあります。
- インターバルトランスファー：指定期間内の同一センサーからのデータの重複排除して間引いてくれる
- エントリーポイントトランスファー：検知始めに関してのみ通知。指定期間経過で退場扱い。
- インアウトステータストランスファー：検知はじめと検知をしなくなったタイミング(指定期間経過後)でin,outという情報も付与して通知してくれる。まさに入退室のステータス把握をGWの機能のみで判断できる。
今回についてはAWS側の機能も活用したかったのでインターバルトランスファーを採用。
3-3. 固定情報付与
クラウド送信時に任意のデータを追加できる。どのGWでの検知なのかなどの情報を追加可能です。
3-4. 受信信号強度
RSSI値でフィルタ可能なので、検知距離をある程度可変できます。
4. クラウド(AWS)について
クラウド側の要件は下記を設定しました。
- 各IoT GWからのメッセージを受け取り後続の処理に仲介するブローカとしての役割を担う
- 初めて検知したときと指定期間検知しなかったら、通知というような複雑な閾値処理を行える。
- サーバ管理不要で、極力プログラムレス
AWS IoT Core
クラウド側でデータを受信しブローカーの働きをするサービスとして今回「AWS IoT Core」を採用しました。
フルマネージドサービスなのでサーバ管理不要で、デバイスの一括管理やカスタム認証など多彩な機能も魅力的です。
テストクライアントでGWからのデータ受信を確認したら、メッセージのルーティングルールとして後述する「IoT Events」の「入力」を設定しました。
IoT Events
今回「AWS IoT Core」を採用しました。
これはセンサーからのデータなどを監視し、特定のパターンや異常を検出するためのフルマネージドサービスです。
基本的な流れとしてIoT Coreなどからのデータストリームを「入力」として設定して、検出モデルを定義してアラートやアクションを自動化することになります。
特定のデバイスの検知と未検知になった際などの処理を作ろうとすると当初、DBにデータ蓄積してそのデータをもとにLambda処理など行う構成が浮かびましたが、これを使えば複雑なアラームルールも簡単にできました。
まずは入力を作成します。これは転送元からのデータフォーマットなどを定義する箇所となります。実際の受信データサンプルをJSONファイルとしてアップロードすることでスキーマを認識させます。
次にアラートの発報条件にあたる探知機モデルの作成を行います。
探知機モデルGUIベースでデータに対する計算、条件設定などを行います。最小の処理単位が”状態”と呼ばれるもので、矢印でつなげて状態間の遷移を行います。
矢印は遷移イベントとよばれ、遷移条件を設定し、その条件にのっとり遷移する。
各状態では3種類の実行タイミングを定義することができます。
- OnEnter 状態に遷移してきたときに動く
- OnInput この状態にいるときにデータが入力されたときに動く
- OnExit 別の状態に遷移するときに動く
それぞれの状態の実行タイミング内および、遷移イベントで条件式を設定し、どのようなアクションをとるかを指定することができる条件式は、センサー値や用意された値をもとに設定していきます。用意された値として任意の時点からの経過時間などを利用することができます。
アクションとしてはSNS転送などが選べます。
この探知機モデル自体が動き出す条件としては「開始」というブロックとつなげた「状態」で設定します。「開始」は常に入力を監視しており、最初の「状態」のOnInput条件にてどの「入力」リソースに値がきたかを設定することで、遷移が始まります。
今回は画像のように”in_detect”と”outdetect_and_prepaernextdetect”という状態を用意します。
この状態同士は”timeout”と”re_detect”という状態遷移でつなぎます。
基本的な流れとしては検知中は”in_detect”状態にとどまり、検知データが入ってこない時間をタイマーでカウントして時間切れとなったら”outdetect_and_prepaernextdetect”状態に移動させます。
それぞれの状態に入った時に通知を飛ばすことで勤務開始と退勤が分かるという仕組みです。
以下設定の詳細を紹介します。
4-1. 状態”in_detect”の定義
OnEnterとOnInputのタイミングで条件式とアクションを設定します。
OnEnterではこの状態に入ってきたとき=入室開始とし、条件式はtrueでアクションとして①未検知となってから退室扱いとする時間をタイマー設定する②勤務開始の通知をAWS SNSに飛ばすの二つを定義しています。
OnInputでは初めて検知したとき、未検知タイマー以内で継続的に検知したとき、に備えます。
条件式として入力にデータがあるか？を設定することでセンサーデータの流入を確認します。
検知をしている場合は退室扱いのタイマーはリセットし続けます。
4-2. 遷移”timeout”の定義
退室扱いのタイマーが時間切れとなったらin_detect状態から遷移する条件を設定します。
4-3. 状態”outdetect_and_prepaernextdetect”の定義
OnEnterとOnInputのタイミングで条件式とアクションを設定します。
OnEnterではこの状態に入ってきたとき=退室とし、条件式はtrueでアクションとして①タイマーの削除(再び入室を検知するのに備える)②退勤の通知をAWS SNSに飛ばすの二つを定義しています。
4-4. 遷移”re_detect”の定義
一度退室扱いとなってから再び検知したときに備えて状態outdetect_and_prepaernextdetectから遷移する条件を設定します。
ここまで設定したら、発行/保存します。
この時「一意のキー値ごとに探知器を作成する」を選択することで当該のキー(data項目)の値ごとにこの探知機が作成されるので、各ユーザごとに独立したアラート評価が行うことが可能となります。
5. 動かしてみる
実際にこのシステムを動かしてみます。(動作確認のため退室判断のタイマーは10分です)
スマートフォンがIoT GWの検知範囲に入ると当該のユーザごとにIoT Eventsの探知機ディテクターが作成され、値の評価が開始されます。
テストなのでSNSからはRawデータが勤務開始として送信されます。（実際の運用時は文面の成型やAPI連携が行えます）
スマートフォンが検知範囲から出てから10分後です。退室判断となりoutdetect_and_prepaernextdetect状態に遷移しました。
SNSへの通知も再度行われました。
6. 最後に
今回は勤怠報告の自動化というユースケースで、AWSを利用したIoTシステムのモデルケースを作成しました。
IoTではセンサの選定や、ネットワーク設計、クラウド構築など様々な領域での検討が必要となりますが、ポイントとしてはいかに運用を楽に、可用性を高めるかというところになります。
勤怠報告というユースケース以外にも、公共福祉での観点での人の見守りや、従業員や顧客の人流把握などにも適用できます。
IoTの利用に課題を感じていたり、解決したいお悩みなどがありましたら是非こちらよりNTT東日本にご相談ください！
相談無料！プロが中立的にアドバイスいたします
クラウド・AWS・Azureでお困りの方はお気軽にご相談ください。