c2a-core
c2a-core copied to clipboard
ut-issl
TLC のキューから，TIではなくunixtimeなどの絶対時間で Cmd を delete できるようにしたい
概要
TLC のキューから，TIではなくunixtimeなどの絶対時間で Cmd を delete できるようにしたい
詳細
- https://github.com/ut-issl/c2a-core/issues/64 で， unixtime （に相当するもの）でTLCが登録 (insert) できるようになった (UTLC)．これを delete できるようにしたい．
現在の UTLC の現状と， delete するための課題
- まず，大前提として，衛星内部におけるマスター時刻は， unixtime ではなく TI である
- 以下の条件が必至なため
- 絶対に過去の遡ることがない（時間単調増加性）
- 起動直後から安定して使える
- 以下の条件が必至なため
- そのため， Cmd実行もTlm生成時刻の基準もすべてTIで動いている
- Tlmの絶対時刻情報などはあくまで補足情報
- UTLCでも時刻としてTI指定ではなくunixtimeで指定できるが，OBCでCmd受理時に時刻がunixtime→TIに変換され，TLCとしてキューに登録される
- 衛星内部のunixtimeは，GPSなどによる更新で変わる可能性もあるし，非可視中に何が起きるかわからないので，マスター時刻はTIで管理するため
- したがって，TLCは基本的には，「x番目」，や，「TI=yのもの」という指定でdeleteする．
- UTLCもCmd受理後はTLCなので同じ
- もし，これをunixtimeでdeleteすることを考える．
- UTLC受理時と同じOBC内ロジックを使うことで，指定したunixtimeでdeleteすることは可能である．
- 一方で，
OBC内ロジック内部で使われる絶対時刻基準（unixtimeとTIの対応元期）は，OBC内部で更新される可能性がある（OBCの内部で保有している絶対時刻ももちろん徐々にずれていくので）． - したがって，delete時にinsert時と同じunixtimeを指定したとしても，delete時に指定したunixtimeから変換されたTIがinsert時のそれと一致する保証はない． これが最大の問題
- その他
- 現在のTLCのキューをTlmで下ろすさい，
{TI, Cmd ID, params}というテーブルで下ろすが，{今OBCが持ってる対応元期から変換されたunixtime, Cmd ID, params}というテーブルでおろすことは可能である．そのテーブルを元に，unixtimeを指定してdeleteすることは可能．- ただし，
今OBCが持ってる対応元期から変換されたunixtimeは，OBC内部の絶対時刻基準が更新されるたびに（時計が再度合わせられるたびに）変わる値であるので，これを地上システム側で吸収する必要はある．（先述の通り，OBC内部のマスター時刻はTIなため） -
絶対時刻基準（unixtimeとTIの対応元期）はTlmによって取得可能であり，これのアップデートも地上システムから検知可能であるので，ここらへんでよしなにするんかなぁ？
- ただし，
- 現在のTLCのキューをTlmで下ろすさい，
close条件
できたら
本質的なところとしてTLCを特定するために使われているものがTIなので、unixtime指定で直接消すというのは少し違和感がある気がする。
つまり、作業の流れとしては
- 消したいunixtime近くのTLCをリストアップする
- TLCを一意に特定するIDを知る
- そのID指定でTLCを削除する
というのが自然な気がしていて、このIDがC2AではTIになっているので、unixtime指定のTLCが打てたとしてもdeleteはTIなんじゃないかな。
要望の背景
人間の運用時にはリストアップから絞り込む方法でも問題ない気がしますが、運用の自動化などを考えると、（ソフトウェアなどが）自身で登録したTLCを確実に削除する方法が欲しいです。
UTLCで登録→TIで削除の手順だと、UTLC登録時にソフトウェアが対応元期をテレメトリから把握しなければならないという制約が増えてしまい、無駄に面倒になってしまうのでunixtime指定での削除が欲しいです。
unixtime指定での削除
@shunichironomura
作ったとしても，上記の通り，不確定性が乗るので，削除コマンドのパラメタは，unixtimeとcmdidの両方（冗長だが）として，そのどっちもが一致した場合に消すといったバリデーションを入れることになるかなと思ってます．
地上システムとして
- UTLC受理時と同じOBC内ロジックを使うことで，指定したunixtimeでdeleteすることは可能である．
- 一方で，
OBC内ロジック内部で使われる絶対時刻基準（unixtimeとTIの対応元期）は，OBC内部で更新される可能性がある（OBCの内部で保有している絶対時刻ももちろん徐々にずれていくので）．- したがって，delete時にinsert時と同じunixtimeを指定したとしても，delete時に指定したunixtimeから変換されたTIがinsert時のそれと一致する保証はない． これが最大の問題
これは許容できますか？
OBC内部の時刻合わせの回数を減らすために， https://github.com/ut-issl/c2a-core/issues/183 というのはやろうと思ってます．
というのが自然な気がしていて、このIDがC2AではTIになっているので、unixtime指定のTLCが打てたとしてもdeleteはTIなんじゃないかな。
個人的にもこれは正しい（DBでいうところのmaster key (id)はTIなので）とおもっていて，unixtmeはあくまでwhereで絞り込めるためのものなんですよね．本来は．（とはいえ，TLCキューをDBとみたとき，このunixtimeは勝手に変わりうるので，そういう意味ではちょっと違うかもしれない）
なので，whereで絞り込んでidを取得するのはシステム側（このシステムを衛星内部で持つのか，地上システムで持つのかは要検討なのですが．．．．）だと思います．（ORマッパー的な） < （ソフトウェアなどが）自身で登録したTLCを確実に削除する方法が欲しいです。
なお，２つ上の僕の投稿で引用している問題がクリティカルではないのであれば，そういうのは追加実装してもいいと思います．
(※ deleteやwhere, idなどは，SQLの意味あいで使ってます．)
なお，衛星内部のマスター時刻をTIではなくunixtimeなどにする，は，宇宙空間にはNTPサーバーなどないので，現状はマスター時刻として必要な要件を満たさず無理だと思っています．
先ほどの話、「リストアップ」と書いたものの、実際100ms以下の範囲のunixtimeになるようwhereで指定すれば原理上自動化できるという感覚でした。
なので，whereで絞り込んでidを取得するのはシステム側（このシステムを衛星内部で持つのか，地上システムで持つのかは要検討なのですが．．．．）だと思います．（ORマッパー的な）
ここが僕の議論の中心で、性能が限られていてリプロが大変な衛星側にわざわざ「unixtimeからTIを絞り込んでTIで削除する機能」を盛り込むより、衛星のTLCをDB的にそしてprimary keyがTIであるとして扱って、select where を打ってTIを特定してTIでの削除コマンドを生成するのは地上局がいい気がしてます。
なるほど、対応元期が変更される差分のオーダーはTIの刻み幅に比べて十分小さいということですかね？ その結果UTLCを送信した時の対応元期を覚えていなくても登録されたTLCを一意に特定できるということであれば地上システム側での対応でよさそうです。
と、書いてて思ったんですが、TLC登録時のunixtimeに合うように登録後に時折TIを修正するという操作を入れうる場合、TIすらも固定されたkeyではなくなってしまうので、なにかkeyになるものを追加した方がいいかもですね...
TLC登録時のunixtimeに合うように登録後に時折TIを修正するという操作を入れうる場合、TIすらも固定されたkeyではなくなってしまうので、なにかkeyになるものを追加した方がいいかもですね...
対応元期が変更される差分のオーダーはTIの刻み幅に比べて十分小さいということですかね？
に関連しますが，UTLの時刻がコマンドを打ってからどのぐらい先かによりますよね．
せいぜい数日を想定していてそれであれば， TLのTIをずらして登録し直す みたいなものは回避できると思ってました（これ必要ならさすがに今の衛星時刻スキームだと限界が．．．）
@ShingoNishimoto @shunichironomura ここらへんの温度感わかりますか？（どれぐらい先のものを登録しようと想定してますか？）
cancelling token的なものを実装してくれるのは大変ありがたいですね
これは，まあなしではないですね．
低リソースマイコンでは無理（主にメモリの観点から．元ISSL MOBCは可能でも，AOBCは厳しそう）なので，C2A coreのoptional機能として実装する感じ．
とはいえ，衛星上でユニークトークンを作るのは現実的に難しいので，シーケンシャルなカウンタを持つことになりそうです（で，それなりの周期でオーバーフローします）
または，MOBCでトークンを作った場合，地上システムがそれを取得するのがめんどくさい，などとなれば，地上システム側でトークンをつくって，それを付与して TL登録する，などでしょうか？
C2A側としては，cancelling tokenからTLCを検索するスキームを導入することになる（ここはO(N)だと厳しいので，さすがにsort indextはってO(log N)ぐらいにしないとダメだと思ってます．となるとまたメモリは食ってしまう）ので，実装コストは高いですが，できることはできますね．
ここらへんの温度感わかりますか？（どれぐらい先のものを登録しようと想定してますか？）
@meltingrabbit これはTOBCでUTLCを使ってどれくらい先のものを登録したいかということですか？ちょっとまだ検討できてないですが，そんなに先のものを登録したいモチベは今のところ思いつかないです．
