アカウント名:
パスワード:
まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすいもっと頻繁にロールオーバーする設計にすれば、すぐに欠点が見つかり修正される数か月に一度ロールオーバーするように設計するとか、そもそも週データを持たずに毎週ロールオーバーする設計にするとかで
>まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすい
GPS 衛星が放送している時刻情報「週番号」は、そのサイズが 10BIT、すなわち 0 から 1023 の範囲で出力されており、1024 週の次は 0 に戻ることが GPS 衛星の仕様として一般に知られています。
1024週目 ~ 約19年半で必ずロールオーバーする仕様を「まれ」なことにしちゃいますか。まぁ、数年で壊れて使われなくなる前提の製品設計だとそれもありかもしれませんね。たまたま壊れずに使われてたら悲劇。
バグとかじゃなくて、仕様としてロールオーバー1回分にしか対応していない機器はあるよ。というか、組み込みでファームアップデート無しなら、むしろそっちが普通なくらい。20世紀の頃に年を2桁で現して 80-99 なら 1900年代、00-79 なら2000年代とかやってたのと同じ感覚で週番号から年を推測する仕様。
前回のロールオーバー後の 15〜19年前くらいに設計された機器なら仕様としてロールオーバーそのものに対応していない可能性はおおいにある。
そもそも、「GPSからの情報だけを元にした」場合、一周分を超えた週番号のロールオーバー判定は原理的には対応できないよね。簡単に言えば「時分秒だけ表示される時計を見て、日付も特定せよ」みたいな問題なわけで、別途「不揮発メモリを使ってロールオーバー回数を記録する」とか「年月日情報を別ルートから仕入れる」といった補完方法を用意しないと無理。
…と、ここまで書いたところで、ちょっとググったら、GPSからの情報だけでも・閏秒情報を見る(GPS時刻は閏秒がなくUTCとはずれているので、別途UTCとのズレも送信されている)・衛星番号を見る(衛星の寿命は20年もないから、衛星番号からどのサイクルか判定できる)などといったアドホックなロールオーバー判定方法があるにはあるみたいです。でも、過去のデータからのサイクル判定はともかく、20年後の未来のサイクル判定に使うにはちょっと不確実過ぎて当てにするのは無謀そう。
まぁロールオーバー回数ならめったに変化せずどこまで高寿命でも大した状態数は要らないので、古の物理的に焼き切るヒューズビットみたいなのでも問題なく記録できそう。
ヒューズビットまでいくと不揮発メモリ呼びして良いのだろうか……
ロールオーバーを判定するためには「前回よりも週数が減っている」ことの検出が必要なので、「最後に測位した時の週数」も不揮発記憶する必要があるかと。
ずっと電源オフで20年ぶりに電源オンとかされたら、もうどうしようもない。
ドライブレコーダーなんて録画をロールオーバーしない製品の方が多いしな断片化対応はけっこう面倒
2000年問題やその後の二桁西暦保持実装を思い返せば何ら不思議ではない話だと思うのだが。その教訓を活かしてないって意味なら確かにお粗末だが、そういう実装がある事自体は当然というか、むしろ無いほうが驚くレベル。
閏年を実装していない(デジタル)時計もあるし、日本でも元号制定=「大化」前は、干支紀年法が使われていた。
# 前にも「GPSロールオーバー」騒動があった記憶があるが、あれからもう20年たったのか。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ見習い
設計が悪い (スコア:0)
まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすい
もっと頻繁にロールオーバーする設計にすれば、すぐに欠点が見つかり修正される
数か月に一度ロールオーバーするように設計するとか、そもそも週データを持たずに毎週ロールオーバーする設計にするとかで
Re:設計が悪い (スコア:1)
>まれにしかロールオーバーしないので、まれなロールオーバーの設計に不備が入りやすい
GPS 衛星が放送している時刻情報「週番号」は、そのサイズが 10BIT、すなわち 0 から 1023 の範囲で出力されて
おり、1024 週の次は 0 に戻ることが GPS 衛星の仕様として一般に知られています。
1024週目 ~ 約19年半で必ずロールオーバーする仕様を「まれ」なことにしちゃいますか。
まぁ、数年で壊れて使われなくなる前提の製品設計だとそれもありかもしれませんね。
たまたま壊れずに使われてたら悲劇。
Re: (スコア:0)
バグとかじゃなくて、仕様としてロールオーバー1回分にしか対応していない機器はあるよ。
というか、組み込みでファームアップデート無しなら、むしろそっちが普通なくらい。
20世紀の頃に年を2桁で現して 80-99 なら 1900年代、00-79 なら2000年代とかやってたのと同じ感覚で週番号から年を推測する仕様。
前回のロールオーバー後の 15〜19年前くらいに設計された機器なら仕様としてロールオーバーそのものに対応していない可能性はおおいにある。
Re:設計が悪い (スコア:2)
そもそも、「GPSからの情報だけを元にした」場合、一周分を超えた週番号のロールオーバー判定は原理的には対応できないよね。
簡単に言えば「時分秒だけ表示される時計を見て、日付も特定せよ」みたいな問題なわけで、別途
「不揮発メモリを使ってロールオーバー回数を記録する」とか「年月日情報を別ルートから仕入れる」といった補完方法を用意しないと無理。
…と、ここまで書いたところで、ちょっとググったら、GPSからの情報だけでも
・閏秒情報を見る(GPS時刻は閏秒がなくUTCとはずれているので、別途UTCとのズレも送信されている)
・衛星番号を見る(衛星の寿命は20年もないから、衛星番号からどのサイクルか判定できる)
などといったアドホックなロールオーバー判定方法があるにはあるみたいです。
でも、過去のデータからのサイクル判定はともかく、20年後の未来のサイクル判定に使うにはちょっと不確実過ぎて当てにするのは無謀そう。
Re: (スコア:0)
まぁロールオーバー回数ならめったに変化せずどこまで高寿命でも大した状態数は要らないので、
古の物理的に焼き切るヒューズビットみたいなのでも問題なく記録できそう。
ヒューズビットまでいくと不揮発メモリ呼びして良いのだろうか……
Re: (スコア:0)
ロールオーバーを判定するためには「前回よりも週数が減っている」ことの検出が必要なので、「最後に測位した時の週数」も不揮発記憶する必要があるかと。
ずっと電源オフで20年ぶりに電源オンとかされたら、もうどうしようもない。
Re: (スコア:0)
ドライブレコーダーなんて録画をロールオーバーしない製品の方が多いしな
断片化対応はけっこう面倒
Re: (スコア:0)
2000年問題やその後の二桁西暦保持実装を思い返せば何ら不思議ではない話だと思うのだが。
その教訓を活かしてないって意味なら確かにお粗末だが、
そういう実装がある事自体は当然というか、むしろ無いほうが驚くレベル。
Re: (スコア:0)
閏年を実装していない(デジタル)時計もあるし、日本でも元号制定=「大化」前は、干支紀年法が使われていた。
# 前にも「GPSロールオーバー」騒動があった記憶があるが、あれからもう20年たったのか。