見出し画像

RaspberryPiを使ったテスト環境についての紹介

はじめまして、Idein 株式会社 の legokichi です。
Idein ではシングルボードコンピューターである Raspberry Pi が使える IoT プラットフォーム "Actcast" を開発しています。弊社では今年から Raspberry Pi 上で動くファームウェアの動作検証用システム "sdwire pi" を組んで運用しているので、紹介したいと思います。


背景

Raspberry Pi では OS のブートストレージに SD カードを使用しています。OS のイメージを焼き込んで起動するには、PC で SD カードにファームウェアを焼き、Raspberry Pi 本体に指しこみ、電源投入で起動する、という手順が必要になります。 この手順のために Raspberry Pi の公式サイトでは SD カードに Raspberry PI OS を焼き込むための Raspberry Pi Imager というツールが提供されています。

Idein で開発中の Actcast Agent も Raspberry Pi OS と同様に、Actcast Writer などのツールを使って OS のイメージを SD カードに焼き、Raspberry Pi 本体に指しこみ、電源投入で起動する、という手順が必要になります。

去年までは、この初回起動までの流れの挙動テストは手動で行われてきました。長年、初回起動のフローに変更を加えていなかったためです。しかし、今年から Actcast OS 2 や Actcast OS 3 という新しいバージョンのファームウェアを導入することになったため、手動テストの煩雑さが開発の大きな障害になっていました。

そこで、Raspberry Pi のファームウェア開発において、面倒な作業である「SDカードへの書き込みとOSの起動」を自動化する "sdwire pi" システムを開発しました。

ハードウェア構成


Sdwire pi クラスタ 4 台分

ひとつの "sdwire pi" システムは次のハードウェアで構成されています。

  • テスト用 Raspberry Pi

  • ホスト用 Raspberry Pi

  • FTDI USBシリアル変換ケーブル

  • SwitchBot プラグミニ

  • SDWire

順に説明します。

テスト用 Raspberry Pi

これは SD カードにテストしたいファームウェアを書き込み、挙動を観察するためのテストベッドとなる Raspberry Pi です。SDWireC と GPIO シリアルが接続されています。また電源には SwitchBot が噛ませてあります。モデルやメモリやリビジョンの異なる様々な種類の Raspberry Pi がテスト対象になっています。また、これらの Raspberry Pi にはそれぞれ様々なバージョンの Pi Camera や i2c デバイス なども接続されています。

ホスト用 Raspberry Pi

テスト機を操作するためのホストマシンです。Pi4B に素の Raspberry Pi OS を入れています。SSH でこのホスト機にログインして 、SDWireC やシリアルケーブルからテスト機を操作できます。テスト機 1 台ごとにホスト機1台が用意されています。

FTDI USBシリアル変換ケーブル

秋月のこれです。テスト機のシリアルコンソールにホスト機からGNU screen などの端末エミュレータからアクセスするためのケーブルです。無線LANとは違い、有線接続のシリアルコンソールなのでテスト機が何らかのトラブルによって無線LANに接続できないときもログインできます。
Raspberry Pi は GPIO でシリアル通信ができるので、ジャンパピンでホスト機の GPIO とテスト機の GPIO を接続してシリアル通信することもできるのですが、最初はホスト機を普通のタワーPCにして USB シリアル変換ケーブルでテスト機とシリアル通信していたので、そのときの名残です。

SwitchBot プラグミニ

スマホから操作できる IoT スマートプラグです。Swtichbot の Web API から も curl 等で簡単に操作できます。テスト用 Raspberry Pi の電源をオンオフするために使っています。製品ページはこちらです。

SDWire

このシステムの肝となる装置です。SDカードに USB ケーブルが生えているような構成になっており、USB ケーブルからの SDカードの書き換えと、対象機器へのSDカード挿入を電気的に切り替えることができるようになっています。もともとは Samsung の Tizen Project の一部のオープンソースハードウェアで、SDカードで起動するハードウェアのテスト用デバイスとして開発されました。とても便利なので Tizen Project が頓挫したあとも様々な会社が生産しています。

"sdwire pi" 前史

実は以前から Idein でもテスト用に SDWire を製造しようとしていました。"sdwire pi" 以前に使われていた PiZero Cluster や Pi Cluster を使ったテストでは PXE netboot を使っていましたが、ハードウェアが複雑で管理が難しく、netboot できない Actcast OS 1 とも相性が悪いため、ファームウェアのテストには使われていませんでした。そこで SDWire を自社製造して netboot ではないファームウェアのテストをしようとしていたのですが、コロナ禍の半導体不足で頓挫していました。今年初頭に他社から販売されるようになったので、今回はそれを購入して使っています。また SwitchBot 等の汎用品を使ったので、従来の Raspberry Pi cluster と比べて部品調達コストが安く、テスト機の拡張も容易で、専門知識が必要ないので使いやすいというメリットがあります。

運用方法

新しいファームウェアのテストをするために、テスト機でファームウェアをインストールし、動作確認をしています。ファームウェア初回起動までの手順は次の通りです。

  1. ホスト用 Raspberry Pi に SSH でログインする

  2. SwitchBot API でテスト機の電源を落とす

  3. SDWire を SD カード読み書きモードにする

  4. USB Mass Storage として SD カードが認識されるのでマウントする

  5. SDカードにテストしたい OS イメージを焼きこむ

  6. アンマウントする

  7. SDWire を SD カード接続モードにする

  8. SwitchBot API でテスト機の電源を入れる

  9. テスト用ラズパイが起動するので GNU Screen でシリアルコンソールに接続し挙動を確認する

この一連の手順をフルリモートでできるようになり、またテストスクリプトを書くこともできるようになったため、開発効率が大幅に向上しました。実際の運用ではホスト機にログインして使うだけでなく、CIからも使われています。

役に立った事例

このシステムを導入することで、実際に役に立った事例を紹介します。

フルリモート環境で自宅にない機材をテストできるようになった

Idein ではコロナ以降フルリモートでの開発をしていますが、テスト対象ハードウェアの社員間での共有は長年の悩みでした。テストに使うデバイスは、テスト対象となる Raspberry Pi だけで何種類もある上に、テスト対象となる カメラも複数あり、さらに i2c デバイスなどもテストしなければいけません。これらの周辺機器の動作確認をする場合、いままでは誰かがオフィスに出社して手動テストをする必要がありました。
しかし "sdwire pi" システムの導入により、これらのデバイスがすべて SSH から操作できるようになったため、動作確認のために出社して機材を組んで手動でテストする必要がなくなりました。

Actcast OS 2 のバグを発見できた

従来の Actcast OS 1 は Raspberry Pi OS のフォークをそのまま使っていましたが、Actcast OS 2 からはファームウェア更新のために OSTree を使って安全にファームウェア更新ができるように変更を加えました。しかし開発中に特定のデバイスで os1 から os2 への切り替え後に起動できないというバグに悩まされました。当初は原因不明でしたが、"sdwire pi" システムで何種類のも Raspberry Pi で起動テストを行ったところ、RAMが 8GB のモデルでのみこの現象が起きることが判明し、バグの原因特定に大きく貢献しました。このバグは OSTree による OS 切り替えをしているブートローダーの u-boot が 8GB モデルでのみクラッシュするというもので、 "sdwire pi" による一斉テスト以前の手動テストでは原因特定が困難でした。

 ファームウェアアップデート中の電源断のテストができた

Actcast OS 2 の OSTree による OS 切り替えには、この瞬間に電源を切られたらファイルシステムが壊れて起動できないかもしれない、というタイミングが存在しました。その期間を最小化し、何が起きるのかを網羅テストするために "sdwire pi" でのテストが行われました。
Raspberry Pi は起動時に起動するカーネルを第一パーティションの FAT 領域(いわゆる /boot) にある config.txt を読み込んでそのパーティション内にあるファイルから決定しますが、この /boot 内のファイル書き込みが失敗すると Raspberry Pi は起動できず文鎮化してしまいます。
そこで、あえてこの /boot への書き込み時に SwitchBot で電源を落として、再起動で復旧できるかを100回以上繰り返しテストしました。その結果、起こり得る故障の症状を網羅し対策を入れて、失敗率を計測でき、ファームウェア更新の安定性に自信を持つことができました。

今後の課題

SwitchBot プラグミニがよく壊れる

SwitchBot プラグミニはお手頃な価格で簡単につかえて、非常に良いユーザ体験を提供しています。しかし、初期不良が多く、よく壊れるという問題があります。 SwitchBot プラグミニを 10 台買って運用をしていると、3日後に2  台壊れて、半年でさらにもう 1 台壊れたりする、ということがありました。現状は安価なので買い直して新しいものと交換する運用を続けていますが、もう少し信用できる電源切替器はないか調査中です。

SwitchBot プラグミニの極性プラグが通常の電源タップに刺さらない

SwitchBot プラグミニは極性プラグを採用しており、左右でプラグの大きさが違います。コンセントが極性プラグに対応していないと刺さらないので、極性プラグ対応の電源タップを追加購入する必要がありました。

HDMI 出力の画面を確認できない

現状はテスト機の HDMI 出力の確認をしていません。そのため、 Act (actcast agent エッジデバイス内で動くアプリケーションソフトウェア)の画面出力のバグに気がつけないという問題が発生しました。この問題には ボスト機に HDMI キャプチャボードを取り付けてテスト機の HDMI 出力を確認できるようにすることで解決する予定です。

異常があったときに誰かしらオフィスに出社して直しにいかないといけない

SDカード故障や SwitchBot の故障には誰かしら出社して修理にいかないといけません。これはどうしようもないですね。

まとめ

Raspberry Piを使った IoT ファームウェア開発において、面倒な作業である「SDカードへの書き込みとOSの起動」をプログラマブルにする "sdwire pi" システムを開発しました。 これによってファームウェア更新のリモートテストと自動テストができるようになりました。また、フルリモートワーク開発において問題になりがちな周辺機器の動作確認もリモートでできるようになりました。弊社では今後も安定したサービスを提供していくため試行錯誤していきます。

Ideinでは現在、一緒に働く仲間を積極的に募集しています。
当社に興味を持たれた方は是非下記ページより詳細をご確認ください。