AWS クラウドに IoT センサー(温度/照度/気圧/気圧/加速度/ジャイロ値)データを可視化

こんにちは、水野裕識(みずのひろのり)です。

こんな御時世だからこそ、時間を持て余したいまこそ、遊び心をもって、新技術の取得に努めたいと思います。

今回は、『AWS クラウドに IoT センサー(温度/照度/気圧/気圧/加速度/ジャイロ値)データを可視化』という長いタイトルで恐縮です。センサーデータを、AWS CORE にて受信をして、ルネサスのサイトにてデータを表示できました。AWSからの配送パッケージ

中身をあけて、お楽しみの基盤とご対面。RX65N CPUボードの上に、センサーボードを載せて、さらにそのボードにwifi基盤を差し込むというお楽しみ様の構成です。

USBから電源を入れて、シリアルコンソール用にもう1つUSBを繋ぐと、無事コンソール出力を確認することができました。wifiの接続先情報、ルネサスのウェブサイトから得た端末名・AWS側エンドポイント・鍵を、基盤に書き込みます。

暫く待っていると、シリアルコンソールにMQTT通信を始めたというログが出力されます。なんか盛り上がり、そして期待が高まってきますな。

AWS の IoT COREにある シャドーステータスを確認に行きますと、おー、受信結果が表示されてます。少数2桁の精度必要か?というのは置いといて、TIMESTAMPもあるので、これをDBに蓄えれば、時間グラフ表現もできそうです。

センサーデータは、温度・湿度・照度・気圧のほかに3軸加速度(左下図)と3方向ジャイロ値(右下図)です。これが30秒ごとにクラウドにあがるようになっています。

キット開封から、設定と確認、ここまでの作業時間は、3時間ほどでした。この手の基盤をいじっていると、ドライバー作業だとか、様々な作業に囚われて、あっというまの深夜作業という時代は、過去のものなのですね。ほんとに良い時代ですな。

基盤のファームウェアも、GitHubにあり、それをDLして修正してファームを焼けばすぐに新サービスとして動作するという印象になります。

そうしますと、これが全国100万台配布されてデータが収集されてきたときに、どんな問題を解決するのか、あるいはどんな作業を軽減化できるのかという事業モデルを考えることにこそ価値があり、それに時間を使えといっているような気がします。

次のつぎのその先のICTによるサービスモデルの実現に向けて、行動をしていきたいと思います。ハード基盤からデータ連携まで、ご要望の方は、ご連絡頂ければと思います。

#with Corna

今年初登山、雲取山へ

こんにちは、水野裕識(みずのひろのり)です。

2月の終わりに、東京で一番高い山である雲取山に登ってきました。少し振り返りたいと思います。2千メートルを超える冬山なので、いろいろと準備をしてきました。今回、ご同行頂きましたのは、古畑勝海さん。古畑さんは、山登り歴がながく、たくさんの明峰を登り、達人さん。昨年の飯豊山登山で初めてお会いし、じつは、私からご一緒していただけますかとお願い申し上げた。

ホリデー快速奥多摩1号で、奥多摩駅下車、そこからバスで揺られて、鴨沢バス停で下車。下界は、好天。元気よく、バス停をスタート。

古畑さんと愉しく会話をしながら、緩やかな登りを、少しゆらりゆらりと登っていく。山道はブナの葉が積もり、足に柔らかな感触がある。空気も新鮮。深く深呼吸をすると、肺一杯に酸素が広がり、頭も冴える気がした。

この山道は、平将門迷走ルートとして立て看板を観ながら、愉しみながら登ることができる。そういえば、グレートトラバースで田中陽希さんが秩父連山の回を、自宅で見てきたが、番組のなかで、かれもこの看板に気を囚われ、説明していた。どこまで本当なのかというのはあるが。

YAMAPアプリで登山の状況を捉えていたので、それをみながら振り返る。1650mの七ツ石山までは、たいへん順調であった。時間あたり317m登っていたようだ。9時12分スタートで、12時47分で七ツ石山着。足を振り上げて登る山でなく、勾配がゆるやかなため、一歩ずつ進めれば、自然に着する。このあたりから、気温も下がりはじめたと感じ、手袋・ニット帽、厚手の上着を羽織ることで、残りの500m登りに備えた。

そして、身体に異変が生じた。

山頂は2017mだ。ここからなんと、2時間近くも要してしまったのだ。登頂は14時54分。時間あたり220mしか登れなかった。たしかに、吹き付ける風もましてきた、小雨から雪に変わりはじめて、温度も0度以下であったろう。

七ツ石山までのスピードに対して、30%以上ダウンした計算である。その理由は、足の付け根の股関節が急に痛みだしたのである。ここまでまったく緩やかな登りであった印象なのに、すこしずつ足に違和感がではじめて、だんだん股関節の痛みが増して、最後は足が前に出せない・でないという状況に陥った。

なんとも不思議であった、これは一体なんだったのか。腸骨筋という説も。。。

それまでも膝頭、ふくらはぎなどいろいろと痛みはあったが、股関節は初めての経験で、ご一緒頂いた、古畑さんには、気を遣わせてしまい、申し訳なく思っている。それでも、なんとか山頂に達することができた。

やった。

疲労困憊のわたしと、山頂標柱(笑)。

山頂を超えた後の下り。ここかもさらに難儀。というのは、山道に積雪10-20cm。それがほぼ凍っていて、ガリガリ。ガリガリの状態の道を下るということが、怖い。一歩踏み出すと、つるんと滑り、滑落しそうな気分になる。下り坂に足がでないのである。ガリガリという単語、ここに来て言葉としての理解と自分の体感として捉えることができた。経験は母だ。少し降りたところで、古畑さんがアイゼンを付けようといわれ、下りの途中で軽アイゼンを装着した。ここから、山荘まで、転がるように降りていき、無我夢中であまり覚えていないが、なんとか、雲取山荘に到着した。15時40分。

雲取山荘は大きく、収容人数も200名位こなすようだ。この日の登山客はだいたい50-60名というところか。古畑さんと私の2名で1室あてがわれ、部屋の中央に大きな炬燵がありがたかった。凍えた身体をそのなかに沈め、夕飯までお話をつづけた。その後も、大きなヒータの前で、ビール缶で小さく乾杯をした。他の登山客のなかには、足利市からいらしたり、女性お一人で登っていらっしゃっていたり。みなさん、それぞれの想いをお話をされていた。

朝方まで風と雪が横殴りであったようだが、朝一番、ご来光を捉えることができた。朝食を食べたあと、昨日降りてきたガリガリ坂を一挙に登り、朝はやくに、山頂に到着した。そこで、撮影して頂いた渾身の1枚。背景にははっきりと富士山が見える。360度見渡す限り、うっすらと雪化粧をした山々、山塊が凛とした空気の先に構えている。ここだからできる素晴らしい経験だ。

2020年の2月の雲取山。冬山の経験は初めてであったが、この山登りをとおして、自分の糧にできたと思う。山は素敵だ。今回ご一緒いただいた、古畑さんには、あらためて感謝をお伝えしたい。そして、また、機会があれば、ご一緒したいと願っていることも。素晴らしい経験を共有できました。本当にありがとうございました。

 

 

 

2020年からの事業継続について考えています

あけましておめでとうございます。水野裕識(みずのひろのり)です。

お正月の21時のNHKスペシャルは、普段のお正月のお祭り騒ぎの番組からは、ほど遠い深刻な現実の内容でした。

地球規模の問題を目にすることが増えました。昨秋の台風19号、21号では、中小河川が溢れて、大きな爪痕を残しました。私の住む場所は、一級河川の側であり、実はその河川が耐えるかどうか、恐怖を感じました。実際、上流では、小規模ですが、溢れました。

2030年、あと10年後までに平均気温を現在の1.5度までに抑えなければならない。これが事実だとすると、時間が短すぎないでしょうか。この深刻な事実に、人類はどのように立ち向かうのでしょうか。1972年の「成長の限界」では、人口の増加は、食料の増産に追い付かないのが2030年と予測していたと思いますが、温暖化や資源の不均衡、技術の急激な進展まで検討に含められていなかったように思います。

平均気温が+1.5度に達したとき、さらに不安定化することは、科学的に明らかだそうです。北極の氷が解け、アマゾンの森林が立ち枯れや火災により荒れた草原にかします、その上で、シベリアやアラスカで永久凍土が溶けて、地下に蓄えられていたメタンが放出。メタンは二酸化探査の25倍の温暖化を促進させる。これらがあいまって、温暖化がさらに加速し、平均気温が4.5度上昇するそうです。地球上の氷が融解することから、海面上昇が起きる。台風もスーパー台風にかわってしまう。

温暖化の刃は、実は企業の売上に直結するという皮肉をも生んでしまっています。水も、空気もありとあらゆる資源が、グローバルな環境の下、すべて繋がっているということを想起させます。ただただ、これまでの常識を続けているようですと、子供や孫の代から先がなさそうです。

地球規模に何ができるのかという話に比べますと、当社における行動は、たいへんに小さいものかもしれません。ただ、当社も、ICT・AIという立ち位置から何ができるかを考え抜いて行動しつづけます。ICT・AIは、グローバルに覆う世界の効率化を推し進めますが、効率化は、省力化・省人化となるわけで、そもそも仕事がなくす方向に作用してしまう。例えば、RPAのメリットを語る人は、x万時間削減しましたと喧伝しますが、それで、それに携わる人の仕事を奪ってしまいましたとはいいません。

ITに携わる人は、本来、仕事を創り出す方向の議論をしなければなりません。我々は、オンプレミスのサーバ資源を、仮想化技術でクラウドに寄せたときに、どれだけの資源が無駄にならいのか、あるいはCO2削減量を提示することも、マクロ的に計算します。装置サーバ資源、電力消費量、かける保守コストなどのKPIに照らし合わせても有利だとお伝えしています。

現在のレガシーシステムは、2025年までに交換すべきだと、国が言い始めています。クラウドの料金単価も、日々下がり続けています。サーバやネット機器を大量に購入して、時間とともに破棄するやり方は、終わりにしませんか。製造メーカの人も、もう分かっておられるのではないでしょうか。

今後は、大規模災害の事業継続性の観点からも、クラウドへの平行展開への依頼も増えてきそうです。単なるデータのバックアップ程度の話ではなくて、サーバをホットサーバとして用意をして、平行稼働するという時代になりそうです。しかも、国内の拠点サーバを起こすだけではなくて、世界拠点への平行稼働案件もあるやしれません。南海トラフなどを想定した場合の事業継続性は、国内では間に合わないからです。

当社もこの大きな視点・流れのなか、地球規模の資源のことまでは、大きなことを考えるところまでなかなか行けないとは思いますが、様々な会社におけるサーバ資源をクラウドに振り向けるをベースに、今年もお客様と真摯に向き合ってまいります。

本年も、どうぞ、よろしくお願いいたします。

ITシステム「2025年の崖」の克服とDXの本格的な展開

水野裕識(みずのひろのり)です。経産省が昨年から語り始めている「2025年の崖」についてと、その克服方法について考えを巡らせています。

従来の保守業務で7~9割の予算が取られて、新しいITサービスに振り分けられる予算が1-3割しか出せないそうだ。古くなる一方のシステムのなかで、新しいことをシステムに問い入れる開発も行えなくなってきている。さらに(数字の根拠は分からない)年間12兆円が溝に捨てられてしまっているようである。

開発SIerたちも、年を取って引退する。その時のドキュメントが整備されない、保守金額が縮退すれば、ノウハウの引継ぎも行われない。後進者も、中身を理解できず、システムに手を出せなくなる。

本来なら正常に動いている範囲において、社内でITの打ち手を考えられる人を育成をして、次の展開を提案できる人を育てるべきなのであるが、日本の会社はITをコストと見做す傾向があって、会社の傍流であって、本流にはなりえないようだ。しかし、経営はシステムと一体となって行われるべきという理解が深く浸透してないなかでシステム投資を決断せざるをえなくて、SIerに丸投げとなりがちである。そうして、請けたSIerも、多重請負派遣の事業構造に組み込まれて、身動きが取れなくなっており、日本IT技術者は、この20-30年ほど、夢も希望もない状態となっている。本来は、社長直下に会社DX企画推進部があり、経営責任を伴う形で、DX部が全部を掌握して進めるというスタイルだと思うが、もちろんそんな部署はありゃしません。

法のDXにより2025年までに最新のITに変貌を遂げられば、2030年にはGDPが年間130兆円押し上げられるとのことで、日本全体でDXに取り組もうというスローガンとその手法について主張が進められている。

たしかに、この10年でオンプレからクラウドへの流れは加速してきた。2010年頃に初めてクラウドを触れて、実際に使えるなと思えたがその1-2年後であった。瞬く間に社内から、少しずつオンプレサーバは消えた。レガシーサーバが、社内のサーバルームにLED点滅しているのが安心なんだという、レガシーSEも少なくなってきた。そりゃそうだ、基盤はクラウド会社で最新の状態に整備されているから。

話が少し脱線してしまったが、仮に日本全体で社内システムがDXにより刷新されたとすると、保守負担分が低下して、新しい戦略・道しるべが見えてくるのだろうか。DXが進むとすると、一番それが大事なはずだ。経理面からみれば、5年ごとのオンプレ資産償却と、クラウド対応費はどちらが安くなるのか、オンプレ資産を社内に有する危機管理(電源管理、セキュリティ、BCPなど)をどう判断すべきか。こういう総合的な判断を踏まえて、DXへシフトしていくべきで、当社はその対応の相談にも乗らせて頂いている。

DXレポート ~ITシステム「2025年の崖」克服とDXの本格的な展開~

の資料にある3章が、日本の未来を救うDX対応指針とのことである。これから、来るべきDXに向き合うために、じっくりと読みすすめ、理解を深めたいと思う。
と、今日はここまで。

 

リザバーコンピューティングで、時系列データを解く  その2

時系列データは、リザバーコンピューティング(RC)で解く その2です。

RCリザバープールノードの重み値は固定・修正しない??の意味が掴めないので、感覚として捕まえるために、少し手を動かして、遊んでみることにした。githubで、reservoir-computingを確認すると、20数件のサンプルが見つかる。その中から、EchoTorch と、simple echo state network を動かした。

時系列予測のベンチマークとしてNARMA10の4000データで学習して、1000データを予測。自分PC(iCore7)でも、数秒で結果が得られる。

すぐにモデルにフィットし、予測値にずれがあるようには見えない。その時の、アクティビティの出力結果は、毎回実行するたびにノードの出力は変わるものの、予測誤差がない。これは、なかなかの印象です。

そしてリザーブプールノードの重み値が変えない恩恵だが、学習時間が短い。このケースでも、IoTセンシングのサンプリングレート100Hz (100msec)なら、4000ポイントであれば、40秒+αで学習できそうな印象。何やら、たくさんのGPUユニットに深いノードで、収束させるのに比べると、このライトな感じは一体・・・・

時系列データパターンの何を教師データとして見抜かせるのか、パターン周期のどこをポイントにするかは、こちらの利用しやすい場所をいかに指示するかにより、その実装センスを持ち合わせる技術者が必要になる。

いま私は、睡眠の解析をしていて、ノイズありの時系列データからあるパターンの特徴抽出したい。そして、この技術を適用できるかもしれない。

もちろん、非線形ダイナミクスを表現する内部ノード構成、時系列パターンにマッチさせるノード構成は、今後の研究を待つことになろうが、現時点でも実用的なサービスに落とし込めそうな感じのする技術であるリザバーコンピューティングは、IoTセンサーや時系列データに応用できそうである。