養殖支援システムとenebular

問題です。
世界の食料問題に関する、喫緊の課題とは何でしょうか？（制限時間5秒。配点3）
・
・
・
・
・
・
・
・
・
・
そうだね。プロテインだね。
・
・
・
はい。
食糧問題には色々な側面があるのですが、一つの課題として、プロテイン（タンパク質）の量が不足しています。日本は人口減少局面に入ってしまいましたが、世界全体でみると人口は増え続けており、かつ、一人当たりが食べるタンパク質の量はどんどん増えています。当然ながら、食肉の生産量も増えているのですが、なんと、天然の漁獲高は1990年代から横ばいで増えていません。海産物・水産物は貴重で限りある「資源」なので、ちゃんと管理して運用しましょうね、という方向になっており、今後も漁獲高が増えること期待できません。サスティナブル。

それでも、みなさんおいしいお魚さん食べたいですよね？そんな皆様の熱い思いにこたえるのが、養殖です。おいしいお魚をみんながおなかいっぱい食べるには、養殖生産量を増やすしかないのです。実は、既に、2014年に食用漁獲高を養殖生産量が超えています。このトレンドは、今後も変わることはありません。

養殖にはロマンがある¹。

この話をしだすと長いので、養殖に興味がある方は、↓のスライドもご覧ください。
第一回水産IoTLT資料

さてさて、本記事のテーマは、養殖そのものについて熱く語ることではなく、養殖とenebularの関係についてです。ウフルでは、バナメイエビの閉鎖循環式陸上養殖² という仕組みの支援システム（以下、陸上養殖支援システム）を作っています。どこにどうやってenebularを使っているのでしょうか？

陸上養殖支援システムのざっくり全体構成

陸上養殖支援システムは、ざっくり以下のような作りになっています。

クラウドの部分がざっくりすぎますが、だいたいこんな感じです³。

水位センサというのは、その名の通り水槽の水位を測っています。多項目水質センサというのは、pH⁴、塩分濃度や水中の溶存酸素量などを測定します。これらは、普通に市販されているものを使っています。

閉鎖循環式の陸上養殖では、水をぐるぐる循環させるため、水質のコントロールがとても重要です。気を抜くと、毒素が溜まってエビちゃんがすぐに全滅してしまいます。エビちゃんを全滅させないようにするための成分や、エビちゃんの生育を良くするための成分は、市販のセンサではうまく測定できないため、「すごいセンサ」を新規に開発しています。ここの詳細は、まだ非公開です。ごめんなさい。

既存のセンサと、新規開発のセンサがある、というポイントだけ抑えておいてください。

enebularが使われているところ

水位センサを管理するゲートウェイ(GW)の部分と、新規開発のセンサのコントローラにenebularのagentが入っています。

何が嬉しいのか？

enebularを導入して得られたメリットは、大きく二つです。

1. 開発期間の短縮
2. システム運用コストの削減

まず、開発期間についてみてみると、水位センサ管理用のゲートウェイ用のフローの開発は1ヶ月かからずに開発しています。また、新規開発のセンサのコントローラ部分は、3ヶ月未満です。このあたりの開発では、エラー処理や設定ファイルの取り扱いなど、汎用的な機能については、これまでの開発ノウハウを詰め込んで作っていますので、本質的なデータ処理フローの開発に集中してリソースを投入することで、開発期間を短縮できています。

「これまでの開発ノウハウ」は、今後、Building BlocksとしてenebularのDiscoveryに公開していく予定です。Building Blocksを活用することで、enebular/Node-REDを使った開発をもっと簡単に、短期間でできるようになると思います。

システム運用コストは、enebularのRelease 2.18.0 で使えるようになった「デバイスにSSHログインするためのRemote Maintenance機能」を取り入れたり、Files Deploy機能を使って設定ファイルをリモートから更新できるようにするなどして、現地に行かなくてもメンテナンスできるようにすることで、システム運用コストを削減しています⁵。今後、展開が始まり設置数が増えてくれば、設置事業者が現場で機器設定をしなくてもすむようにするゼロタッチアクティベーションも取り入れていきたいと思っています⁶。

課題

enebularを導入して良いこともあるのですが、それで全て万々歳という訳でもありません。

開発期間の観点で見てみると、enebularを使っても、システム全体の開発期間のクリティカルパスを潰せていないので、全体システムのローンチには時間が掛かっています。

システムコンポーネントごとの開発期間は、おおよそ下記のようになっています。

開発対象	開発期間	備考
水位センサー用GWのソフトウェア	1ヶ月	enebular適用
新規開発センサー用コントローラのソフトウェア	3ヶ月	enebular適用
新規開発センサーハードウェア(の試作機)	8カ月
Salesforceシステム	3ヶ月
AWSシステム	6ヶ月

例えば、新規開発センサーのソフトウェアの開発期間は確かに短縮できていますが、ハードの開発期間がそれに追いついていないので、せっかくenebularを使ってソフトを短期間で開発しても、結合試験ができないという状況に陥ります。

この辺りは、動作確認済みセンサや、動作確認済みゲートウェイなどの周辺ハードウェアを地道に増やしていくしかないのかな、と思います。極端な話、水位センサー（既存のセンサ）とSalesforce（SaaS）だけでシステムを組めば、最短3ヶ月でシステム開発を完了することができます。今後、このようなパターンをどれだけ増やせるかが、enebularの課題ではないかと思います。

まとめ

• 世界は養殖を求めている
• enebularを使うと、IoTシステム（の一部）を短期間で開発できる
• でも、まだ課題もあるので、これからも頑張ります

そんな感じで、記事を終わりたいと思います。

Happy Hacking!

1. 他のブログ からパクッてきました。ごめんなさい。 ↩

2. 某アイドルグループT〇KI〇が某番組のカレー作りで取り組んでいるやつです ↩

3. 通信回線部分がADSLになっているのに気づいたアナタ、鋭い。養殖場は大体の場合、超田舎に作るので、光回線が届いていません。5Gとか言い出せる雰囲気ではない。ネットがギリ届いているだけでも御の字。 ↩

4. イマドキの学習指導要領では「ぴーえいち」と読むらしいですね。筆者はどうしても「ぺーはー」と読む癖が抜けません。 ↩

5. なにせ、現場が超田舎なので、オンサイト対応はコストが高い。 ↩

6. この手のシステムの場合、往々にしてイニシャルコストは、機器単体のコストよりも設置コストの方が高くなりがちです。そのため、設置コストを削減することは、導入の容易さを担保するためにとても重要な観点となります。 ↩