人工衛星セミナー資料と人工衛星ハッキングの問題点 ― 2010年02月05日 07時29分04秒
人工衛星セミナー資料なるものがダウンロードできるようです。
実は人工衛星との通信はアップリンクとダウンリンクというような言い方がされますが、わざわざ双方向通信的な用語ではなくて単方向通信的な用語が使われるのには理由があります。
それは通常のインターネットの通信と同様の全二重通信は出来ない仕組みだからです。
要は「アンテナ」の向きと周波数帯、送信出力などに依存している通信ということです。
この前提で改めて人工衛星ハッキングを考えてみると面白いでしょう。 詳細は調べたいと思いますが、調べるまでもなく以下のような問題があると思います。
- 人工衛星との通信には管制局のサーバと繋がっている送信用アンテナの出力と人工衛星との物理的な位置関係に依存する
- 人工衛星との通信には管制局のサーバと繋がっている受信用アンテナの感度と人工衛星の送信用アンテナの向き、人工衛星との物理的な位置関係に依存する
- したがって、ある地点のGPS受信機が測位に使っている人工衛星を洗い出して、その衛星と通信したいと思ってもその同時刻に管制局のサーバと繋がっているアンテナと人工衛星のアンテナの都合により通信できない場合がある
原稿再修正依頼対応 ― 2010年02月06日 14時37分20秒
1月に提出した原稿の修正依頼がまたまた来てしまいました。 60文字程度の追加です。 2度の修正は始めてかな。
今回の教訓。
- 全体の文字数だけでなく、章立ての数を意識する
- 章立てが多い時は文字数は少なめ
- 章立てが少ない時は文字数は多め
- 段組と章立ての見出しの位置にも配慮
- フォントサイズにももちろん留意
テキストファイルだけで提出するのでちと厳しい話ですけどね。
実行速度の遅いiwup_tsk ― 2010年02月07日 00時46分16秒
現在開発に携わっている案件でμITRONを使っています。
このμITRONのiwup_tsk()が異常に遅い。 クロック周波数などは伏せますが、割り込みハンドラ内での実行速度に5us～80usというように幅がある。 サービスコールの前後でポートに出力してオシロスコープで観測した結果です。
私の認識ではiwup_tskはμITRONのサービスコール（システムコール）のなかでも最上級でシンプルで実行速度が速いつもりでいました。この認識を覆す遅さです。
遅いというよりも実行速度に幅があることが問題。こんなに幅があると割り込みハンドラの設計が出来ない。割り込み保留可能時間を見越せないということで非常に問題があります。
これは開発担当者の実装設計がまずいといわざるを得ないです。
私の認識では「iつきサービスコール」は以下のような実装である必要があると思っています。
- 遅延ディスパッチは当然
- 遅延ディスパッチの前の事前のキュー繫ぎ替え処理は関数本体では行わない
- 関数本体では要求のためのマークをつけるだけ
- キュー繫ぎ替え、割り込み復帰時のディスパッチ用のスタック操作は遅延ディスパッチ処理の一環として実施
実行速度に幅がある理由は想像では以下です。
- 関数本体で遅延ディスパッチの事前準備まで実施
- つまりレディキュー、待ちキューの繫ぎ替え処理まで行っている
- 処理時間の違いはキューに繋がっているタスクの数に依存
- キュー繫ぎ替えの結果によってディスパッチするタスクが割込みが入る以前のタスクかそうでないかによってコンテキストの扱いが変っている
遅延ディスパッチの実装上の意味を割り込みハンドラから抜けるタイミングまで遅らせて次の実行タスクにジャンプする程度のことだと勘違いしていないですかね。開発担当者は。
例えばサービスコール発行が一つではなく、複数の場合はこの実装だと処理時間の無駄が積算されます。
まあ、そんなに単純な理由ではないのかもしれませんけど。 ソースコード見ないことには真相は不明です。
いずれにしてもこんなに性能が悪いμITRONが出回っているのだとするとμITRONを使用したシステムの基本設計の最初の段階でサービスコールの実測作業が必要だということになります。 特に「iつきサービスコール」については実測必須です。 μITRONが速いということも主張できなくなりますね。
・・・・というところまで書いてきて、検索してたら使っているものとは違いますがdoxygenでTOPPERSのソース公開されているところを見つけました。結論としてはTOPPERSの実装が諸悪の根源みたいです。
これを見るとiwup_tsk()とwup_tsk()の実装はほぼ同じ。iwup_tsk()ではディスパッチを実行せずにディスパッチが必要かどうかのフラグを立てているところが違う。 だめじゃん。もっと前の段階の処理を省略しないと処理速度が一定にならないです。ディスパッチが必要かどうかを判定する処理自体も遅延させないと。つまり「wait_complete(tcb)」って関数コールはここでやったらだめです。キューの状態に依存する処理は処理速度が一定にならないですから。
こちらにも解説がありますね。
このような状況が放置されているのは最近のμITRONのカーネルの開発者と実際の組込みシステムの開発者の意識が違いすぎるということなのかもしれません。μITRON2.0の時代は現場の人間がμITRONカーネルの開発をしたので学者じゃなかったと思います。
今のμITRONカーネル開発者は「学者」ってことです。本当の性能要件が分かっていない。 割り込みハンドラの実装部分から設計をやり直したいですね。 メモリ保護とかよりもこっちが先でしょ。
2009年分帳簿入力完了 ― 2010年02月08日 01時29分50秒
2009年分の帳簿データの入力をひとまず終わらせました。
主に経費関係の領収書のつき合わせでデータ入力です。
しばらく時間を置いて再確認の上確定申告したいと思います。
設計に問題があるrcv_mbf ― 2010年02月09日 00時39分53秒
rcv_mbf()は指定したメッセージバッファIDのメッセージバッファからメッセージを受信するまで待つサービスコールです。
メッセージバッファへの送信はsnd_mbf()を使います。
ここで問題。
snd_mbf()には送信サイズを指定して、そのサイズがメッセージバッファ生成時に指定した最大サイズを超えているとエラーリターンします。
一方rcv_mbf()は受信したメッセージサイズをリターン値として取得するようなインターフェースはありますが、異常動作を未然に防ぐような仕組みは全く用意されていない。 この仕様だとどうなるかというとバグによりRAM領域を破壊する可能性が高い。
- バッファサイズ100バイトのメッセージバッファを生成
- 送信サイズは可変
- 送信側タスクがメッセージバッファに20バイトのメッセージを送信
- 受信側タスクが10バイトの領域を指定して受信
- 受信は正常完了
- 受信のリターン値は20バイト
- 受信タスクは異常に気付かない
- 全く別のタスクでRAM破壊による異常動作が発生
というような不具合が平気で発生します。
rcv_mbf()にstrncpy()のような最大サイズを指定するようなインターフェースを用意するのが組込み屋さんとしての最低限の実装でしょう。 その上でエラーリターンしてくれないと・・・・
代替案としてはrcv_mbf()を直接使うのではなく、受信サイズと領域サイズをチェックするようなマクロを通常は使うようにする。というようなところでしょうか。
最近のコメント