09:30 〜 09:45
[S02-03] WINフォーマットにおけるチャンネル番号の拡張
WINシステム（卜部・束田，1992など）は地震のフェーズの検測や震源決定等の解析，大学・気象庁・防災科学技術研究所などの機関間のデータ流通に広く使われている多チャンネルの地震波形データを取り扱うための処理システムで，UNIX上で動作するプログラム群である．WINシステムではWINフォーマットと呼ばれるデータフォーマットを定義している．WINフォーマットにおいてデータの区別を16ビット長のチャンネル番号（channel ID）によって行っており，最大65536チャンネルまで扱うことが出来る．
卜部（データ流通ワークショップ，2013）で言及があった通り，JDXnetで流通しているのは10000チャンネル弱であり，85％程度は空いているが，多くが虫食い状態であり大きなブロックは残っていない．一方で，陸上や海底でのオフライン観測で得られた観測データをJDXnetの流通データと統合して解析を行ったり，複数機関でのデータ共有，高感度地震計以外の地殻変動・火山・強震等の多項目観測データを同一システムで取り扱う機会が増えており，チャンネル空間の枯渇が課題となっていた．そこで，チャンネル番号の桁数を現行の16ビット長から32ビット長へ増加することにした．
WINフォーマットは観測点での収録から，伝送流通網，収録系にまで幅広く使用されている．チャンネル空間の拡張にあたっては新しいフォーマットが必要となる．運用中の機器との互換性や，これまで収録されてきた既存データとの相互運用性を考えると，ネットワーク上やファイルシステム上で新旧両フォーマットが混在可能であることが望ましい．またソフトウェアについても両フォーマットを混在した状態を扱えることが望ましい．そこで，現行のWINフォーマットを拡張することとした．
WINフォーマットは1秒のブロックが基本単位になっている（図上段）．先頭に6バイト長の時刻情報があり，その後に複数のチャンネルブロックが連なっている．各チャンネルブロックの先頭には4バイト長のチャンネルヘッダがついており（図中段の黄色ハッチ部），その後ろにデータの本体が続く．チャンネルヘッダには2バイト長のチャンネル番号（channel ID）が含まれる（図中段赤枠）．現行フォーマットでは，チャンネル番号（channel ID）として0x0000から0xFFFFまでの値を取ることが出来る．0xFFXXのチャネル番号は32ビット拡張用として予約されていたが，それを利用することとした．即ち，先頭バイトが0xFFであったら拡張フォーマットであることを表し，更に続く2バイト目が0x00の時(図下段青枠)は，引き続く32ビット（図下段赤枠）が新たなチャンネル番号（channel ID）を示すと定義した．なお，チャンネルヘッダの先頭2バイトが0xFF01～0xFFFFの場合は現在未定義であり，将来の拡張用とすることにした．
以上，今回拡張したチャンネル番号の割り振り方をまとめると，
1．0x0000～0xFEFF (0x0000 0000～0x0000 FEFF)は新旧どちらのフォーマットでも表現出来るチャンネル．ただし，基本は16ビット長で作成．
2．0xFF00以降 (0x0000 FF00～0xFFFF FFFF)は拡張フォーマットでのみ表現できるチャンネル．
となる．なお，チャンネルヘッダには，4096Hz以上のデータを扱える高サンプリングレート等のバージョンもあるが，チャンネル番号の拡張については上で述べた方法で対応可能である．
現在，チャンネル番号32ビット拡張化については，WINシステムの基本ライブラリの対応が完了し，順次，個々のソフトウェアの対応を進めている．今後，伝送流通網や収録系のテスト環境の下で検証を行う．
卜部（データ流通ワークショップ，2013）で言及があった通り，JDXnetで流通しているのは10000チャンネル弱であり，85％程度は空いているが，多くが虫食い状態であり大きなブロックは残っていない．一方で，陸上や海底でのオフライン観測で得られた観測データをJDXnetの流通データと統合して解析を行ったり，複数機関でのデータ共有，高感度地震計以外の地殻変動・火山・強震等の多項目観測データを同一システムで取り扱う機会が増えており，チャンネル空間の枯渇が課題となっていた．そこで，チャンネル番号の桁数を現行の16ビット長から32ビット長へ増加することにした．
WINフォーマットは観測点での収録から，伝送流通網，収録系にまで幅広く使用されている．チャンネル空間の拡張にあたっては新しいフォーマットが必要となる．運用中の機器との互換性や，これまで収録されてきた既存データとの相互運用性を考えると，ネットワーク上やファイルシステム上で新旧両フォーマットが混在可能であることが望ましい．またソフトウェアについても両フォーマットを混在した状態を扱えることが望ましい．そこで，現行のWINフォーマットを拡張することとした．
WINフォーマットは1秒のブロックが基本単位になっている（図上段）．先頭に6バイト長の時刻情報があり，その後に複数のチャンネルブロックが連なっている．各チャンネルブロックの先頭には4バイト長のチャンネルヘッダがついており（図中段の黄色ハッチ部），その後ろにデータの本体が続く．チャンネルヘッダには2バイト長のチャンネル番号（channel ID）が含まれる（図中段赤枠）．現行フォーマットでは，チャンネル番号（channel ID）として0x0000から0xFFFFまでの値を取ることが出来る．0xFFXXのチャネル番号は32ビット拡張用として予約されていたが，それを利用することとした．即ち，先頭バイトが0xFFであったら拡張フォーマットであることを表し，更に続く2バイト目が0x00の時(図下段青枠)は，引き続く32ビット（図下段赤枠）が新たなチャンネル番号（channel ID）を示すと定義した．なお，チャンネルヘッダの先頭2バイトが0xFF01～0xFFFFの場合は現在未定義であり，将来の拡張用とすることにした．
以上，今回拡張したチャンネル番号の割り振り方をまとめると，
1．0x0000～0xFEFF (0x0000 0000～0x0000 FEFF)は新旧どちらのフォーマットでも表現出来るチャンネル．ただし，基本は16ビット長で作成．
2．0xFF00以降 (0x0000 FF00～0xFFFF FFFF)は拡張フォーマットでのみ表現できるチャンネル．
となる．なお，チャンネルヘッダには，4096Hz以上のデータを扱える高サンプリングレート等のバージョンもあるが，チャンネル番号の拡張については上で述べた方法で対応可能である．
現在，チャンネル番号32ビット拡張化については，WINシステムの基本ライブラリの対応が完了し，順次，個々のソフトウェアの対応を進めている．今後，伝送流通網や収録系のテスト環境の下で検証を行う．