洋上で稼働するIoTプロダクトのプロトタイプ
この記事はUMITRON Advent Calendar 2021 4日目の記事です。
はじめに
こんにちは。UMITRONのCo-founder / CTOの岡本(@um_takuma)です。今年は会社として初めてAdvent calendarをやることとなりました。25日分埋めるにはソフトウェアエンジニアとハードウェアエンジニアをを足しても厳しいなと考えていたのですが、エンジニア以外も手を上げてくれました。それでも複数記事書く人も多かったり空欄もありますが、来年はどうなっているでしょうか。
Advent Calendar 4日目は洋上で稼働するIoTプロダクトのプロトタイプという内容をお届けします。
UMITRONは水産養殖の課題を解決するスタートアップです。創業期から魚の生育の課題を解決することを目的としていて、UMITRON CELLという洋上の生簀に設置する自動給餌器としてIoTプロダクトを開発しています。こちらのプロダクトはカメラが付いていて生簀の中の魚の様子を遠隔でモニタリングしながら給餌することができたり、カメラから取得した給餌時の魚の様子の動画に対して画像処理と機械学習を行い、魚の食欲指数を計算して最適な給餌になるよう自動的に給餌を制御する機能があります。これにより、魚が餌を食べていないことを検知して無駄になる餌の量を削減したり、逆に食欲が旺盛なのに給餌量が足りていないということを防いだりします。
このようなIoTプロダクトのデバイスを開発するにあたり、本当にこのような製品が開発できるのか、ユーザである養殖事業者の課題を解決できるのか、開発したら実際にユーザに利用してもらえるのか、といったことを仮説検証するためにプロトタイプのIoTプロダクトを作る必要があります。UMITRONではUMITRON CELLという大型の自動給餌器を開発する前にプロトタイプの開発を行いました。最初から大型のデバイスを開発するのはスタートアップにとってリソースも足りず、技術的難易度も高いため、まずは小型のIoTデバイスを開発して検証を行いました。プロトタイプは既存の給餌器を加工して外付けのIoTデバイスにBluetooth接続できるようにして利用するものでした。
検証したい機能で予めわかっていたものは以下のとおりです。
既存の給餌器の給餌機能をソフトウェアで制御して遠隔から利用できる
カメラを設置して遠隔で生簀の魚をモニタリングできる
洋上でこのようなソフトウェア機能を提供するIoTデバイスが稼働できるかということが最初に検証すべきことでした。さらにユーザに利用してもらって発生した要望に沿って追加機能を開発してく必要もあります。このプロトタイプをどのように開発したのかということについて書きたいと思います。
プロトタイプで検証したいこと
洋上で稼働するIoTデバイスのプロトタイプということで設置する環境面から以下の点を考慮する必要がありました。
デバイスが稼働するための電源を太陽光で賄う必要がある
屋外で稼働するため、自然現象の影響を大きく受ける
人がデバイスの近くに常時いるわけではない。近くに行くのに時間がかかる
デバイスが設置される洋上の生簀は沖合養殖と比較すると沿岸ではありますが、それでも船で数分のところから30分程度かかるようなところもあります。そのため、電源を外部からの供給なしでまかなう必要があります。ネットワークに関しては幸いにも生簀が携帯回線が届く範囲内であるため、SoracomのようなIoT向けのSIMを利用することができます。自分たちがすぐにデバイスの近くに行けるわけではなく、ユーザも常に生簀の近くにいるわけではないです。
このような条件から以下のような方針を取って開発を進めました
できるだけ早く洋上に設置し稼働させる
設置した後にソフトウェアを容易に変更できるようにする
設置した後から開発したソフトウェアを動かせる余力を設ける
設置した後にIoTデバイスの調査が容易にできるようにする
できるだけ早く洋上に設置し稼働させる
これは屋外に置く必要があるIoTデバイスであるがゆえです。自然環境にさらされるデバイスは屋内で使用されるデバイスと比較して厳しい環境で稼働する必要があります。そのような環境でも動作するように入念にテストしようと試みますが、そのようなテスト環境を用意して行うのは時間やコストがかかり、かつ、それでも完璧にすべての課題を洗い出すようなテスト環境を用意することはできません。長期間屋外に設置していないと発生しないような課題も想定できます。そのためプロトタイプの時点ではある程度屋外で稼働するものができたら実際の環境に設置して課題を洗い出すことを優先します。
設置した後にソフトウェアを容易に変更できるようにする
前述のようにできるだけ早く実際の環境にデバイスを設置する必要があるため、ユーザが将来的に必要としているソフトウェアの機能を開発するのに十分な時間が取れるとは限りません。またソフトウェアの特性上すべてのバグを開発中に発見することはできません。実際の自然環境でないと発生しないような問題もあります。そのため、洋上にデバイスを設置した後もソフトウェアを容易に変更することでそのような問題に対処します。そしてそれをできるソフトウェアアーキテクチャにする必要があります。洋上に設置したままの状態で遠隔でソフトウェアを更新できるようにします。
設置した後から開発したソフトウェアを動かせる余力を設ける
また、後からユーザが必要になった機能を開発しデバイス上で実行できるだけの余力をあらかじめデバイスに持たせるということを意識しました。最初からソフトウェアのパフォーマンスをチューニングすることに時間をかけるよりも、プロトタイプと割り切って計算リソースに余裕のあるハードウェアを採用します。
ソフトウェアのパフォーマンスチューニングはIoTプロダクトの場合、サーバサイドなどと比較してボトルネックになりうるリソースが多く、実際の自然環境でテストしないと意味がないです。また、ソフトウェアパフォーマンスのチューニングは時間がかかるだけでなく、ソフトウェアのロジックが複雑になりバグが発生しやすくなったり、のちの開発スピードに影響が出たりすのでそれを最初は避けるという意図もあります。
設置した後にIoTデバイスの調査が容易にできるようにする
これも前述と同じようにデバイスを設置した後に起きる課題・トラブルを調査できるようにするためです。実際に洋上においてから初めて遭遇するトラブルとして故障したハードウェアがどのような挙動になるのか、長期間ソフトウェアを動かすことで初めて遭遇する問題などがあります。また長期間動かせば動かすほどなかなか遭遇しないレアケースというものに巡り合う確率が高くなります。そのような事象のデータを後できちんと検証する、できれば即時で調査できるような環境を用意しておくと以降の開発に役立ちます。
左手の奥に見える3つの島の付近に生簀がありプロトタイプを設置した場所の1つ
実際にやったこと
これらの方針を踏まえて以下のように開発を進めました
Raspberry Pi + Raspberry Pi OSを採用する
遠隔からデバイスにログインできるようにする
電力を確保する
複雑な機能の実装はサーバサイドでやる
Raspberry Pi + Raspberry Pi OSを採用する
遠隔からデバイスにログインできるようにする
IoTデバイスのソフトウェアを設置後に遠隔で容易に更新をし続ける。トラブルが起きたときにデバイスの調査を遠隔で行える。これらを安価に満たすためにSSHでログインできるLinuxをデバイスのOSとして採用します。(当時はRaspberry Pi OSではなくRaspbianという名称でした。) そのためにIoTデバイスのハードウェアとしてRaspberry Piを採用しました。LinuxをIoT環境で採用するときに事例が多く開発しやすいためです。ハードウェアとして調達が容易、ハードウェアトラブルについても検索しやすい等のメリットがあります。ソフトウェア開発にLinuxの資産を活用することもできるため、後から追加機能の開発などにも高速かつ柔軟に対応できます。プロトタイプに必要なネットワークを利用した遠隔制御やカメラのモニタリング機能もLinuxには様々なライブラリ資産が存在します。またトラブル調査のためにログをデバイス内に保存しておくようにすれば、サーバサイドにすべてのログを送信しなくてもデバイスにログインして必要なものを適宜調査できます。
IoTデバイスでは他にArduinoなどのOSの乗っていないマイコンを採用するケースもあります。洋上は電力確保が難しいので省電力なマイコンを採用しようという考えもありますが、マイコンでは後から生産者の要望にそって開発した機能を十分に動かせる余力があるかは疑問がありました。また遠隔でのソフトウェア更新、トラブル調査のためのログ送信など、それらの機能のために予め開発が必要になります。そしてそれらもすべてのケースでうまく動くようにするにするには開発工数が膨らみます。そこで遠隔ログインと追加機能の稼働余力を優先し、電力の問題は他の方法で解決するようにしました。
電力を確保する
Raspberry Piを採用しましたが、実際に洋上の生簀におけるソーラーパネルのサイズやデバイスに組み込めるバッテリーのサイズを考えると省電力なRaspberry Pi zeroを採用したとしても電力が十分とはいえないということがわかりました。そこで省電力なArduinoと組み合わせてRaspberry Piの電力を管理することにしました。今回解決したい課題の特性上夜間はユーザが操作する必要がないため(夜は暗くてモニタリングができない、夜に魚に給餌することはない)、夜間は電力消費の多いRaspberry Piの電源を切っておいて、朝になったらArduinoがRaspberry Piの電源を入れるという構成にしました。日照がある間は太陽光によるバッテリーの充電が行われ余剰電力があります。一方夜は充電が行われず、バッテリーから電力を消費するしかないのです。つまり夜間の消費電力さえ気にすればいいことになります。(なお実際は悪天候で日照がないときは電力はバッテリーから消費されます。)この構成のおかげでArduinoだけが24時間稼働することになり、Raspberry Piは昼間のうち指定された時間だけ起動することになります。
またこのRaspberry Piの起動時間は遠隔で変更できるようにしておきます。夏場と冬場では日照時間が違うので、Raspberry Piが起動できる時間も違いますし、悪天候が続いた場合に一時的に起動時間を本来よりも短くして、天候の回復を待つというような運用も可能です。他にもネットワークの転送量を減らすようにソフトウェアのロジックを変えて消費電力を減らすということも可能です。(実際に14日間晴れがないというケースは経験しました。) またバッテリーの電圧のデータをトラックすることは重要で、現在の日照量で十分充電ができているか把握したり、バッテリーの電力だけで稼働可能な残り時間を計算できたりします。
複雑な機能の実装はサーバサイドでやる
遠隔でデバイスのソフトウェアを更新できるようにしたとしても、サーバサイドのソフトウェアと比較すると労力はかかります。デバイスにログインして問題を調査する場合も同様です。なのでデバイスのソフトウェアの更新頻度は少なく、問題も起きにくいような実装を考える必要があります。
そこで、最初は複雑な処理はサーバサイドで行うようにして、デバイス側では簡単な処理だけを行うように実装します。例えば機械学習をデバイス側で行わず、サーバにデータを送信してサーバサイドで推論を行いデバイスに推論結果を返す。ユーザからデバイスへの命令も一度サーバサイドで受け取り必要な処理をしてから、デバイスに単純な命令を送る。データの転送量が多くなる、レスポンスが遅くなるといったデメリットがありますが、それは実際に問題になって解決するべきときになってから解決するようにします。こうすることでプロトタイプの開発速度と安定性を向上することに繋がります。
実際の開発では、給餌タイマーの実装を最初はサーバサイドで行いました。給餌タイマーという機能はユーザが指定した時刻に給餌が自動的に開始されるというものです。ユーザは遠隔でデバイスの給餌タイマーを変更することが可能です。この実装方法として最初はユーザの設定した給餌の時刻になったら、そのタイミングでサーバからデバイスに給餌命令を送るという実装になっていました。こうすることでデバイス側は給餌命令を受け取ったら給餌を開始するというシンプルな実装にできます。デバイス側で時刻を計算して実行しようとすると、時刻の同期やユーザが設定したタイマーをデバイスに保存/更新するといった処理も実装する必要になります。最初はこのような実装にしておいて、プロトタイプのソフトウェアが安定して稼働するようになってからデバイスに複雑な機能を移していきます。
まとめ
今回は洋上で稼働するIoTプロダクトのプロトタイプの作成時の話を振り返ってみたのですが、すべてのIoTプロダクトの開発にこのやり方が適しているとは限りません。電源やネットワークが潤沢にある環境やすぐに物理的にハードウェアにアクセスできる環境もあります。プロダクトとして高速なレスポンスが必要なため最初からエッジコンピューティングをしなければいけない場合もあります。作ろうとしてるプロダクトの性質、検証しようとしていることに合わせて、どこを最初にやるのか、どこを後回しにしてもよいか、ということは変わってきます。IoTプロダクトはWebサービス、モバイルアプリと比較して用いられるユースケース、環境が多岐に渡るため、自身のケースに合わせて考える必要があります。
ウミトロンでは一緒に働く仲間を募集しております。持続可能な水産養殖を地球に実装するというミッションの元で、私たちと一緒に水産養殖xテクノロジーに取り組みませんか？
https://umitron.com/ja/career.html
この記事が気に入ったらサポートをしてみませんか？