RTCと時刻管理の設計
組み込み機器のログに記された時刻がずれてしまい原因の解析に支障が生じる、年をまたぐ時期や将来の日付を入力する際に異常が起こるといった事象に遭遇したことはないでしょうか。こうしたトラブルの多くは、RTC（Real Time Clock）設計を最初に固めることで防ぎやすくなります。この記事では以下の4点を扱います。①RTCの構成選択、②暦計算の落とし穴、③時刻合わせとドリフト補正、④タイムスタンプ運用と2038年問題への備え。順にRTC設計の勘所を整理します。
組み込み機器におけるRTCの役割と構成の選択
RTC（Real Time Clock）は、機器の主電源がオフの状態でも時刻を保持し続ける機能です。ログの記録、スケジュールの制御、データ整合性の実現に重要な役割を果たします。構成と時刻表現の方法をプロジェクトの初期段階で決めなければ、後工程で問題が発生し、大規模な修正を余儀なくされるおそれがあります。
内蔵RTCと外付けRTCの違いと選定の軸
多くのマイコンに搭載されている内蔵RTCは、バックアップ電源（VBAT）と組み合わせて使います。内蔵発振器の精度は、外付け水晶発振子に劣ります。市販の温度補償型（TCXO内蔵）のRTC IC（時計用IC）には、I2C接続で、動作温度0〜40℃時に±2 ppm（月あたり約±5秒相当）、－40〜85℃時に±3.5 ppm（月あたり約±9秒相当）という仕様例があります。RTCを選ぶ際には、精度、コスト、基板面積、バックアップ電池の寿命に代表される4項目が重要です。
時刻表現の決め方（Unix time、分割レジスタ、BCD）
Unix time（Unixエポックからの経過秒）は計算しやすい一方、32 bit実装時の2038年問題を抱えます。RTC内部のBCD分割は読みやすい一方で、演算をおこなう際には暦の計算を要します。BCD分割では、年、月、日、時、分、秒が個別のフィールドとしてレジスタに格納されます。アプリケーション層ではUnix timeで保持し、表示時のみ分割形式に変換する設計をおこなうことで、演算のしやすさと読みやすさを両立できます。
暦計算で踏みやすい落とし穴
グレゴリオ暦は400年で97回のうるう年という変則ルールを持ち、自前での実装ではバグを生みやすい領域です。タイムゾーンや夏時間の扱いを誤ると、海外で使用する際に動作不良を起こすおそれがあることにも注意が必要です。
うるう年判定の例外と月末日の扱い
うるう年は「4で割り切れる年。ただし100で割り切れる年は平年。さらに400で割り切れる年はうるう年」と定義されています。直近では2024年と2028年がうるう年です。2000年もうるう年ですが、2100年は平年となります。2月29日や月末日といった条件では、オフバイワンエラー（Off-by-one error）や月末日を格納するテーブルの更新漏れが発生しやすいことに注意が必要です。
タイムゾーンと夏時間の変換ミス
タイムゾーンをJST（Japan Standard Time：日本標準時）固定で実装すると、海外で使用する際に動作不良を起こします。tzdata（IANA Time Zone Database：タイムゾーンデータベース）を持たない組み込み環境ではUTCによる基準を用いて保持し、表示時にオフセット加算する方式が一般的です（DSTや法改正を考慮しない固定オフセット運用の場合）。DSTや法改正への追随が必要な機器では、tzdataの搭載と更新手段を検討します。夏時間（DST）の境界日では同じ時刻が2回出現する、または存在しない時刻が生じる点に注意が必要です。
標準ライブラリに任せてよい場面と自前実装が要る場面
C言語標準ライブラリのtime_t型、mktime関数、gmtime関数はホストOSと処理系で挙動が異なります。広く使われる標準Cライブラリ実装の64 bit環境では、time_tは64 bit整数として実装されており、1970年より前を含む広い範囲の時刻を扱えます。ただし32 bit環境では2038年問題が残ります。組み込みCランタイムでは、扱える年月日の範囲がさらに狭い場合があります。マイコンのSDKでは、範囲、精度、スレッド安全性をリファレンスマニュアルで確認します。
時刻合わせとドリフト補正の設計
RTCは長期間の運用により時刻のずれが蓄積し、ログに記録される時刻が実際の時刻と一致しなくなるおそれがあります。時刻を同期する手段と補正方式を設計に組み込むことで、現場での時刻ずれに起因するトラブルを大きく減らせます。なお本記事では、外部から時刻を得ることを「時刻取得」、RTCやシステムへ反映することを「時刻設定」、定期的に差分を補正して維持することを「同期」と呼び分けます。
NTPとSNTP同期、ネットワーク切断時の対策 (うるう秒対応含む)
Ethernet／Wi-Fi接続機器では、SNTP（Simple Network Time Protocol：NTPの簡易実装）で定期的にUTCを取得することが一般的です。複数サーバの指定とフェイルオーバー、パケットロスが発生した際のリトライ、起動直後の時刻補正などを設計に織り込みます。ネットワークの切断中は内蔵のRTCで運用し、復帰時に再同期します。
うるう秒は、地球の自転周期とUTCのずれを補正する目的で不定期に挿入される1秒です。NTPは、うるう秒を挿入する予告を示すLeap Indicator（LI）フラグ（RFC 5905）を定義しています。ただしLIはうるう秒挿入の予告情報であり、実際の扱いはクライアント実装により異なります。実装によっては、23:59:60を挿入するのではなく、一定時間をかけて時刻をならすleap smear方式を採る場合もあります。長期間にわたり運用を継続する機器では、採用するNTPクライアントのうるう秒挿入時の挙動を検証しておきましょう。
水晶発振子のドリフトとRTC補償レジスタの活用
32.768 kHzの水晶発振子は温度により発振周波数が変動する特性があります。温度補償が無い状態では、月数秒から数分ずれます。一部のマイコンでは、補償レジスタを用いて分解能約1 ppm、範囲±490 ppm程度の補正ができます（採用するマイコンのリファレンスマニュアル参照）。別のマイコンでは符号付きキャリブレーションレジスタで最大±260 ppmの補正が可能な例もあります。
派生シリーズ間でレジスタ構成が異なる場合があるため、採用するマイコンのリファレンスマニュアルで対応レジスタを確認します。製造時に基準クロックと比較して個体ごとの補正値を不揮発メモリへ書き込む工夫が現場で使われます。
GPS同期とPPS（1パルス／秒）信号
屋外設置機器ではGPS受信モジュールのPPS（Pulse Per Second）出力（1 Hzのパルス信号。パルス幅はモジュールの仕様により異なる）でマイコンのタイマーを校正します。PPSの立ち上がりで秒境界を同期すると、ミリ秒（ms）の精度で時刻を保持できます。なお、GPS時刻はうるう秒を含まない連続時刻系であり、UTCとは差があります。GPSのナビゲーションメッセージにはGPS-UTCオフセットが含まれており、通常は受信モジュール側がUTC表示へ補正します。UTCでログを統一する場合は、この補正の有無をデータシートで確認します。
タイムスタンプ運用と2038年問題への備え
時刻はログ、データ、通知など、組み込み機器の活用において広く用いられています。また製品の寿命も見据えた上で、タイムスタンプの形式や2038年問題への対策を講じる必要があります。
ログ突き合わせを支えるタイムスタンプ設計
複数機器のログを後工程で突き合わせる場合、タイムスタンプの形式を検討する必要があります。UTC統一、ISO 8601拡張形式（例：2026-05-20T12:34:56.789Z）などの中から、要件にあわせて選択します。精度についても、ミリ秒（ms）の精度でよいか、マイクロ秒（μs）の精度が必要かという検討を要します。
機器IDと時刻の同期に用いた方法をログに付加すると、解析をおこなう際に精度の評価もおこなえます。時刻の同期に用いた方法には、NTP、GPS、RTC単独のいずれかを識別できる形式が望ましいです。
2038年問題とGPS週カウンターロールオーバー
2038-01-19T03:14:07Z（32 bit time_tの最大値）を最後に、次の秒で負数へ折り返します。組み込み機器を正常に稼働するためには、64 bit time_tへの対応が現実的です。GPSの場合、週番号を考慮する必要があります。レガシーなLNAV信号（L1 C/A）では10 bitのまま1024週（約19.7年）ごとにロールオーバーし、直近は2019年4月6日、次回は2038年11月20日が該当します。
CNAV信号（L2CとL5で使用、IS-GPS-200Nで定義）およびCNAV-2信号（L1Cで使用、IS-GPS-800Jで定義）では13 bit化されており、ロールオーバー周期は8192週（約157年）へ延びています。受信モジュール側でLNAVのロールオーバー補正に対応しているかをデータシートで確認します。
長寿命機器の時刻運用ガイドライン
設置寿命が10年を超える機器では、製品出荷時のRTC精度の仕様、補正手段、2038年問題への対応方針をドキュメント化しておきます。バックアップ電池の交換手順、時刻の同期が失敗した際の挙動、年またぎに関するテスト項目も保守設計の一部として整理します。
RTCの構成、暦の計算方法、時刻合わせとドリフト補正、タイムスタンプ設計、2038年問題という観点で設計をおこなうことで、現場で時刻に起因するトラブルを大幅に減らせます。
