エンベデッドシステムスペシャリスト 2025年 午後1 問02
超小型人工衛星を用いた建設進捗状況を監視するシステムに関する次の記述を読んで、設問に答えよ。
B社は、超小型人工衛星(以下、衛星という)を用いて、日本国内におけるダム建設や大規模宅地造成など、建設現場の建設進捗状況を監視するシステム(以下、本システムという)を開発している。衛星は軌道上において自律的に動作し、建設現場の上空通過時に画像の撮影を行い、日本国内で衛星の運用を行う地上局の上空通過時に画像データを送信する。衛星の利用によって、建設現場の状況を時系列に沿って確認しながら、周囲環境への影響も確認することができる。本システムの概要を図1、衛星の外観を図2、本システムの構成要素の概要を表1に、それぞれ示す。


衛星は、衛星自体の制御を行う衛星バスモジュールと、建設現場の撮影を行うミッションモジュールとで構成される。衛星の主な構成要素を図3に、衛星の主な構成要素の概要を表2に示す。


〔衛星と地上局間の通信概要〕
衛星と地上局間の通信は、地上局からコマンドデータを送信するアップリンク、衛星からコマンドデータに対する応答(以下、コマンド応答データという)及びテレメトリデータを送信する低速ダウンリンク、衛星から画像データを送信する高速ダウンリンクによって実現される。通信速度は、アップリンク及び低速ダウンリンクが38,400ビット/秒、高速ダウンリンクが1Mビット/秒である。高速ダウンリンクと低速ダウンリンクの同時利用には対応しない。
衛星は24時間に2回、地上局と10分間の通信が可能な軌道上の区間(以下、通信可能範囲という)を通過する。通信可能範囲内で通信条件が良好な5分間(以下、高速通信範囲という)に、衛星が高速通信用アンテナを地上局に向ける姿勢を取っている場合に限り、高速ダウンリンクを利用できる。低速ダウンリンクは、衛星の姿勢にかかわらず利用できる。
〔衛星と地上局間の通信メッセージと通信プロトコル〕
衛星と地上局は、コネクションレス型のパケット通信方式で通信を行う。パケットの到達は保証されない。衛星と地上局間の通信メッセージを表3に示す。

パケットには、エラー検出訂正符号(以下、ECCという)を付与する。ECCは対象とするバイト列及び付与したECC自身に対して、バイト単位でエラーの検出と訂正を行う。その際、付与したECCのバイト数の半分のバイト数まで、エラーの検出と訂正が保証される。加えて、テレメトリデータ及び画像データの送信時は、設定によって同一パケットを繰返し送信することができる。パケットのフォーマットを表4に示す。
〔衛星の姿勢管理〕
衛星制御部は、リアルタイム位置姿勢情報、テレメトリデータ及び撮影と通信のスケジュール情報を基に、表5に示す衛星の姿勢モードのいずれかを選択する。各姿勢モードには、充電姿勢モードの選択中を除き、表5に示す姿勢モードへの移行トリガーが成立すると直ちに移行する。

〔各姿勢モードにおける衛星の姿勢変更〕
衛星制御部は、現在の姿勢モードとリアルタイム位置姿勢情報に基づいて、衛星が次に取るべき姿勢(以下、目標姿勢という)を周期的に決定し、目標姿勢が前回と異なる場合には、姿勢変更ユニットに目標姿勢への姿勢変更を指示する。
姿勢変更ユニットは、姿勢変更が完了すると、衛星制御部に姿勢変更完了を送信する。姿勢変更完了は、指定どおりの姿勢変更が完了した場合は正常終了とし、それ以外の場合は異常終了とする。姿勢変更が完了する前に、新たな姿勢変更が指示された場合は、現在の姿勢変更を異常終了として即時中止し、新たに指示された姿勢変更を開始する。
姿勢モードの移行及び姿勢変更の結果はテレメトリデータとして保存する。
〔建設現場の撮影〕
ミッション制御部には、撮影位置及び撮影指定姿勢を示すデータ(以下、撮影設定という)が保存されている。衛星制御部は、ミッション制御部から撮影設定を受信し、衛星は次の3ステップで建設現場を自律的に撮影する。
① 衛星制御部は、昼間に建設現場手前の上空に差し掛かると、撮影姿勢モードに移行し、撮影指定姿勢を姿勢変更ユニットに送信する。衛星制御部は、姿勢変更ユニットから姿勢変更完了を受信すると、正常終了か異常終了かにかかわらず、ミッション制御部に姿勢変更完了を送信する。
② ミッション制御部は、衛星の姿勢変更が正常終了したら、撮影位置と衛星制御部から定期的に送信されるリアルタイム位置姿勢情報とを比較し、撮影位置に到達すると、カメラユニットを用いて画像1枚の撮影を行う。
③ カメラユニットは撮影した画像データをデータ処理ユニットに送信する。データ処理ユニットは、ストレージ内の画像データを削除したのち、今回撮影した画像データを圧縮してストレージに保存する。保存が完了すると、ミッション制御部に画像保存完了を送信し、ミッション制御部は衛星制御部に撮影完了を送信する。衛星制御部は周回姿勢モードに移行する。
撮影対象とする建設現場を変更したい場合、地上局は新たな撮影設定をコマンドデータとして衛星に送信することで、衛星に保存された撮影設定を更新できる。
〔画像データの送信〕
衛星は、次の3ステップで撮影した画像を自律的に地上局に送信する。
① 衛星制御部は、夜間に通信可能範囲に接近すると、ミッション制御部に送信待ち画像確認要求を送信する。ミッション制御部は、データ処理ユニットから得られた送信待ち画像有無情報を衛星制御部に応答する。送信待ち画像が存在する場合、衛星制御部は通信姿勢モードに移行し、通信最適姿勢を姿勢変更ユニットに送信する。姿勢変更ユニットは、姿勢変更が完了すると、姿勢変更完了を衛星制御部に送信する。
② 衛星の姿勢変更が正常終了し、衛星が高速通信範囲に到達すると、衛星制御部は、画像データの先頭から、指定した容量ごとに分割した画像データ(以下、画像ブロックという)をミッション制御部に順次要求する。ミッション制御部はデータ処理ユニットから画像ブロックを受信し、衛星制御部に送信する。衛星制御部は、順次、地上通信ユニットに各画像ブロックに対応するパケットの送信を要求する。
③ 全画像ブロックの送信が完了すると、衛星制御部はミッション制御部に画像送信完了を送信し、ミッション制御部は送信が完了した画像データをデータ処理ユニットから削除する。画像データの送信途中で高速通信範囲の終端に到達した場合、衛星制御部は以降の画像ブロックの送信を取りやめる。衛星制御部は周回姿勢モードに移行する。
〔衛星制御部のソフトウェア更新〕
衛星は、地上局との通信によって、軌道上での衛星制御部のソフトウェア更新(Over The Air 以下、OTAという)を実現する機能をもつ。
〔衛星制御部のソフトウェア構成〕
衛星制御部では、リアルタイムOSを使用する。衛星制御部の主なタスク構成を図4に、衛星制御部の主なタスクの処理概要を表6に、それぞれ示す。

設問1:本システムの仕様について答えよ。
設問1(1)
問題文を見る撮影位置に到達するまでに姿勢変更を完了させるには、撮影姿勢モードへの移行トリガーを、撮影位置から軌道上の距離として何km以上手前に設ける必要があるか。答えは小数第2位を切り上げて、小数第1位まで求めよ。ここで、衛星は、0.5秒周期で目標姿勢を決定し、決定後、最大15秒で機体を指定の方向に回転させ停止させることができるものとする。
模範解答
116.3
解説
解答の導き方
撮影姿勢モードへの移行トリガーを設ける位置は、姿勢変更が完了するまでに衛星が進む距離以上、撮影位置より手前である必要があります。まず、姿勢変更が完了するまでの最悪の場合の時間を求めます。
問題文では、衛星制御部が目標姿勢を「周期的に決定」し、目標姿勢が前回と異なる場合に姿勢変更を指示するとあります。設問では目標姿勢の決定周期が0.5秒なので、トリガー成立から次の目標姿勢決定まで、最長で0.5秒待つ可能性があります。
さらに、設問では目標姿勢の決定後、指定方向への回転と停止に最大15秒掛かるとされています。したがって、姿勢変更が完了するまでの最悪時間は次のとおりです。
表1にある衛星の飛行速度は7.5km/秒です。姿勢変更が完了するまでに衛星が進む距離は、次のとおりです。
撮影位置から少なくともこの距離だけ手前にトリガーを設ける必要があります。設問の指示どおり、小数第2位を切り上げて小数第1位まで求めると、必要な距離は116.3 kmとなります。
誤りやすいポイント
- 姿勢変更に掛かる最大15秒だけで計算すると、目標姿勢を決定するまでの待ち時間を見落とします。
- 目標姿勢の決定周期が0.5秒なので、平均待ち時間ではなく、最悪の場合の0.5秒を使います。
- 「少なくとも必要」な距離を求めるため、端数は指示どおり小数第2位を切り上げます。
FAQ
Q: 目標姿勢の決定までの待ち時間は、なぜ0.5秒ですか?
A: トリガーが周期処理の直後に成立すると、次の目標姿勢決定までほぼ1周期待つことになるためです。最悪の場合として0.5秒を加えます。
A: トリガーが周期処理の直後に成立すると、次の目標姿勢決定までほぼ1周期待つことになるためです。最悪の場合として0.5秒を加えます。
Q: なぜ距離は衛星の飛行速度と時間を掛けて求めるのですか?
A: 姿勢変更が完了するまで衛星は軌道上を飛行し続けるため、その間に進む距離を撮影位置より手前に確保する必要があるからです。
A: 姿勢変更が完了するまで衛星は軌道上を飛行し続けるため、その間に進む距離を撮影位置より手前に確保する必要があるからです。
Q: 姿勢変更に掛かる時間には、回転だけでなく停止まで含めますか?
A: はい。設問では、機体を指定の方向に回転させて停止させるまでに最大15秒掛かるとされています。
A: はい。設問では、機体を指定の方向に回転させて停止させるまでに最大15秒掛かるとされています。
関連キーワード: 周期処理、姿勢制御、軌道速度、最悪時間、切上げ
設問1(2)
問題文を見る衛星の運用を開始し、地上局による画像データの受信確認後、衛星が夜間の上空通過時に通信姿勢モードに移行せず、画像データの送信を行わない場合、いつ、どのような事象が発生したと考えられるか。データ処理ユニット内に送信待ち画像が存在する場合について、30字以内で答えよ。ここで、地上局からのコマンドデータ受信、姿勢変更の異常終了、衛星の各部品の故障及び外乱を原因とする誤動作は生じていないものとする。
模範解答
・昼間の撮影完了後に、充電姿勢モードに移行した。
・建設現場の撮影完了後に、バッテリー残量が一定値を下回った。
解説
解答の導き方
-
まず、夜間に送信待ち画像がある場合の通常の動作を確認します。表5では、送信待ち画像が存在するとき、夜間に通信可能範囲の手前に差し掛かると、通信姿勢モードへ移行するとされています。したがって、送信待ち画像があるのに通信姿勢モードへ移行しないのは、通常とは異なる姿勢モードの状態が続いていた可能性があります。
-
表5では、バッテリー残量が一定値を下回ると充電姿勢モードに移行し、残量が一定値を超えるまでは、ほかの姿勢モードへ移行しないとされています。衛星が充電できない軌道を飛行中でも、この制約は変わりません。
-
表6でも、バッテリー残量低下の通知を受けるとメインタスクが充電姿勢モードを要求し、姿勢管理タスクは充電姿勢モード中、充電姿勢モード終了の要求を受けるまでほかの姿勢モード要求を無視します。つまり、送信待ち画像があって夜間の通信姿勢モードへの移行条件が成立しても、充電姿勢モード中であれば通信姿勢モードには移行しません。
-
そのため、昼間の撮影完了後、バッテリー残量が一定値を下回って充電姿勢モードに移行したと考えられます。充電姿勢モードが続いた結果、夜間に通信姿勢モードへ移行できず、画像データも送信されなかったと判断できます。
誤りやすいポイント
- 送信待ち画像があれば必ず通信姿勢モードへ移行すると考えないようにします。充電姿勢モード中は、ほかの姿勢モードへの移行が抑止されます。
- 衛星が充電できない軌道に入れば、充電姿勢モードが解除されるとは限りません。表5では、バッテリー残量が一定値を超えるまでほかの姿勢モードへ移行しないとされています。
- 画像データが送信されない理由を、直ちに通信機器の故障と考えないようにします。この設問では故障などによる誤動作がない条件なので、仕様にある姿勢モードの移行制約から原因を考えます。
FAQ
Q: 送信待ち画像があるのに通信姿勢モードへ移行しないのはなぜですか?
A: 充電姿勢モード中は、バッテリー残量が一定値を超えるまで、通信姿勢モードを含むほかの姿勢モードへの移行が行われないためです。
A: 充電姿勢モード中は、バッテリー残量が一定値を超えるまで、通信姿勢モードを含むほかの姿勢モードへの移行が行われないためです。
Q: 充電できない軌道を飛行中なら、充電姿勢モードを終了しますか?
A: いいえ。表5では、充電できない軌道を飛行中の場合も、バッテリー残量が一定値を超えるまではほかの姿勢モードへ移行しないとされています。
A: いいえ。表5では、充電できない軌道を飛行中の場合も、バッテリー残量が一定値を超えるまではほかの姿勢モードへ移行しないとされています。
Q: 送信待ち画像が存在することは、この判断にどう関係しますか?
A: 送信待ち画像があれば夜間に通信姿勢モードへ移行する条件が成立します。それでも移行しないため、充電姿勢モードによる移行抑止が原因と考えられます。
A: 送信待ち画像があれば夜間に通信姿勢モードへ移行する条件が成立します。それでも移行しないため、充電姿勢モードによる移行抑止が原因と考えられます。
関連キーワード: 状態遷移、姿勢制御、バッテリー管理、モード調停
設問1(3)
問題文を見るパケットについて答えよ。
(a) ECCをECC1とECC2に分割せず、ヘッダー部とデータ部を統合してエラーの検出と訂正を行う単一のECCを付与する仕様と比較して、ヘッダー部に独立したECC1を付与する仕様は、どのような点で優れているか。ヘッダー部に生じたエラーが、データ部のエラー訂正に及ぼす影響の観点から、45字以内で答えよ。
(b) 5Mバイトの画像データを、5,000パケットに分割して地上局に送信する。1パケットのサイズは1,500バイトとし、各パケットには画像ブロックに加えて、画像の識別と画像ブロックのシーケンス番号の識別のために、それぞれ4バイトのメタデータを含めるものとする。各パケットにおいて、データ部に対して訂正が保証されるエラーバイト数の割合は何%か。答えは小数第2位を切り捨てて、小数第1位まで求めよ。ここで、1Mバイトは1,000,000バイトとし、同一パケットの繰返し送信は行わないものとする。
模範解答
(a):データ部長又は分割データ長にエラーが発生した場合も、ECCによる訂正が可能となる。
(b):15.9
解説
解答の導き方
(a)
表4では、ヘッダー部の先頭から10バイトに対応するECC1と、分割データに対応するECC2が別々に設けられています。ヘッダー部の先頭から10バイトには、データ種別、送信者ID、受信者ID、データ部長、分割データ長が含まれます。
本文には、ECCは対象とするバイト列とECC自身についてエラーを訂正し、ECCのバイト数の半分まで訂正を保証するとあります。したがって、ヘッダー部とデータ部を一つのECCで保護する場合と異なり、ヘッダー部のエラー訂正にデータ部の訂正能力を使わずに済みます。特に、データ部長又は分割データ長にエラーが生じても、ECC1でそのエラーを訂正し、データ部のエラー訂正はECC2で行えます。
(b)
まず、画像データを5,000パケットに分割するので、1パケット当たりの画像データは次のとおりです。
各パケットには、画像の識別と画像ブロックのシーケンス番号の識別に使うメタデータがそれぞれ4バイト含まれます。したがって、分割データは画像データとメタデータを合わせた1,008バイトです。
次に、表4のヘッダー部は、データ種別から分割データ長までの5項目がそれぞれ2バイトで、ECC1が10バイトです。合計は20バイトなので、1,500バイトのパケットにおけるデータ部は1,480バイトです。
データ部から分割データを除いた分がECC2ですから、ECC2は次のとおりです。
ECCのバイト数の半分まで訂正が保証されるため、ECC2によって訂正が保証されるエラーは236バイトです。求める割合は、データ部全体の1,480バイトに対する割合なので、
小数第2位を切り捨てると、15.9%となります。
誤りやすいポイント
- ECC1とECC2を一つのECCとして扱わないようにします。ECC1はヘッダー部、ECC2は分割データをそれぞれ保護します。
- メタデータは画像データそのものではありませんが、分割データに含まれるため、ECC2の計算では分割データの長さに加えます。
- 割合の分母は画像データの1,000バイトではなく、ECC2を含むデータ部の1,480バイトです。
- 訂正保証バイト数はECC2のバイト数そのものではなく、その半分です。また、最後の割合は四捨五入ではなく、小数第2位を切り捨てます。
FAQ
Q: ECC1とECC2を分けると、なぜヘッダー部のエラーがデータ部の訂正に影響しにくくなるのですか?
A: それぞれが異なるバイト列を保護するためです。ヘッダー部の訂正能力とデータ部の訂正能力を別々に確保できます。
A: それぞれが異なるバイト列を保護するためです。ヘッダー部の訂正能力とデータ部の訂正能力を別々に確保できます。
Q: 分割データに含めるメタデータは、画像データのサイズに含めますか?
A: 画像データのサイズとは分けて考えますが、パケット内では分割データの一部です。そのため、ECC2の長さを計算するときには分割データのサイズに含めます。
A: 画像データのサイズとは分けて考えますが、パケット内では分割データの一部です。そのため、ECC2の長さを計算するときには分割データのサイズに含めます。
Q: 15.9%の計算で、なぜECC2のバイト数ではなくデータ部全体を分母にするのですか?
A: 問われているのは「データ部に対して」訂正が保証されるエラーバイト数の割合だからです。分子はECC2による保証訂正バイト数、分母は分割データとECC2を合わせたデータ部のサイズです。
A: 問われているのは「データ部に対して」訂正が保証されるエラーバイト数の割合だからです。分子はECC2による保証訂正バイト数、分母は分割データとECC2を合わせたデータ部のサイズです。
関連キーワード: 誤り訂正符号、パケット通信、ヘッダー、データ部、誤り訂正能力
設問2:衛星制御部のソフトウェア設計について答えよ。
設問2(1)
問題文を見る模範解答
a:充電姿勢モード終了
b:テレメトリ送信停止
c:テレメトリ送信開始
d:目標姿勢
e:姿勢変更完了
解説
解答の導き方
表6の空欄は、タスクが受け取る通知や要求と、その後に行う処理のつながりから判断します。
まず、aはバッテリー残量が回復したときにメインタスクが通知する要求です。バッテリー残量が低下したときは「充電姿勢モード要求」を通知し、姿勢管理タスクは「充電姿勢モード終了要求」を受けるまで、他の姿勢モード要求を無視します。したがって、バッテリー残量が回復したときにメインタスクが通知するのは、充電姿勢モードを終える要求です。aには「充電姿勢モード終了」が入ります。
次に、bとcは、夜間の通信中にテレメトリデータと画像データをどのように送るかを考えます。表3には、画像データの送信中はテレメトリデータを送信しないとあります。また、通信の説明では、高速ダウンリンクと低速ダウンリンクを同時に利用できません。
夜間に高速通信範囲に入ると画像データの送信を始めるため、その前にテレメトリデータの送信を止める必要があります。よって、bは「テレメトリ送信停止」です。一方、高速通信範囲から出た後も、通信可能範囲内にいる間は低速ダウンリンクを利用できます。画像データの送信を止めた後にテレメトリデータの送信を再開するため、cは「テレメトリ送信開始」です。
dは、姿勢管理タスクが姿勢変更ユニットに送信するものです。表6には、姿勢管理タスクが姿勢モードを選択した後、「現在の姿勢モードに対応する」ものを決定して送信するとあります。姿勢モードそのものではなく、そのモードで衛星が取るべき姿勢を決めて送るので、dは「目標姿勢」です。
最後に、eは、ミッションタスクがミッション制御部に通知する内容です。撮影の手順では、衛星制御部が姿勢変更の完了をミッション制御部に伝え、ミッション制御部は姿勢変更が正常終了した場合に撮影を進めます。表6でも、メインタスクが姿勢管理タスクから受けた撮影用の姿勢変更完了をミッションタスクに通知するとあります。したがって、ミッションタスクからミッション制御部への通知であるeは「姿勢変更完了」です。
誤りやすいポイント
- aを「周回姿勢モード」としないようにします。表6では、バッテリー残量回復時に通知するのは姿勢モードそのものではなく、充電姿勢モードを終了する要求です。
- bとcの順序を逆にしないようにします。高速通信範囲では画像データを送信するため、テレメトリデータの送信を止め、高速通信範囲を出たら再開します。
- dを「姿勢モード」と混同しないようにします。姿勢管理タスクは姿勢モードを選択した後、そのモードに応じた目標姿勢を姿勢変更ユニットに送信します。
- eは撮影完了ではありません。撮影を進める前にミッション制御部へ伝える、姿勢変更の完了通知です。
FAQ
Q: 高速通信範囲から出た後も、すぐにテレメトリ送信を再開するのはなぜですか。
A: 高速通信範囲を出ても、通信可能範囲内であれば低速ダウンリンクを利用できるためです。通信可能範囲から出るときに、テレメトリ送信と通信を停止します。
A: 高速通信範囲を出ても、通信可能範囲内であれば低速ダウンリンクを利用できるためです。通信可能範囲から出るときに、テレメトリ送信と通信を停止します。
Q: 姿勢モードと目標姿勢はどう違いますか。
A: 姿勢モードは撮影や通信などの動作状態を表します。目標姿勢は、その姿勢モードで衛星が実際に取るべき姿勢です。
A: 姿勢モードは撮影や通信などの動作状態を表します。目標姿勢は、その姿勢モードで衛星が実際に取るべき姿勢です。
Q: 姿勢変更が異常終了した場合も、姿勢変更完了の通知を行いますか。
A: 行います。問題文では、姿勢変更の結果は正常終了か異常終了で示されます。ミッション制御部はその結果を受け、撮影を進めるかどうかを判断します。
A: 行います。問題文では、姿勢変更の結果は正常終了か異常終了で示されます。ミッション制御部はその結果を受け、撮影を進めるかどうかを判断します。
関連キーワード: タスク間通信、状態遷移、姿勢制御、通信帯域、イベント通知
設問2(2)
問題文を見るタスクの優先度設計について述べた次の文章中のf~iに入れる適切な字句を答えよ。
コマンド応答データを他のデータに優先して送信する目的は、建設進捗状況の監視と地上局による運用効率の両立である。メインタスク、地上通信タスク、地上コマンドタスクに、高、中、低の異なるタスク優先度を割り当てた。地上コマンドタスクの優先度にfを割り当てることによって、地上通信タスクとの間では、gによってhが阻害されることを防ぐことができ、メインタスクとの間では、hによってiが阻害されることを防ぐことができる。
模範解答
f:中
g:テレメトリデータの送信
h:コマンドデータの処理
i:姿勢モードの変更
解説
解答の導き方
-
まず、表6から各タスクの役割を確認します。地上通信タスクはテレメトリデータを順次送信し、コマンドデータを受信すると、その内容に応じて地上コマンドタスクなどに通知します。地上コマンドタスクは、コマンドデータに対応する処理を行い、地上通信タスクにコマンド応答データの送信を要求します。
-
地上通信タスクがテレメトリデータを送信している間に、地上コマンドタスクの処理が待たされると、コマンド応答データの送信要求も遅れます。そこで、地上コマンドタスクを地上通信タスクより高い優先度にします。これにより、テレメトリデータの送信よりもコマンドデータの処理が先に実行されます。したがって、文中のgは「テレメトリデータの送信」、hは「コマンドデータの処理」です。
-
一方、メインタスクは姿勢モード変更の要求を一括管理します。コマンドデータの処理に時間がかかっても、メインタスクによる姿勢モードの変更が遅れないようにするには、メインタスクを地上コマンドタスクより高い優先度にします。したがって、iは「姿勢モードの変更」です。
-
タスク優先度は「高・中・低」の3段階で、メインタスク、地上通信タスク、地上コマンドタスクにはそれぞれ異なる優先度を割り当てます。ここまでの関係は、メインタスクが地上コマンドタスクより高く、地上コマンドタスクが地上通信タスクより高い、という順序です。よって、地上コマンドタスクに割り当てるfは「中」です。
誤りやすいポイント
- 地上通信タスクがコマンド応答データを他のパケットより優先して送ることと、タスク優先度の設定を混同しないようにします。ここで問われているのは、タスク間の実行順序です。
- 地上コマンドタスクを「高」にすると、メインタスクより優先されてしまいます。姿勢モードの変更がコマンドデータの処理に妨げられないよう、メインタスクの優先度を最も高くします。
- テレメトリデータの送信とコマンドデータの処理の優先関係を逆にしないようにします。コマンド応答を速やかに行うため、コマンドデータの処理がテレメトリデータの送信に妨げられない設定にします。
FAQ
-
Q: なぜ地上コマンドタスクを最も高い優先度にしないのですか?
A: メインタスクが行う姿勢モードの管理を、コマンドデータの処理が妨げないようにするためです。 -
Q: コマンド応答データの送信そのものも、地上コマンドタスクが行うのですか?
A: いいえ。地上コマンドタスクは送信を要求し、実際の送信は地上通信タスクが行います。 -
Q: 優先度が高いタスクは、どのように低いタスクの処理を妨げずに実行されますか?
A: リアルタイムOSの優先度スケジューリングでは、実行可能な高優先度タスクがあると、低優先度タスクより先に実行されます。
関連キーワード: タスク優先度、優先度スケジューリング、プリエンプション、リアルタイムOS
設問2(3)
問題文を見る表6中の下線(ア)について、メインタスクは充電姿勢モード要求を通知する前に、二つのタスクに通知を行う必要がある。それぞれどのタスクに対してどのような通知を行うか。30字以内で答えよ。
模範解答
①:ミッションタスクに対して撮影中止の通知を行う。
②:地上通信タスクに対して画像送信停止の通知を行う。
解説
解答の導き方
問われているのは、バッテリー残量低下を受けて充電姿勢モード要求を通知する前に、メインタスクがどの処理を止める必要があるかです。
まず、表5では、バッテリー残量が一定値を下回ると充電姿勢モードに移行し、バッテリー残量が一定値を超えるまでは他の姿勢モードへ移行しないとされています。表6でも、姿勢管理タスクは充電姿勢モード要求を受けると、充電姿勢モード終了要求を受けるまで他の姿勢モード要求を無視します。つまり、充電姿勢モードへの移行後は、撮影や画像送信に必要な姿勢を優先できません。
次に、充電姿勢モードと両立しにくい処理を確認します。撮影中はカメラを撮影指定姿勢に向ける必要があり、画像送信中は高速通信用アンテナを地上局に向ける通信最適姿勢が必要です。どちらも、充電効率を高めるための姿勢とは異なる姿勢を必要とする処理です。
そこで、充電姿勢モード要求を出す前に、撮影を担当するミッションタスクへ撮影中止を通知し、画像送信を担当する地上通信タスクへ画像送信停止を通知します。テレメトリ送信ではなく画像送信を止めるのは、画像データの送信に通信最適姿勢が必要だからです。
誤りやすいポイント
- 充電姿勢モードへの移行要求だけを出せばよいと考えないようにします。充電姿勢モードが優先されるため、進行中の撮影や画像送信も停止させる必要があります。
- 撮影中止の通知先はカメラユニットではなく、ミッション制御部との通信を担当するミッションタスクです。
- 画像送信停止の通知先は地上通信ユニットではなく、地上通信タスクです。地上通信タスクが通信を管理しています。
- テレメトリ送信停止と混同しないようにします。低速ダウンリンクは衛星の姿勢にかかわらず利用できますが、画像データの送信には通信最適姿勢が必要です。
FAQ
Q: なぜ撮影と画像送信の両方を止めるのですか?
A: どちらも充電姿勢とは異なる姿勢を必要とする処理だからです。充電姿勢モードへ移る前に、進行中の処理を止めます。
A: どちらも充電姿勢とは異なる姿勢を必要とする処理だからです。充電姿勢モードへ移る前に、進行中の処理を止めます。
Q: テレメトリ送信も停止する必要がありますか?
A: この設問で求められている通知はテレメトリ送信停止ではありません。低速ダウンリンクは衛星の姿勢にかかわらず利用できる一方、画像データの送信には通信最適姿勢が必要です。
A: この設問で求められている通知はテレメトリ送信停止ではありません。低速ダウンリンクは衛星の姿勢にかかわらず利用できる一方、画像データの送信には通信最適姿勢が必要です。
Q: 姿勢管理タスクに撮影中止や画像送信停止を通知するのですか?
A: いいえ。撮影中止はミッションタスクへ、画像送信停止は地上通信タスクへ通知します。姿勢管理タスクには、これらの処理を止めた後に充電姿勢モード要求を通知します。
A: いいえ。撮影中止はミッションタスクへ、画像送信停止は地上通信タスクへ通知します。姿勢管理タスクには、これらの処理を止めた後に充電姿勢モード要求を通知します。
関連キーワード: 姿勢モード管理、タスク間通信、割込み処理、衛星通信
設問3:OTAについて答えよ。
衛星制御部のOTAは次の3ステップで実施する。
① 衛星が通信可能範囲を飛行中に、地上局は更新する衛星制御部のソフトウェア(以下、OTAデータという)を分割し、OTAコマンドとして送信する。衛星制御部は、受信したデータを情報記憶ユニット内の専用の領域に保存したのち、地上局に完了を示すコマンド応答データを送信する。地上局は、完了を受信すると次のデータを送信する。
② 地上局は、全OTAデータに対応する完了を受信すると、保存されたOTAデータの検証を衛星に指示する。衛星制御部は、検証成功又は検証失敗を地上局に応答する。
③ 地上局は、検証成功を受信すると、衛星が通信可能範囲を飛行する運用上適切な時点で、受信した新たなソフトウェアの実行を目的とした衛星制御部の再起動を指示する。
設問3(1)
問題文を見る建設現場が撮影時に衛星と地上局が通信可能な範囲に立地している場合であっても、OTAコマンド受信時に建設進捗状況の監視が阻害されないようにすることを目的として、表6中の下線(イ)で行う調停の内容を45字以内で答えよ。
模範解答
画像送信の開始後、画像送信停止までOTA処理タスクにOTAコマンドを通知しない。
解説
解答の導き方
問われているのは、OTAコマンドを受信したときに、画像データの送信を妨げないための調停です。
表6では、地上通信タスクがOTAコマンドをOTA処理タスクに通知し、OTA処理タスクはコマンド応答データの送信を要求してから、送信完了まで待機するとされています。
一方、表3では、コマンド応答データの送信時には画像データの送信を一時停止し、コマンド応答データの送信を優先するとされています。つまり、画像データを送信している最中にOTAコマンドを処理すると、その応答を送るために画像データの送信が中断される可能性があります。
画像データは高速通信範囲で送信し、その範囲の終端に達すると、残りの画像ブロックの送信が取りやめられます。そのため、画像送信中はOTAコマンドをOTA処理タスクに通知せず、画像送信停止後に処理するのが適切です。
誤りやすいポイント
- OTAコマンドを受信したら直ちにOTA処理タスクへ通知する、と考えることです。OTA処理の応答送信が画像データの送信を中断させる可能性があります。
- OTAコマンドを破棄すると考えることです。必要なのは、画像送信中の通知を控えて処理を遅らせることであり、OTAコマンドを無効にすることではありません。
- 「通信可能範囲」と「高速通信範囲」を混同することです。画像データの送信に使う高速ダウンリンクは、高速通信範囲で利用されます。
FAQ
Q: なぜOTAコマンドの応答が画像データの送信に影響するのですか?
A: コマンド応答データの送信時には、他のパケット送信を一時停止する仕様だからです。画像データを送信中にOTAコマンドを処理すると、画像送信が中断される可能性があります。
A: コマンド応答データの送信時には、他のパケット送信を一時停止する仕様だからです。画像データを送信中にOTAコマンドを処理すると、画像送信が中断される可能性があります。
Q: OTAコマンドは画像送信中に受信したら破棄するのですか?
A: いいえ。画像送信を優先するため、OTA処理タスクへの通知を画像送信停止まで遅らせます。
A: いいえ。画像送信を優先するため、OTA処理タスクへの通知を画像送信停止まで遅らせます。
Q: なぜ送信停止まで待つ必要があるのですか?
A: 画像送信が高速通信範囲の終端までに完了しないと、以降の画像ブロックの送信が取りやめられるためです。
A: 画像送信が高速通信範囲の終端までに完了しないと、以降の画像ブロックの送信が取りやめられるためです。
関連キーワード: タスク間調停、優先制御、パケット通信、データ送信制御
設問3(2)
問題文を見る衛星の軌道投入後、地上通信ユニットに障害が発生し、高速ダウンリンクの利用ができなくなった。建設進捗状況の監視を継続するために、テレメトリデータの送信を昼間の上空通過時に変更し、夜間の上空通過時に、低速ダウンリンクの通信帯域を最大限活用して、高圧縮した画像データを送信するソフトウェア(以下、低速画像送信ソフトという)を開発し、OTAを行うこととした。低速画像送信ソフトにおける、衛星制御部のタスク処理変更の概要を表7に示す。

(a) 表7中のj、kに入れる適切な内容を、それぞれ35字以内で答えよ。なお、画像データの圧縮率、データ部長及び分割データ長の設定は、地上局からのコマンドデータ送信によって変更できるものとする。
(b) 低速ダウンリンクで画像データの送信を行うため1パケットのサイズを512バイトに変更し、通信可能範囲の80%を画像データの送信に割り当てるものとした。パケットのヘッダー部のサイズは表4のままとし、画像の識別と画像ブロックのシーケンス番号の識別のために付与するメタデータのサイズはそれぞれ4バイト、ECC2は64バイトとする。送信可能な画像データの最大サイズは何Mバイトか。答えは小数第2位を切り捨てて、小数第1位まで求めよ。ここで、1Mバイトは1,000,000バイトとし、同一パケットの繰返し送信は行わないものとする。
模範解答
(a) j:画像データの送信前及び送信後に、姿勢モードの要求を通知しない。
k:通信可能範囲に入ると、通信開始及び画像送信開始を通知する。
(b):1.8
解説
解答の導き方
この設問では、高速ダウンリンクが使えなくなった後、画像データを低速ダウンリンクで送るためのタスク処理と、送信できる画像データ量を考えます。
まず、姿勢モードの要求を変更する理由を確認します。表5では、通信姿勢モードは高速通信用アンテナを地上局に向けるための姿勢として説明されています。一方、本文には「低速ダウンリンクは、衛星の姿勢にかかわらず利用できる」とあります。したがって、低速ダウンリンクで画像を送る場合は、通信の前後に通信姿勢モードへ移行する必要がありません。これが、表7のjに入る内容です。
次に、通信を始めるタイミングを考えます。表7では、テレメトリデータの送信を昼間の通信可能範囲に行うよう変更しています。また、表3では「画像データの送信時は、テレメトリデータの送信を行わない」とされています。そのため、夜間の通信可能範囲ではテレメトリデータを送らず、通信可能範囲に入った時点で通信を開始し、画像データの送信を開始します。これがkに入る内容です。
続いて、送信可能な画像データ量を計算します。1パケットのサイズは512バイトです。表4のヘッダー部は、データ種別、送信者ID、受信者ID、データ部長、分割データ長、ECC1を合わせて、
です。ECC2は64バイトで、画像の識別と画像ブロックのシーケンス番号の識別に使うメタデータは、それぞれ4バイトなので合計8バイトです。したがって、1パケットに含められる画像データは、
です。
画像データの送信に使えるのは夜間の通信可能範囲です。通信可能範囲は10分間で、その80%を画像データの送信に割り当てるので、送信時間は、
です。通信速度は38,400ビット/秒なので、この時間に送信できるパケットの総量は、
です。これは512バイトのパケットにすると、
に相当します。各パケットの画像データは420バイトなので、送信可能な画像データ量は、
です。小数第2位を切り捨てて小数第1位までにするため、求める値は1.8Mバイトです。
誤りやすいポイント
- 低速ダウンリンクでも通信姿勢モードが必要だと考えてしまう点です。低速ダウンリンクは姿勢にかかわらず利用できます。
- パケットのサイズからヘッダー部やECC2だけを差し引き、メタデータを差し引き忘れる点です。画像データとして送れるのは、これらを除いた部分です。
- 送信可能な総バイト数を、そのまま画像データ量と考えてしまう点です。総バイト数にはヘッダー部、ECC2、メタデータも含まれます。
- 1.89Mバイトを四捨五入して1.9Mバイトとする点です。この設問では小数第2位を切り捨てます。
FAQ
Q: 画像データの送信時間を10分間すべて使わないのはなぜですか。
A: 問題では、通信可能範囲の80%を画像データの送信に割り当てると指定されています。そのため、送信時間は10分間の80%です。
A: 問題では、通信可能範囲の80%を画像データの送信に割り当てると指定されています。そのため、送信時間は10分間の80%です。
Q: ECC1も512バイトから差し引くのですか。
A: はい。ECC1はヘッダー部に含まれ、ヘッダー部の合計20バイトに含めて差し引いています。
A: はい。ECC1はヘッダー部に含まれ、ヘッダー部の合計20バイトに含めて差し引いています。
Q: 1.89Mバイトが1.8Mバイトになるのはなぜですか。
A: 小数第2位を四捨五入するのではなく、切り捨てる指定だからです。
A: 小数第2位を四捨五入するのではなく、切り捨てる指定だからです。
関連キーワード: パケット通信、通信帯域、誤り訂正符号、メタデータ、データ圧縮





