Raspberry Piは本当に壊れやすいのか

6 min read読了の目安(約5400字 6

最近「Raspberry Piはすぐ壊れる」という趣旨の話題がTL上に出てきたので複雑な心境で眺めていました。
(以下簡略化のためRaspberryPi = RPiにします)

もし「RPiはすぐ壊れるから製品投入に向いてない」と思っている方がいるのであれば、その理由でRPiを切ってるのはもったいないなぁと思いこの記事を書いてみました。

カンタンに自己紹介をしておくと、某社でRPiをベースにした製品を作り「RPiはすぐ壊れないものなのか?」の検証を進めていました。今では各地で5000台以上は動いてると思います。

ざっと書いたので、あまり技術的に詳しいことは書いてませんが、読み物として楽しんでもらえれば幸いです。

(これらテストをしたのがどのバージョンのRPiなのかについては触れません。読者さんが使いたいと思ったRPiでで気になる部分をテストしてもらうことが良いと思っています)

10,000回 電源をぶちぎってみる

まずRPiで最も多い故障箇所はSDカードでその故障の原因が電源ぶつぎりです。これは経験とかではなくググったら出てくる話しなのでこれはどうにかしておかないとまずいです。

電源をぶちぎってダメになる原因の一つは、OSがSDカードへなんらかデータを書き込んでいるときに電源が切れると次回起動時に読み出せなくなることのようです。

ただユーザにそういうことを説明して「シャットダウンしてから電源を抜いてください」と言っても毎回そうしてもらうことを期待することはできません。なので、めんどくさいですが作り手としては「電源をぶちぎっても大丈夫な状態にしておく」ことを目指すことになります。

ということで、10,000回くらいRPiの電源をぶち切ってみて大丈夫かどうか確認します。

これは、電源コードの5V +側を切って間にリレーをかませばできそうですね。
ということでリレー基板を買ってきてRPiで制御して何度も電源をON/OFFさせます。

https://jp.sainsmart.com/products/16-channel-12v-relay-module

後のUSBとか有線LANのテストでも使い回せるようにチャネル数多いのが良いです。
RPiは5V 4Aくらいの電源ですが、このリレーは30V 12Aまで耐えれるので大丈夫そうです。
回路は適当につくってください。

RPiでリレーのようなハードウェアの制御したりテスト結果をログするのにボクは Node.js をよく使います。Node.jsを使えるようになると格段に開発スピードがあがるので、組込みCだけで開発している人にとっては明確に使い分けができる良い言語だと思います。いい意味でも悪い意味でも衝撃的なことがたくさんあって人によっては受け入れがたいと思う部分もあるかと思いますが。。。トータルで見てjsは習得して良いことしかないです。

さて話しを戻して。。。何も対策せずに電源ぶちぎりテストしてみると20-30回くらいでRPiのOSがカーネルパニックを起こして起動しなくなることがわかります。
20-30回というのは平均で、最低回数2回とかはありました。

なのでやはりSDカード問題の対策をする必要がありファイルシステムのRAM化が手っ取り早いです。
そのあたりこのツイートで大体わかると思います。

https://twitter.com/ksksue/status/1082558177898520577

・ ファイルシステムのRAM化
・ OSシャットダウン猶予を与えるような回路にする

こういう対策をすると10,000回電源ぶちぎっても大丈夫ということがわかってきます。

10,000回 USBをぶちぎってみる

たとえばユーザがUSBメモリを使うと想定される場合には、何回抜き差ししてもちゃんとファイルが読み出せるのか?という点は気になりますよね。
なのでこの確認もめんどくさいんですが10,000回くらいやります。

電源ぶちぎりテストと同じようにUSBケーブルぶった切ってリレーかましてRPiでNode.jsで制御すればいっちょあがりです。

ただ リレーって切り替え音がカッチカッチ結構うるさい んですよね。なんで趣味でフォトカプ使ってUSBの接続/切断できる基板つくったりしてました。


https://github.com/ksksue/usb-switcher

USBメモリを切断→接続→USBメモリの中身を読出しdiffを取る、という一連の作業をNode.jsなんかを使うと2-3時間くらいで作れるので、3日放置しておけば10,000回くらいになってエラー率がでます。ボクがやったテストではエラー率はゼロでした。

ちなみに物理的な挿抜で壊れる場合のテストは難しいので諦めてます。後に書きますが、交換するしかない場合は交換することが健全だと思います。このテストで重要なのは物理的な挿抜以外で故障が発生しうる確率を出すことです。

10,000回 有線LANをぶちぎってみる

ユーザが有線LANをつかう場合にはやはりLANを抜き差しして問題が〜。。。という話しの流れはそろそろいいですかね。

まぁリレーを使った接続/切断はUSBの要領と同じなので省きますが、導通確認は ping 8.8.8.8 とかで確認でOKとしてました。スループットはかりたい場合はサーバー役のRPiをもう一台用意して iperf3 とか使うとよいです。

10,000回 Wifiをぶちぎってみる

有線LANと要領は同じです。Wifiは sudo ifconfig wlan0 down コマンドで切って、 sudo ifconfig wlan0 up で有効にできます。
このテストはシェルで完結するんでシェルでサクッとつくってもいいんですが、テスト結果集計しやすかったりするのでやっぱり Node.js で書いてました。

10,000回 Bluetooth Low Energyをぶちぎってみる

Node.jsで使える noble/bleno を使ってRPi 2台でセントラルとペリフェラルを立ててconnect/disconnectを繰り返すテストをしました。

静電気にはめっぽう弱い

RPiは静電気には弱いです。そもそも静電気対策されてないので当たり前といえば当たり前ですが、意外とここちゃんと確認してない人多い気します。産技研なんかで1時間700円くらいで静電気ガンを貸してくれるので行ってバチバチやってみればOKです。

東京都立産業技術研究センター 静電気障害試験器

https://www.iri-tokyo.jp/setsubi/ev34.html

静電気試験 IEC61000-4-2 で定められているレベル3(接触 6kV 気中 8kV)は数回耐えれたとしても市場ではバンバン静電気で壊れるんで、レベル4(接触8kV 気中15kV)を何回かやっても大丈夫なくらいは確認したほうがいいです。
ちなみに裸のRPiに気中8kVは即死です。ケースで絶縁距離とるか、IOあるなら拡張基板にTVSとか載せて対策しましょう。

あと雷サージも気にはなっているのですが市販の雷サージタップを信頼して試験まではしてません。このあたりやったことある人は肌感教えてもらいたいです。

普段から高温・低温状態でテストする

高温・低温環境でのテストをするのに恒温槽という装置があります。恒温槽は10万〜30万くらいの高価なものなのでこれも産技研で借りれるんですが、日をまたいで借りることはできないので放置しておくことができません。

最終的な試験では恒温槽で試験することは当然なんですが、普段使いのものとして1−2万円くらいの温冷庫を使うと高温・低温時のエラーが顕在化しやすくなります。ボクの使っている安い温冷庫は-5℃〜60℃弱くらいまでしかなりませんが 基本的に放置してエラーが出るラクな方法と考えていくとこうなりました。安いので並列化しやすいのも良いです。

上記10,000回テスト装置をポーンと入れておいて、あとは10,000回まで放置です。

SDカードはindustrialを使う

ファイルシステムをRAM化したとしてもSDカードそのものの物理的耐久性(連続稼働、耐温度)が高いという理由でSDカードは工業用にするのがいいです。
Western Digital(最近SanDiskはWDに買収されたのでWDパッケージの方が新しい),Transendあたりが出してます。Amazonとかで見ると3000円越えてますが、代理店とおせばそれなりにさがるのと、市場でも2000円切るものは見つけられます。

個体差をやっつける

個体差はたまに出てくるので数十台くらいなら手元で個体差確認できる環境準備するか、数百台以上くらい出荷するとわかってるなら製造ライン設計するのが良いと思います。

平均値から外れたらはじくルールで
USBなら大きめのファイルを読み書きして何秒で読み書きできるかチェック
有線LAN/Wifiなら iperf3 でネットワークスループット計測チェック
Bluetooth は noble/bleno でスループット計測チェック
このあたりも RPi & Node.js でサクッと作れます。

製造ラインでもRPiは大活躍します。RPiは安いので並列化して製造ラインのスループット上げれるのが強いです。

宇宙線は諦める

宇宙線は諦めてます。以上

最悪交換しても安い

まぁ最悪壊れたら交換すればいいじゃん、というのが健康的な考え方で良いと思います。
RPiの最大の利点はそこで、安くてすぐ替えがきく点だと思います。

幸いRPiは本体とSDカードがあれば元通りになるので、SDカードの内容を dd で吸い出しておけばいつでも復活できます。

逆に言うとこの利点を活かすために大事なデータをローカル保存しておくのは得策じゃないのでクラウドに投げる仕様にしておくのが良いと思います。

テストをやっていくと見えてくること

わりとパターン化するとさほど労力をかけなくてもテストできることがわかってくるので、それなら10,000回くらいはテストやっておくか、という感覚になると思います。ハードウェアの信頼性が増し、結果自分のエンジニアとしての信頼性も上がるので一石二鳥です。

またチームにとっても良く、「ここRPiが原因なんじゃないの?」という人に「そこ10,000回くらいテストしてみたんですけど異常でなかったんですよね〜」というと大体は他の原因を探す動きになるので早期解決に繋がりやすいです。

あと「なにもないかもしれないのに、なんでそんなに繰り返しテストするの?」という指摘がたまにあります。
これはソフトウェアテストとハードウェアテストの根本的な考え方の違いに起因するのかなと思っています。

ソフトウェアテストでは主に網羅的な機能チェックつまりカバレッジが重視される傾向にあると思います。わかりやすく言えば、デプロイ前に網羅的に1回テストパスすれば良い、というのがソフトウェアテスト的な考え方です。

一方で、ハードウェアはわずかな環境によって結果が違ってきたりするので、例えば「USBメモリが10回に1回くらい認識されないんだよね」みたいなことが出てきます。USBメモリならユーザが目の前いるので抜き差ししてもらえば良いですが、これがどこかに組み込まれてしかも1000台出荷して毎日100台が不具合を起こすシステムと聞くとだいぶまずいですよね。

この故障率が10回に1回なのか、100回に1回なのか、10,000回に1回なのかがわからないというのがハードウェアテストの考え方のベースにあります。つまり、ハードウェアテストとは故障率を明らかにすることだといえます。

さいごに

ただどこまでやってもボクはRPiは壊れないとは断言できません。RPiが物質である以上なんらかの原因で壊れることは確かです。ここでは想定していない環境では壊れやすいかもしれません。エンジニアとしてできるのは、壊れる原因を特定して、壊れる確率を下げて、それを継続的にやっていくことしかできないと思っています。

タイトル「Raspberry Piは本当に壊れやすいのか」 はそれぞれの環境によってかわってくるのでボクは壊れやすいとも言えるし壊れにくいとも言えると思っています。

エンジニアがはっきりYes/Noと答えずに嫌われる所以ですね。

この記事に贈られたバッジ