日記・備考録
Diary/Memorandum

2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019/ 1 2 3 4 5 6 7 8 9 10 11 12 | 2020
Search
June July
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
August | Home

2019/08/01〜

....................................................................................................................................

2019/07/30

2019/07/28 20:00 UTC頃、QZS-1 L1C/A (PRN193) アラートON。2019/07/29 03:15 UTC頃 アラートOFF。NAQU2019142によるとサービス停止時間は6時間26分。計画されていたサービス停止ではないので何らかの障害と推測される。サービス停止時の仰角が低かったため、信号停止を伴ったか否かは確認できていない。整理のため、昨年11/1のQZSS正式サービス開始以降の計画されないサービス停止 (L1C/A) を以下にまとめておく。

QZSS unscheduled service outage (L1C/A)
satellite PRN start (UTC) stop (UTC) duration NAQU
QZS-3 199 2019/01/28 20:15 2019/01/29 07:24 11 H 9 m 2019021, 2019033
QZS-1 193 2019/01/28 20:19 2019/01/29 04:37 8 H 18 m 2019025, 2019029
QZS-3 199 2019/02/17 06:48 2019/02/17 19:25 12 H 37 m 2019043, 2019046
QZS-1 193 2019/05/19 15:50 2019/05/19 21:17 5 H 27 m 2019109, 2019113
QZS-1 193 2019/07/28 20:48 2019/07/29 03:14 6 H 26 m 2019138, 2019142

....................................................................................................................................

2019/07/29

GPS World, Without Galileo, life goes on, July 25, 2019

Inside GNSSの記事 (参照) と同じ様な趣旨。外から見てても、さすがに今回のGalileo障害に対するGSAの対応は不満が残るよね。他山の石とせねば。

....................................................................................................................................

2019/07/28

CSG shop, ublox ZED-F9T high accuracy timing module with SMA

ラトビア某社製ZED-F9Tボード。F9Pボードと価格が一緒なのでポチる気にはならない。F9Pボードではバックアップ電池がSMAコネクタとショートしそうだったが、このボードでは改良されている。RTKステータスを表すLEDインジケータがついている様だが、F9TでRTK動くんだっけ ?

-------------------------------------

Qiita, RTK-GPSを用いた高精度測位のリベンジ ! (普及型高精度GPSプラットフォームの構築) 〜No.4〜

ZED-F9P + ESP32による普及型高精度GPSプラットフォーム「RTKDRAGON」。個人プロジェクトの様だが、今後の展開に期待。

-------------------------------------

Drogger, RTK 2周波 GNSS DG-PRO1RW

ZED-F9Pベースの小型RTK受信機。通信はBT。専用Androidアプリ。\59,800 (2周波アンテナ付き、税抜) は少し高い。やはり、単独でロガーとして使えるよう、本体にSDカードスロットが欲しい。

....................................................................................................................................

2019/07/27

Politico, Galileo blackout followed effort to guard against cyber threats, July 25 2019

Galileo障害続報。GSA関係者によると、障害は地上局の時刻システム障害で始まったが、ドイツのもう一局がソフトウェアのセキュリティ更新のためバックアップとして動作せず、全面サービス停止を引き起こした、とのこと。記事の信頼性は不明。

....................................................................................................................................

2019/07/25

RTKLIB: Support information

No.147を追加。BD982 F/W 5.41では、BINEX 0x01-04の代わりに0x01-14を出力する様に変更になっているので、Trimbleの他の受信機でも同様と思われる。本件次のリリース (パッチ) で対応予定。

補足: BINEX Log。Upgraded Galileo decoded ephemeris (0x01-14) は、BINEX 2018/07/13の改訂で追加されている。Galileo decoded ephemeris (0x01-04) との違いは、ToCフィールドの追加とaf0フィールドのビット数増加 (real4->real8)。(7/28追記)

....................................................................................................................................

2019/07/24

Inside GNSS, Failure to communicate: A black swan has landed... right on top of the Galileo program, July 23, 2019

これも、別に新しい情報があるわけではないのだが、

> In the longer term, however, the Galileo program faces trust issues for its failure to communicate the situation, its cause and its
> consequences in a prompt, clear and thorough manner.

と今回のGalileo障害に関する、GSAの後手後手で不十分な情報公開に苦言を呈している。記事にあるように、GPS SVN49問題とかGLONASS全面停止だとか、他GNSSでも大なり小なり過去トラブルはあった訳だが、今回の障害は、復旧まで長時間かかった点で比例するものがない。GNSSの信頼回復のため、今後詳細な調査報告が出されることを望む。

....................................................................................................................................

2019/07/19

WIRED, Europe's weeklong satellite outage is over - but still services as a warning, July 18, 2019

Galileo障害について、大して新しい情報はないのであるが、

> "An assumption is made, whether it’s Galileo or GPS, that that service will always be up and available and is perfectly reliable,"
> IOActive's Sheehy says. "We have seen that that is a flawed assumption. The tech industry is very reliant on these services, and
> it's really remarkable how much critical infrastructure today depends on timing or location services. So that assumption can have
> some very significant real-world consequences."

ということで、今回のGalileo障害をきっかけに、GPS/GNSSに依存した社会の仕組みやGPS/GNSS自身の脆弱性について、再度議論が高まるのではないか。

....................................................................................................................................

2019/07/18

Daniel Estevez, Galileo constellation outage, July 16 2019

スペインGMV社のGNSSエンジニアで、アマチュア無線技師でもある、EstevezさんによるGalileo障害の解析。LimeSDRを使ったGNSS-SDRで、障害中のGalileoの信号を受信して解析している。彼の解析結果によると、障害中、衛星信号は正常であるが、ephemerisがIODNAV=958、T0e,T0c=424200 (2019/07/11 21:50 GST) 以降、更新されなくなった。ephemerisには週番号が含まれないので、2019/07/15 09:50 以降、受信機が週番号を誤認し、衛星軌道の大きな誤差、最終的に大きな測位解誤差が現れた、と推測している。また、約半数の衛星のephemerisのdata validity statusが0 (OK) を示し、残りは1 (not OK) を示していた。後者が1を示した理由に関しては "I have heard rumour that depending on the on-board software, some satellites are able to detect that the ephemeris are too old and set the data validity to 1 automatically, while others need to be commanded by a groundstation. " としている。

-------------------------------------

NAGU2019027

2019/07/17 20:52 UTC、Galileo正常復帰。障害開始時刻が微妙だが、NAGU2019025からとすると、サービス停止期間は6日19時間52分、NAGU2019026からとすると、サービス停止期間は5日19時間2分であった。

-------------------------------------

u-blox, ZED-F9H module

product summary を見る限り、F9Pと仕様の多くが同一なので、F/W変更/機能限定版みたいだが。rawが出てかつ安ければ歓迎。

補足: rawもRTCM 3も出ないみたい (参照)。でも、なんか裏技が見つかるかもしれないので、実物が出たら1個買うかも。(8/22追記)

-------------------------------------

NavSAS, Galileo down - July 2019 (Part 2)

NavSASによると、EVK-M8Tは2019/07/16 19:04 UTCの時点でGalileoのみでvalid fix解を出力していた様だ。ただし2019/07/17 12:00 UTC時点の航法データ解析ではSISAはNAPAを示しており、ステータスは "Marginal" となっている。Xiaomi Mi8 proでは、EVK-M8Tとは異なり、解からGalileo衛星を除外している。また、障害中 2019/07/12 10:00 UTCにおけるIGS精密暦を使った測位解は正常値を示しており、これは今回の障害がephemrisのみに影響し、それ以外のSIS要素は正常であったことを示唆する、としている。

u-blox M8Tが "Marginal" (SISA=NAPA) の衛星を使用して、解を出力してしまうのは動作としては妥当ではない。といっても、SISAの規定が追加されたのは、Galileo OS-SIS ICD issue 1.3 (Dec. 2016) からなので、F/Wの対応がICD改訂に間に合っていないのかもしれない。

-------------------------------------

2019/07/17 23:47 UTC現在、ウチで受信中のGalileo衛星のSIS statusは "Marginal" から "Healthy" に変わり、ZED-F9P + RTKNAVIの単独測位解に組み込まれる様になった。GPST-GSTオフセット (+ISB) 推定値も2-3 nsと正常値に戻った。Constellation Statusでは、ほとんどの衛星は未だNOT USABLEで、新しいNAGUも発行されていないが、程なく正常に復旧するのではないかと予想される。

....................................................................................................................................

2019/07/17

2019/07/17 08:18 UTC現在のウチのBD982 (F/W 5.41、上)、ZED-F9P (F/W 1.00 HPG 1.12、中) の信号受信状況。下はGalileoのephemeris一覧。ephemerisは更新され、SHS (signal health status) + DVS (data validity status) も正常 (=0) となっているが、SISA (signal-in-space accuracy) がNAPA (no accuracy prediction available, =255) を示しており、RTKNAVI (2.4.3 b32) の単独測位解には組み込まれていない (バーが灰色)。なお、この様な状況では、BD982のBINEXではephemerisを出力してくれない様だ。

補足: Galileoのステータスに関する参考文書。Table 4を見ると現在のGalileo衛星のSIS statusは "Unhealthy" ではなく "Marginal" であることが分かる。(18:17追記)

European GNSS (Galileo) open service signal-in-space operational status defintion, Issue 1.1, July 2016

再補足: BD982のGalileo ephemerisのBINEX出力に関して、F/W 5.41から、形式従来の0x01-04 (参照) レコードから0x01-14レコード (参照) に変更になっている様だ。現行RTKLIB (2.4.2 p13, 2.4.3 b32) では0x01-14レコードは未サポートなので、F/W 5.41で出力されるGalileoのephmeirisが認識されない。本件次のリリースで対応予定 (support info No.147)。(7/25追記)

-------------------------------------

GSA, Galileo initial service recovery actions underway, July 17, 2019
Inside GNSS, Galileo outage update: service failure poses serious questions, July 15, 2019

Galileo障害続報。Inside GNSSサイトは繋がりにくい状況が続いていたが、やっと正常に記事が表示される様になった。と言っても両者とも大して新しい情報はない。主従 2局のPTFが両者とも障害を起こしていることは間違いない様だ。バックアップがバックアップになっていなかったということで、どこかにsingle point of failureがあったのだろう。システムの問題ということでいずれ総括がされると思うが、システム設計の観点で参考になる点が多々あるので、今後の推移を注目してみたい。

....................................................................................................................................

2019/07/16

NavSAS, Galileo down - July 2019

未だGalileo障害は回復していないが、伊 Navigation signal analysis and simuation (NavSAS) による、Galileo障害中の信号および航法データの解析。この解析によると、(1) 衛星信号レベルは正常、(2) GPS+Galileoの測位解に500mオーダーの誤差、(3) PRN14を除く全可視Galileo衛星のSISステータスフラグは "healthy" を示す。(4) 短期の測位解変動として "snake-like" トレンドを示す。(5) 市販受信機 (u-blox EVK-M8T) の信号受信状況は正常だが、GPS+Galileo測位解からはGalileoが除外され、GalileoのみではNo Fixとなる。(6) スマホ (Mi 8, P10, Galaxy S8) ではGalileo測位解は得られない。(7) 15時間の監視後、いくつかの衛星の航法データのDVSフラグが0以外 (unhealthy) を示すようになった。(8) 航法データのエイジが既定の4Hを超えている可能性がある。

本当に航法データ更新が止まっているとすると、PTF障害だけでなく他の地上系サブシステムも正常動作をしていないことになり、障害が連鎖的に波及している可能性がある。深刻な事態で復旧にどれくらい時間がかかるかちょっと予想できない。

....................................................................................................................................

2019/07/15

R.Zanello et. al., Time transfer with the Galileo precise timing facility, 39th annual PTTI meeting, 2007

ちょっと検索した範囲では少し古い資料しか見つからなかったが、Galileo PTF (precise timing facility) の構成を含むGST (Galileo system time) の生成。この資料によると、PTFは主従 (master - slave) 2局から構成され、各々独立にGSTを生成する。各PTFは、2台 (運用+バックアップ) のAHM原子時計 (active hydrogen masers、T4S社製) と 4台のCs原子時計 (Symmetricom社製)、TWSTFT (two way satellite time and frequency transfer) 用VSAT通信機材、GPS CV (common view) 用GNSS受信機 (TTS-3受信機、AOS社製)、計測・制御用計算機、PTFソフトウェア、等から構成される。運用AHMはINRiM (Instituto Nazionale di Ricerca Metrologica) の協力により開発されたGSTアルゴリズムによりsteeringされGSTを生成する。バックアップAHMはSpectroTime社の協力で開発されたアルゴリズムでsteeringされる。毎時、TWSTFTにより、UTC(k) 間、USNO間、PTF間の時刻転送が行われる。CVは16分間隔で実施され、時刻転送のバックアップとして使われる。これら時刻転送により、GGTO (Galileo - GPS time offset)、PPTO (PTF - PTF time offset) が生成され、steeringの入力として使われる。

ということで、今回のGalileo障害の原因としては、イタリアの主PTFの障害により、GSTの既定精度が維持できなくなり、UREの異常監視スレッショルドを超えたため、全衛星のステータスを異常にしてサービスを止めた、という可能性が高い。障害が長引いているのを見ると、以上の2重のバックアップ系の切り替えも正常動作しなかった、ということであろう。発端はH/W障害であろうが、H/W障害に伴い内在したPTFソフトウェア不具合が顕在化したと予測する。

補足: PTF所在地についての情報が見つからなかったが、2つのGCC (Galileo Control Centre) は独 Oberpfaffenhofen (GCC-D) と伊 Fucino (GCC-I) に置かれている (参照) らしいので、問題の発生したPTFは、伊 FucinoのGCC-Iに併設されているのではないか。(19:14追記)

....................................................................................................................................

2019/07/14

GSA, Constellation Information

2019/07/14 13:00 UTC現在、Galileo 全衛星のstatusが ”TESTING" または "NOT USABLE" となっている。(関連記事)

補足: 2019/07/15 08:00 UTC現在、復旧せず。NAGU2019025によると、最初の障害が発生したのは2019/07/11 01:00 UTCなので、すでに100時間以上が経過している。障害状況や原因についてNAGU以外の公式発表はないが、BBCの報道 (参照) によると、 "... the problem lay with a fault at a Precise Timing Facility (PTF) in Italy. A PTF generates and curates the reference time against which all clocks in the Galileo system are checked and calibrated." とのことである。記録のため、うちのBD982 (F/W 5.41、Ignore Health Allに設定) の現在の信号追尾状況を貼っておく。多分、赤はunhealthyではないかと思うのだが。正常そうな衛星 (E04, E09, E36) もあるが、これはAlmanacが更新されていないだけなのかもしれない。(7/15追記)

-------------------------------------

u-blox, ZED-F9P FW 1.00 HPG 1.12

ZED-F9P FW 1.00 HPG 1.12がリリース。release note を見る限り、RTKでのQZSSのサポートは見送り。integration manual によると、UART2でのUBXサポートも未。主な変更点はBeiDou PRN31-37サポート位。

-------------------------------------

檜山, マルチGNSSを活用したGEONETの新たな解析手法について, 第48回国土地理院報告会, 令和元年6月5日

「日々の座標値」新解析戦略、民間GNSS連続観測点活用、等。現解析戦略による「日々の座標値」は「最新の国際的な位置の基準 (ITRF2014) から2-3cm離れている」(p.15) とのこと。過去経験では、電子基準点「日々の座標値」を使った基線解と、IGS精密暦やMADOCA暦を使ったPPP解とは水平で数cm程度の系統誤差を示すことが多く、解析戦略更新後はこれが改善されるのでないかと期待する。

-------------------------------------

農研機構, 小型GNSS受信機を用いた高精度測位マニュアル (ドローン用対空標識編)

ドローン用対空標識の座標値測定マニュアル (プレスリリース)。測定には低価格小型GNSS受信機とRTKLIBを使用している。付録で機材の製作方法、運用手順、プログラムや関連データの取得方法等が詳説されている。

補足: 「ドローンを用いたほ場計測マニュアル (不陸 (凹凸) 編)」。ドローン + SfMによる測量は、精度、コスト面で、農業応用に限らずとても有望な技術と考えている。運用性面で、GCP (地上評定点) を設置・測量しなければいけない点が課題であったが、ドローン自身に高精度GNSSを載せることで、原理的にGCPが不要となり、より実用的な技術に進歩したと思う。高精度GNSSの低価格化に伴い今後より普及が進むと予測している。(10:41追記)

....................................................................................................................................

2019/07/10

Geosense, アンテナ別 ZED-F9Pの受信強度

ZED-F9Pと各種多周波アンテナを組み合わせて受信強度 (C/N0) を評価している。大変興味深い結果。表で示されたデータは、仰角80度以上の、一部を除いた全衛星の平均であることに注意。実用上は低仰角特性やマルチパス耐性も重要なので、表の値が低いから低性能という訳ではない。

....................................................................................................................................

2019/07/03

Trimble BD982 Receiver - Support

Trimble BD982 F/W ver. 5.41リリース。ver. 5.37にあったGalileoの追尾衛星数が減ってしまう問題は直っている様だ。F/W更新にはFirmware Warranty Dateとして、2018-11-01以降が必要。うちのBD982の1台はこれが2018-09-01なので "Warranty Date Expired" と出てF/W更新ができなかった。

....................................................................................................................................

2019/07/02

u-blox, ZED-F9Tモジュール

u-blox社 ZED-F9Tモジュールの量産開始。マニュアル等の技術文書も追加されている。Web shopで既にサンプルも買える様になっているが、価格は175.9 EUR @1pcs (\21,517) とF9Pと変わらない。この価格だと、量産しても\1万以下で2周波RTK受信機を出すのは無理な訳で、ちょっと残念ではある。

-------------------------------------

X. Xu et al., Characteristics of BD3 global service satellites: POD, open service signal and atomic clock performance, Remote Sensing, 2019

BD3 (BeiDou-3) 衛星の性能評価。信号特性としては、B1CのSNRが少し低くノイジー、GFIFP (geometry-free, ionosphere-free phase) によるinter-frequency phase bias評価では2cm程度の変動。軌道決定精度としては、オーバラップ誤差とSLR残差で双方5 cm前後。搭載時計安定度としては2.43×10-14@10,000s、2.51×10-15@86,400sで、GPS Block IIF (RAFS) より良く、Galileo FOC (PHM) より悪い。BD2衛星に比較して、信号特性、時計安定度が大幅に改善されており、2020年のBD3完成時には、よりよい性能が期待されるとしている。

-------------------------------------

いくつか問い合わせを頂いているので、昨日の補足。当面、大学研究員の仕事は続ける予定です。それ以外は白紙で、次に何をするか、ゆっくりと考えたいと思っています。

....................................................................................................................................

2019/07/01

移動のご挨拶

いつも、本ウェブサイトをご覧いただきありがとうございます。

私事になりますが、昨日2019年6月30日付で、ライトハウステクノロジー・アンド・コンサルティング (株) (LHTC社) (参照) を退職しました。在職中に仕事を通じて多数頂いたご厚情に深謝します。入社後、一エンジニアとして自分なりに頑張ってきたつもりですが、「個人的に研究開発を続けてきた技術を世に出す」という目標 (参照) に対し、道半ばで会社を去ることに少しだけ心残りを感じます。ただ、この約6年間の会社員生活を振り返ってみると、色々な勉強をさせて頂き、本当に充実した幸福な日々でした。この様な機会を与えてくれた前田社長をはじめ、同社の皆様には感謝の気持ちしかありません。最後になりますが、同社の発展と皆様のご多幸を、今後とも陰ながらお祈りしています。

2019年7月1日

....................................................................................................................................

〜2019/06/30


Home by T.Takasu