「リアルタイムクロック」の版間の差分
m Botによる: {{Normdaten}}を追加 |
m Bot作業依頼: Apple関連記事の改名に伴うリンク修正依頼 (Apple|Apple) - log |
||
40行目: | 40行目: | ||
}}</ref>。一方、[[Windows NT系]]OSでは既定値としてRTCはローカルタイムとして扱う<ref group="注">UTCにも変更可能である。</ref>。このため両OSを[[マルチブート]]できるシステムにおいて、仮にUnix系OSでRTCのタイムゾーンをUTCと設定しておくと、両者の切替の際に齟齬が生じ、RTCの内容に信頼がおけなくなる。この問題に対して、Windows NT系ではUTCを使うという対策がある。しかし、時刻が直感的に判り難く、またローカルタイムの概念を持たないアプリケーションでは[[タイムスタンプ]]がUTCをローカルタイムとみなして保存するので都合が悪くなる。<!--Unix系OSの一部では、RCのシャットダウンシーケンスの一部でUTCをローカルタイムに直してリアルタイムクロックに書き込み、Windowsを起動しても時計が狂わない様にした物もある(あまり良いアプローチではないので評判は芳しくない)。-->もしくはUnix系OS側のタイムゾーンをローカルタイムにすれば良い。 |
}}</ref>。一方、[[Windows NT系]]OSでは既定値としてRTCはローカルタイムとして扱う<ref group="注">UTCにも変更可能である。</ref>。このため両OSを[[マルチブート]]できるシステムにおいて、仮にUnix系OSでRTCのタイムゾーンをUTCと設定しておくと、両者の切替の際に齟齬が生じ、RTCの内容に信頼がおけなくなる。この問題に対して、Windows NT系ではUTCを使うという対策がある。しかし、時刻が直感的に判り難く、またローカルタイムの概念を持たないアプリケーションでは[[タイムスタンプ]]がUTCをローカルタイムとみなして保存するので都合が悪くなる。<!--Unix系OSの一部では、RCのシャットダウンシーケンスの一部でUTCをローカルタイムに直してリアルタイムクロックに書き込み、Windowsを起動しても時計が狂わない様にした物もある(あまり良いアプローチではないので評判は芳しくない)。-->もしくはUnix系OS側のタイムゾーンをローカルタイムにすれば良い。 |
||
いずれの場合も、時刻源にRTCを使わず、NTPなど外部の時刻源に同期する様に設定するとほぼ問題無く時刻を参照できる(ただし[[macOS|Mac OS X]] v10.4.xは時計が戻されるとFinderの動作がおかしくなるバグがある。[[ |
いずれの場合も、時刻源にRTCを使わず、NTPなど外部の時刻源に同期する様に設定するとほぼ問題無く時刻を参照できる(ただし[[macOS|Mac OS X]] v10.4.xは時計が戻されるとFinderの動作がおかしくなるバグがある。[[Apple]]はMac OS X v10.5へのアップグレードを推奨している)。 |
||
== その他の利用 == |
== その他の利用 == |
2021年5月20日 (木) 11:18時点における版
リアルタイムクロック(real-time clock、RTCと略記[注 1])は、コンピュータなどが内蔵する時計や、その機能が実装されている集積回路(IC)のことを指す。リアルタイムクロックはシステムの電源が切られていてもバッテリバックアップなどにより「時刻」を刻み続けることが特徴である。これに対し、オペレーティングシステムが持つ時刻機能(以下システム時刻)はタイマーにより「時間」を測定しそれを積算するもので、分解能はリアルタイムクロックに勝るが、シャットダウンすると時刻情報が失われ、次にシステムを起動したときにRTCを参照して設定する必要がある。
MS-DOSのように自身では時間をカウントせず、時刻を必要とする時は常にRTCを参照するようなシステムもある。[要出典]
概要
RTC機能を持つICは多くのコンピュータシステムで使われており、現在のパーソナルコンピュータや情報家電にはほぼ必ず組み込まれている。オペレーティングシステムによっては、システム時刻に対してハードウェアクロックと呼ぶことがある。また、組み込みシステムの分野では、RTCのことをカレンダークロックと呼ぶこともある。
RTCは、システム本体の電源から独立したバッテリー(ボタン型電池や、電気二重層コンデンサなど)から電力を得られる様にして、システムがシャットダウンしている時でも計時機能を維持する設計とすることが多い(バッテリーバックアップ)。ただし、システムが無停電電源装置などによって停電保障されている場合は、システム本体と同じ電源でRTCを駆動するような設計が行われることもある。また、一次バッテリーをバックアップに用いる場合、消耗を押さえるために、商用電源が断たれた場合のみバッテリー駆動に切り替える設計も行われる。
RTCは、コンピュータの、CPUや他の周辺機器(CPUクロックやシステムクロック)とは別のクロックジェネレータ(通常32768Hz=2^15Hzなど、分周器によって1Hzを作り易い周波数のもので、主に時計用などとして生産・流通しているもの)で動作させることが多い。
典型的なRTCは「年」、「月」、「日」、「時」、「分」、「秒」をそれぞれBCDで保持し、1秒ごとに日時を更新し、機種によっては「曜日」も提供する。PC用のRTCでは8ビット幅のデータバスを持ち、これをCPUのデータバスに接続してIOポートとして扱うが、SPIやI2Cなどのシリアルインターフェースで接続するものもある。初期のRTCではμPD1990のように、西暦年の4桁のうち、1の位と10の位の、下位2桁のみをBCDで保持するものもあった[注 2]。そのような場合、OS側で上位2桁を補う必要があり、2000年問題に通じる問題を持つ。システムが開発された時期に応じて、MS-DOS関係では、1980年を基準として、80以上99以下なら1900年代、00以上79以下ならば2000年代として扱う処理となっていたりするものが多い。
コンピュータでの実際の利用
一般にRTCへの書き込み(つまり時刻あわせ)はコンピュータから見て非常に時間がかかる。そのためネットワーク上で時刻同期するような場合でも、頻繁にRTCへ書き込まないような考慮をオペレーティングシステムが行っている。
現在のOSは起動時にRTCを読み取って、別に用意された高精度(イベント)タイマーの日時と精度を校正し、以後RTCから時刻を読み出すのではなく、高精度タイマーのカウンタ値によって時刻を保持している。これはRTCの時刻精度がおよそミリ秒が限度なのに対して、高精度タイマーはナノ秒からピコ秒の精度をもっており、より正確な時刻管理が出来るためである。特にこのような精密な時刻管理はNTPの様に「時計を正確な時刻に徐々に進める・遅らせる」といった操作には必要不可欠である[注 3]。
タイムゾーン
PCなど多くの場合、RTCはタイムゾーンを扱う機能を持たず、読み出した日時がどのタイムゾーンの時刻であるかを直接知る術はない[1]。OSはブート時にRTCを参照してシステム時刻を同期させるが、両者がそれぞれどのタイムゾーンであるかを把握しておかないと齟齬が生じる。OSのインストーラではRTCが保持している日時がUTCであるかローカルタイムであるか、またローカルタイムであるならどのタイムゾーン(例JST)であるか、をユーザーに質問する。このためユーザーはインストール前に何らかの方法でRTCの保持する時刻のタイムゾーンを調べなければならない。概ねBIOSのI/O コントローラー・ハブ(ICH)の設定にRTCの時刻が表示されるので、これでRTCがUTCかローカルタイムであるかを把握できる。或いはBIOSの時刻設定機能を用いて、予めRTCをUTCないしローカルタイムに合わせておいてからOSのインストーラを起動してもよい。インストーラで設定されたRTCのタイムゾーン情報はOS・システム時刻のタイムゾーン情報(Unix系OSではいわゆるtz database)とは別個に保持される。Unix系OSでは前者は/etc/adjtime、後者は/etc/localtimeという別々の設定ファイルに分けて記録されている。この後、OSブートの度にRTCを読み出しシステム時刻がこれと同期される。Unix系OSではその際/etc/adjtimeファイルを参照してRTCが何のタイムゾーンであるかを判断した上で同期する[注 4]。逆にシャットダウン時はタイムゾーンを考慮しつつシステム時刻をRTCに書き込む[2]。一方、Windows NT系OSでは既定値としてRTCはローカルタイムとして扱う[注 5]。このため両OSをマルチブートできるシステムにおいて、仮にUnix系OSでRTCのタイムゾーンをUTCと設定しておくと、両者の切替の際に齟齬が生じ、RTCの内容に信頼がおけなくなる。この問題に対して、Windows NT系ではUTCを使うという対策がある。しかし、時刻が直感的に判り難く、またローカルタイムの概念を持たないアプリケーションではタイムスタンプがUTCをローカルタイムとみなして保存するので都合が悪くなる。もしくはUnix系OS側のタイムゾーンをローカルタイムにすれば良い。
いずれの場合も、時刻源にRTCを使わず、NTPなど外部の時刻源に同期する様に設定するとほぼ問題無く時刻を参照できる(ただしMac OS X v10.4.xは時計が戻されるとFinderの動作がおかしくなるバグがある。AppleはMac OS X v10.5へのアップグレードを推奨している)。
その他の利用
パチンコ業界においては、筐体にリアルタイムクロックを組み込み、時間に合わせて演出を作動させるという「RTC機能」の導入が進んでいる。
この機能は、2007年にSANKYOが「CRフィーバー007」において初導入したもので、曜日や時刻によって違った演出が出せるようにしたものである(出玉に関する機能には一切影響しない)[3]。
RTC機能が広く認知されるようになったきっかけとなった機種が2012年に発売された「CRぱちんこAKB48」(京楽産業.)で、1時間に1回すべての機体が一斉に「重力シンパシー公演」という特別演出を繰り出すというものである。当時AKB48は人気の絶頂期にあり、また機体発表から数週間は毎週新しいオリジナル楽曲が演出に登場するということもあって、同機はパチンコファンのみならずAKB48ファンにも高い注目を浴び、販売初年度の総販売数20万台以上、総売上げ約800億円という好成績を残した。この成功を受け、SANYOは「CRスーパー海物語IN沖縄3」でシリーズ初となるRTC機能「スペシャル魚群タイム」を搭載、Sammyも「ぱちんこCR北斗の拳5 覇者」においてシリーズ初搭載など、業界各社も実機へのRTC機能標準搭載に動いている。
この他、一部のゲームハード、ゲームソフトにもリアルタイムクロックが組み込まれていることがあり、主にRPGで時間によって変わるイベントが発生したり、日替わりのイベントが発生したりする物があり、『天外魔境ZERO』などのハドソンのゲームソフトではPLGS(Personal Live Game System、パーソナル・ライブ・ゲーム・システム)と称される。かつてはゲームカートリッジの中にリアルタイムクロックを実現するチップと、それを駆動するバッテリーによって構成されている事が多かったが、ソフトのコストの面や、バッテリー切れになった時にリアルタイムクロックが停止することで、ゲームが正常にプレイできなくなる、イベントが制限される、更にはセーブにSRAMを使っている物はSRAMとリアルタイムクロックチップの両方に電力を食われる事でバッテリーの消耗が早く、セーブデータその物が早期で消えてしまうといったデメリットがあった。 しかしながら21世紀に入ってから発売されたほぼ全てのゲーム機には、据え置き機・携帯機問わずハード側に時計機能としてリアルタイムクロックが搭載されているため、ソフト側にリアルタイムクロックが搭載されることは殆どなくなったことで、この様な問題は収束することとなった。
脚注
注釈
出典
- ^ 大竹龍史 (2008年12月26日). “暗記に頼らずちゃんと理解 実践でも役立つLPICドリル - 第8回 Linux時刻管理の仕組みと設定”. アットマーク・アイティ. jibun.atmarkit.co.jp. pp. 1. 2011年8月12日閲覧。 “ハードウェアクロック自体にはUTCかローカルタイムかの情報を保持する領域はありません。”
- ^ 大竹龍史 (2008年12月26日). “暗記に頼らずちゃんと理解 実践でも役立つLPICドリル - 第8回 Linux時刻管理の仕組みと設定”. アットマーク・アイティ. jibun.atmarkit.co.jp. pp. 2. 2011年8月12日閲覧。
- ^ CRフィーバー007