養殖支援システムとenebular

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

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

養殖にはロマンがある[^1]。

[^1]: [他のブログ](https://qiita.com/takaoaoki/items/486bd4ab30719d8857fd) からパクッてきました。ごめんなさい。

この話をしだすと長いので、養殖に興味がある方は、↓のスライドもご覧ください。
[第一回水産IoTLT資料](https://www.slideshare.net/kotak/iotlt-206277261)

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

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

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

陸上養殖支援システムは、ざっくり以下のような作りになっています。
![概略構成図.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/122546/04938579-c36c-f0a1-b2a9-c608f0655357.png)

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

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

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

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

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

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

# 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機能を使って設定ファイルをリモートから更新できるようにするなどして、**現地に行かなくてもメンテナンスできるようにする**ことで、システム運用コストを削減しています[^5]。今後、展開が始まり設置数が増えてくれば、設置事業者が**現場で機器設定をしなくてもすむ**ようにするゼロタッチアクティベーションも取り入れていきたいと思っています[^6]。

[^5]: なにせ、現場が超田舎なので、オンサイト対応はコストが高い。
[^6]: この手のシステムの場合、往々にしてイニシャルコストは、機器単体のコストよりも設置コストの方が高くなりがちです。そのため、設置コストを削減することは、導入の容易さを担保するためにとても重要な観点となります。

# 課題

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

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

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

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

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

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

# まとめ

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

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

Happy Hacking!