aptpod Advent Calendar 2023 12月20日の記事です。
intdashグループの野本です。組込Linuxソフトウェア開発を担当しています。
aptpodでは、intdashに接続可能な組込Linuxシステムとして「intdash Terminal System（以降、Terminal System）」を開発しており、このたび大規模アップデートを行いました。Terminal System 2として近々リリース予定していますので、アップデート内容について（少し先取りして）ご紹介したいと思います！
- はじめに
- Terminal Systemとは
- Terminal Systemの開発経緯
- Terminal Systemの課題
- Terminal Systemの課題に対する解決策
- Terminal System 2の紹介
- Terminal System 2のデモ
- さいごに
- おまけ
はじめに
Terminal Systemをご存じない方向けに、まずTerminal Systemについて解説します。
Terminal Systemとは
Terminal Systemは、intdashに接続可能なゲートウェイアプライアンスで、組込Linuxにより構築されたシステムです。 名前に"System"が含まれていることからわかるように、ハードウェア・ソフトウェアを含んだシステム全体を対象としており、以下により構成されます。
エッジコンピューター: aptpodが開発した専用LinuxディストリビューションであるTerminal System OSがインストールされたハードウェア
アプリケーション: intdashサーバーとの間でデータ送受信を行うエージェントソフトウェア（intdash Edge Agent）、エージェントソフトウェアと外部デバイスとの間でデータを仲介するソフトウェア（デバイスコネクター）、各種サービスなど
外部デバイス: データの送受信を行うために接続されたデバイス。EDGEPLANT USB Camera、EDGEPLANT CAN-USB Interface、EDGEPLANT ANALOG-USB Interfaceなど
Terminal Systemの開発経緯
aptpodは、「“つながる”を社会のチカラへ」をミッションとして掲げ、「“あらゆるスペースをつなぎ、世界の新体験を創造する”」こをビジョンとして追求しています。 導入事例をご覧頂くと、多種多様なものをつないできたことをご理解いただけると思います。
"つなぐ"ことは簡単ではありません。
単純に物理的に機器を接続するだけでなく、取得したデータをintdashサーバーと送受信するできるように、ソフトウェアの対応が必要です。 あらゆるものを対象とする場合、アプリケーションレベルでの対応ができない場合があり、以下のようなOS（カーネル）レベルのカスタマイズ作業が発生する場合があります。
- カーネルイメージのビルド（カーネルコンフィグ変更、パッチ適用など）
- ドライバのビルド、インストール
また組込機器では、動作保証の観点から、システム全体の構成管理が非常に重要となります。 以下のようなことが発生しないように、堅牢かつ安定性したシステムを開発する必要があります。
- 昔のOSでは動いていたのに、最新のOSでは動作しなくなった（
apt upgradeなどでパッケージを更新したら動作しなくなった） - あるデバイスでは動くのに、あるデバイスでは動作しない（デバイスのソフトウェアバージョンの不一致、手動作業の適用漏れなど）
また、幅広いユースケースに対応するため、エッジコンピューターの複数機種サポートも必要となる場合があり、様々なエッジコンピューターに対応したビルドシステムも必要です。 エッジコンピューターによっては、以下のような高度なカスタマイズ要求が発生する場合もあります。
- 不要なサービスやパッケージを削除したい（限られたリソースで動作させたい、セキュリティリスクを低減したい）
- エッジコンピュータごとにシステム設定を最適化したい
- 複数のエッジコンピューター向けに同じ方法でOSイメージを構築したい
Terminal Systemは、これら組込システム特有の課題を解決するために開発されました。
具体的には、組込Linuxディストリビューション開発のデファクトスタンダードであるYocto Project（以降、Yocto）を利用し、 組込Linuxディストリビューションである Termial System OSを開発することで、 カーネルレベルの高度なカスタマイズ、構成管理、複数機種のサポートを実現しています。
Terminal Systemの課題
そんなTerminal Systemですが、aptpod社内でしばらく運用したところ、以下の課題があることがわかりました。
アプリケーションの開発がしにくい
Yoctoを利用したシステムの場合、アプリケーション開発のために専用のビルド環境が必要です。
また、アプリケーションに依存ライブラリが必要となる場合は新しくパッケージをビルドする必要があることや、
そもそもYocto自体の学習曲線が急でとっつきずらいことなど、
Yoctoでのアプリケーションの開発はやりづらいことがわかってきました。
OTAがしにくい
Yoctoで生成したパッケージを利用し、ファイルベースのOTA機構を独自開発することでOTAを実現していました。
ただし、リポジトリ運用の取り回しに課題があったり、
小さな変更であってもYoctoを使わないとパッケージを生成できなかったり、
ファイルベースなので更新の完全性（差分更新による不整合、エラーのリカバリなど）に不安があったりと、
運用・機能面に課題があり、今後も現状の方法を続けていくことは厳しいのではという意見が寄せられておりました。
これらの課題解決は、aptpod社内での開発の問題だけでなく、パートナープログラムにより アプリケーション開発などをパートナー様が推進する際に確実に障害になることが予想され、早期に解決する必要がありました。
Terminal Systemの課題に対する解決策
これらの課題を解決するために、intdashグループでは以下の解決策を考えました。
アプリケーションの実行環境にDocker Composeを採用した
Yoctoでアプリケーションが開発しにくいなら、開発しなければいいじゃないかということで、アプリケーションの実行環境をDocker Composeに移行しました。
これにより、Yoctoによる高度なカスタマイズ・構成管理によるメリットを享受しながらも、アプリケーション開発のための専用のビルド環境が不要で、自由度の高いカスタマイズをすることが可能です。 コンテナを利用することでホスト環境からも分離されるため、基本的にはホストの変更影響も受けない *1 ですし、既存のコンテナイメージを活用でき、ソフトウェアの再利用性が高まるというメリットもあります。
Menderを利用したOTAをサポート
独自開発したOTA機構を廃止し、northern.tech社のIoTデバイス向けOTA(Over the Air)ソフトウェアアップデートソリューションであるMenderをサポートしました。
Menderは、Yoctoを利用せずにアップデートファイルを作成することができます。また、サーバーはSaaSでの提供もされているため、自社での運用・管理が不要で、コストを抑えながら導入可能です（OSS/オンプレによる自社運用も可能です）。 ファイルベースではなく、ブロックベースのA/Bアップデートを採用しており、堅牢かつ高機能なOTAが実現可能です（エラー時のロールバックも可能）。 また、OTAだけでなく、デバイス管理、各種設定/操作にも活用することができます。
こうした対策を実施し、誕生したのがTermial System 2となります。
Terminal System 2の紹介
Terminal System 2は、 旧Terminal System の課題（以降、従来のTerminal Systemを「旧Terminal System」と表記します。）を解決し、以下のような特徴を持っています。
- アプリケーションの実行環境にDocker Composeを採用
- Menderを利用したOTAをサポート
また、内部のアプリケーションもアップデートされています。
- エージェントソフトウェアをintdash Edge Agent 2にアップデート
- intdash Edge Agent 2向けに最適化されたデバイスコネクターをプリインストール
現時点では、EDGEPLANT T1をエッジコンピューターとしてご利用いただけます。 次のリリースでは、より手軽に試せる・カスタマイズのリファレンスとしてご利用いただけるようにRaspberry Pi 4をサポートしつつ、 任意のエッジコンピューターでTerminal System 2を動作できるようにする準備を進めています。
Terminal System 2のデモ
Terminal System 2の特徴はカスタマイズにより真価を発揮するため、標準機能だけではエンドユーザーからは何が新しくなったのか分かりづらいです。 なので、実際にカスタマイズ開発やOTAを実施し、どのように課題が改善されたのをデモンストレーションすることで、改善効果を説明したいと思います。
コンテナを利用したアプリケーション開発
今回はEDGEPLANT T1を利用し、Jetsonの推論サンプルjetson-inferenceの車載カメラ向け物体検出推論デモアプリケーションを動かして、計測をしてみたいと思います。
Terminal System 2では、アプリケーションの実行環境にDocker Composeを採用したため、特別なカスタマイズをせずにNVIDIAの公式コンテナイメージをそのまま再利用することができます。 旧Terminal Systemの場合、ソフトウェアを再利用するためにはYoctoで利用できるようにカスタマイズする必要があり、数日〜数週間のカスタム作業が必要となります（難易度によっては実現できない場合もあるかもしれません）。
実施手順の詳細はこの記事では省略しますが、以下の構成で計測を行います。 詳細についてはTerminal System 2デベロッパーガイドを参照してください。
jetson-inferenceコンテナ向けのdocker-compose.ymlファイル *2
version: "3" services: jetson-inference: image: dustynv/jetson-inference:r32.7.1 command: detectnet /dev/video0 rtsp://@:55555/inference_output --input-width=1920 --input-height=1080 --input-rate=30 --output-codec=h264 --output-encoder=omx --bitrate=4000000 --headless --log-level=success --network=dashcamnet runtime: nvidia network_mode: host privileged: true restart: unless-stopped init: true volumes: - /dev:/dev - /tmp/argus_socket:/tmp/argus_socket - /etc/enctune.conf:/etc/enctune.conf - /media/ssd/jetson-inference/data:/jetson-inference/data
準備ができたら、車にEDGEPLANT T1やペリフェラルなどをセットアップします。
実際に計測したデータはこちらになります。
物体検出推論デモアプリケーションが動作し、車載カメラに写った自動車や人物が検出されました！
今回はデモアプリを動作させただけですが、サンプルをカスタマイズすることで、検知時の処理を追加したり、モデルをカスタマイズすることも可能です。
Menderを利用したOTA
次に、Menderを利用したOTAをデモとして、上記サンプルの物体検知モデルの差し替えをしたいと思います。
Terminal System 2では、アップデートファイルをYoctoを利用せずに作成でき、Webブラウザ上から好きなタイミングでOTAを実行することができます。 旧Terminal Systemの場合、アップデートファイルの作成にはYoctoビルドが必要で、OTAのためにはリポジトリの立ち上げ・差し替えなどが必要になります（非常に手間・時間がかかります）。
実施手順の詳細はこの記事では省略しますが、以下の方法でアプリケーションアップデートを行います。 詳細についてはTerminal System 2デベロッパーガイドを参照してください。
モデルはjetson-inferenceコンテナ向けのdocker-compose.ymlファイルの--networkオプションで指定することができますので、このファイルをMenderを利用して差し替えます。
事前にトレーニングされたモデルを参照し、モデルをdashcamnetからpeoplenetに変更します。
これにより、検知するオブジェクトが人物のみになるはずです。
command:
detectnet
/dev/video0
rtsp://@:55555/inference_output
--input-width=1920
--input-height=1080
--input-rate=30
--output-codec=h264
--output-encoder=omx
--bitrate=4000000
--headless
--log-level=success
- --network=dashcamnet
+ --network=peoplenet
アプリケーションアップデートアーティファクトを生成し、ブラウザを立ち上げMenderからデプロイします。
デプロイが完了したので、再度計測します。
モデルが変更され、車載カメラに写った人物のみが検出されるようになりました！ *3
今回はファイルを差し替えただけですが、Menderのアップデートの仕組みは非常に柔軟かつ多機能であり、多くのユースケースに対応できます。 アップデートの仕組みについて詳細に知りたい方はTerminal System 2デベロッパーガイドを参照ください。
さいごに
この記事では Terminal System 2のご紹介をさせていただきました。
エッジコンピューターを利用したシステムを開発する場合、今回私達が経験したものと同じような課題にお困りの方もいらっしゃるのではないでしょうか。 Terminal System 2の課題解決アプローチに魅力を感じていただけましたら、ぜひ弊社製品・サービスのご利用をご検討ください！以下よりお問い合わせ頂ければと思います。
おまけ
aptpodの入社面接で「エッジコンピューター上でDockerアプリケーションを動かしたい」と発言したことを今でも覚えています（実際できて嬉しい）。 単純にYoctoで作ったOS上でDockerを動かすだけなら簡単です。それをシステムとして利用可能な形に落とし込むところに、aptpodのエンジニアの努力が詰まっています。
aptpodは、会社の方向性とマッチしていれば興味のあることについてわりと自由にやらせてくれる組織風土だと思います。 エンジニアのサポートも手厚く、入社当時（数年前）は、Linuxも不慣れで、YoctoもDockerもあまり使ったことがなかったですが、今ではあたりまえのように使うようになりました！
aptpodは、趣味で電子工作を楽しんでいるエンジニアや、Raspberry Pi、Arduino、Jetson、M5Stackなど、IoTデバイスをいじったりすることが好きな人も多く在籍しています（私自身も自作キーボードを作ったりしています）。 もし、弊社にご興味がありましたら、ぜひ以下よりお問い合わせください。aptpodで一緒に働きましょう。
*1:コンテナとホストを完全に分離することはできず、一部ホストに依存する部分があります（NVIDIA Container Runtimeなど）。 余談ですが、meta-tegraのkirkstoneブランチでnvidia runtimeを動作させるために色々と苦労しました。その話だけで記事がもう１つ書けるので、また別に機会にお話できればと思います。
*2:物体検出はdetectnetを使用します。ビルド済みモデルは--networkで指定でき、車載カメラ向けモデルのdashcamnetを使用します。カメラの解像度やFPSも合わせて指定しています。
*3:peoplenetは車載カメラ向けのモデルではないので、今回の設定では映像のフレームレートが低くなるようでした。
