【ITニュース解説】The ten-year battery that would not make five

ニュース記事のタイトルにあるように、10年間のバッテリー寿命を目指して設計された機器が、実際には5年も持たなかったという問題は、組み込みシステム開発において非常に重要な教訓を含んでいる。特にシステムエンジニアを目指す初心者にとって、理論上の設計と実際の運用との間に生じるギャップを理解することは、信頼性の高い製品を作る上で不可欠な知識だ。

今回の事例は、自動的にデータを収集する水道メーターに関するものだ。一度設置されると、その後は誰も手を加えることがないため、内蔵されたバッテリーが製品寿命を決定する。もしバッテリーが早期に尽きてしまえば、ソフトウェアのアップデートでは解決できず、全てのメーターに作業員が出向いて交換する必要が生じる。これは、膨大なコストと手間がかかる事態だ。この水道メーターは、超音波で水を測定し、1日に少なくとも4回データを報告する仕様で、LoRaWAN版とGPRS版の二種類が開発された。電源には、約19アンペア時の容量を持つ単一のDサイズリチウム塩化チオニル電池が使われている。

当初の設計では、19アンペア時の容量があれば10年間持つと見積もられていた。単純に計算すると、19,000ミリアンペア時を10年（87,660時間）で割ると、平均して1時間あたり約217マイクロアンペアを消費できることになる。これは、1日あたりに換算すると5.2ミリアンペア時だ。この平均値が重要で、メーターはほとんどの時間、微小な電流しか消費しない「スリープ」状態にあり、1日に数秒だけ数百ミリアンペアを消費する「稼働」状態になる。バッテリーの予算は、これらの各状態がどれくらいの電流をどれくらいの時間消費し、1日に何回発生するかという要素を積み重ねて計算される。

GPRS版の設計において、当初のスプレッドシートでは、以下のような仮定で計算が行われた。まず、ほとんどの時間を占める「スリープ」状態では8マイクロアンペアを消費し、1日あたり0.19ミリアンペア時。次に、「測定」は2秒ごとに1回超音波を発するとして、1日あたり0.14ミリアンペア時。そして、「無線通信（レポート）」は1回15秒で200ミリアンペアを消費する通信を1日4回行うとして、1日あたり3.33ミリアンペア時。さらに、「バルブ操作」は週に一度の頻度で0.04ミリアンペア時と見積もられた。これらの合計は、1日あたり平均154マイクロアンペア、総消費量は3.71ミリアンペア時となった。19アンペア時のバッテリー容量があれば、この計算では14年間持つことになり、目標の10年に対して4年もの余裕があると判断され、設計は承認された。この時点では、消費電力の約9割が無線通信に費やされており、本来の目的である測定はほとんど電力を使わないことがわかる。

しかし、実際にプロトタイプを製作し、研究所で測定したところ、GPRS版は5年すら持たないことが判明した。なぜこのような大きなギャップが生じたのか。その原因は、スプレッドシートに記載されていなかった要素や、最適な条件を前提とした仮定にあった。

まず、「スリープ」時の消費電流は、マイクロコントローラ単体のデータシート値だけでは不十分だった。メーターはマイクロコントローラだけでなく、電圧を調整するレギュレータ、完全にオフではないモデム、プルアップ抵抗、待機状態の測定回路など、様々な部品で構成されている。これら全体で考えると、スリープ電流は8マイクロアンペアどころか25マイクロアンペアにも容易に達する。一見小さな差に見えるが、これが1日24時間、10年間続き、年間で考えると無視できない大きな差となる。

次に、最も大きな影響を与えたのは「無線通信」だ。設計時の仮定はオフィス環境での測定値だったが、実際のメーターは地下のピット内や金属の蓋の下など、電波状況の悪い場所に設置される。このような環境では、携帯電話ネットワークに接続するのに時間がかかったり、通信そのものが失敗したりする。オフィスで15秒かかったレポートが、現場では30秒かかることも珍しくない。さらに、時には1分間かけても通信に失敗し、成功した時と同じくらいの電力を消費しながらも何も情報を送れない、といった事態も発生する。これにより、無線通信にかかる電力は設計値を大きく上回る。

また、「バッテリーそのものの特性」も考慮されていなかった。リチウム塩化チオニル電池は、使用していなくても年間約1%の自己放電がある。高温環境ではさらにその割合は増える。19アンペア時のバッテリーであれば、年間190ミリアンペア時、これは常に約22マイクロアンペアの電流が流れているのと同じ状態だ。これは総予算の1割にも相当するが、どの回路も直接消費するわけではないため、スプレッドシートには計上されていなかった。

さらに、バッテリーの「公称容量」も問題だった。19アンペア時という容量は、低い定常電流で室温環境で測定された値だ。しかし、携帯電話モデムは最大2アンペアもの電流をパルス的に要求することがあり、このような種類のバッテリー単独では供給しきれない。そのため、ピーク電流を吸収するためのコンデンサと組み合わせて使用されることが多い。加えて、数週間休止状態にあったバッテリーは、最初の高電流パルスに対して応答が遅れることがある。また、ピット内の高温はバッテリーの劣化を早める。結果として、公称容量の80%が実際に利用できれば楽観的だと言える状況だった。

一方で、「バルブ操作」は一時的に大きな電流を消費するが、週に一度という頻度の低さから、全体に占める消費電力の割合は1%にも満たず、想定よりも重要度は低かった。消費電力が大きくても、発生頻度が低ければ全体への影響は小さいという良い例だ。

これらの現実的な条件を反映してスプレッドシートを修正すると、結果は劇的に変化する。スリープ電流は25マイクロアンペアで1日あたり0.60ミリアンペア時。測定は変わらず0.14ミリアンペア時。無線通信は、1回30秒で220ミリアンペアを消費するレポートを1日4回、さらに2日に1回は1分間の通信失敗を考慮に入れると、1日あたり9.17ミリアンペア時。バルブ操作は0.04ミリアンペア時。そして、自己放電による損失が年間1%で1日あたり0.52ミリアンペア時。これらを合計すると、1日あたり平均436マイクロアンペア、総消費量は10.47ミリアンペア時となる。さらに、バッテリーの利用可能容量を公称値の80%と考えると、このメーターの寿命はわずか4年という計算になる。最初の見積もりでは14年だったものが、現実の条件を考慮すると4年になってしまうという、非常に大きな乖離だ。

この大きなギャップのほとんどは、無線通信の項目に集中していた。GPRSでのレポート1回あたりのコストは、現場では約1.8ミリアンペア時にもなる。1日のバッテリー予算が5.2ミリアンペア時であるのに対し、GPRSで1日4回のレポートを行うだけで、すでに予算オーバーしてしまう。現場での実測値から逆算すると、10年間の寿命を達成するためには、1日1回のレポートしか許されない計算になる。ここから導き出される重要な結論は、GPRSを使用する場合、1日あたりのレポート回数は単なる設定値ではなく、バッテリー予算に基づいて行われる「設計上の決定」であるということだ。クライアントの要望だけで決めるべきではない。

一方、LoRaWAN版では計算が大きく異なる。LoRaWANメッセージはGPRSレポートと比較して約100分の1のエネルギーで済むため、無線通信がバッテリー寿命の支配的な問題ではなくなる。しかし、エラーがなくなるわけではない。無線通信のコストが低い場合、今度はスリープ電流や自己放電といった、当初スプレッドシートで見落とされていたり過小評価されていたりした項目が、全体に占める割合として大きくなるのだ。

この事例から、システムエンジニアを目指す初心者が学ぶべきことは多い。設計の初期段階から行うべきことは以下の通りだ。まず、「データシート値」の隣に「実測値」の列を設けること。バッテリー予算は、マイクロコントローラ単体ではなく、デバイス全体のプロトタイプで各行の実測値が揃うまで承認しない、というルールを作るべきだ。

次に、「無線通信は、実際の設置場所で測定する」こと。メーターが置かれるピット内、蓋を閉めた状態、展開される地域で最も電波状況の悪い場所で測定を行う。通信に失敗したケースも、それらを個別の消費電力として予算に計上するべきだ。研究所でのプロジェクションでもすでに不十分だったのだから、現場ではさらに悪化する可能性を常に考慮する。

さらに、「回路が直接消費しない損失を明記する」こと。バッテリーの自己放電、利用可能な実効容量、温度による影響など、スプレッドシートにこれらの項目がない場合、予算は実態と乖離するリスクがある。

そして、「バッテリー予算に基づいてレポート頻度を決定する」こと。メーターは頻繁に測定し、そのデータを蓄積し、複数の測定値をまとめて一つのメッセージで送信することで、通信回数を減らす工夫ができる。GPRSレポートを1回減らすだけで、バッテリー寿命を何日も延ばせる場合があることを理解する。

最後に、「実際のデータが得られたら予測をやり直す」こと。製品の最初の数ヶ月間のパイロット運用で、各メーターが実際にどれくらいの電力を消費しているかを測定する。問題を発見した際、数千台の機器が設置された後で対処するよりも、初期段階で発見・修正する方がはるかにコストと手間を削減できる。

今回のスプレッドシートは、決して手抜きで作成されたものではない。測定前の段階で知り得る情報に基づいて、合理的に作成されたものだ。しかし、10年間のバッテリー寿命を目標とするような長期運用システムは、単に机上の情報だけで設計できるものではない。理論上のデータだけでなく、実際の環境と運用を深く考慮し、プロトタイプの実測に基づいて設計を進めることこそが、システムエンジニアとして信頼性の高い製品を世に送り出す上で不可欠な役割である。