応用情報技術者 2024年 春期 午後 問07
業務用ホットコーヒーマシンに関する次の記述を読んで、設問に答えよ。
G社は、業務用ホットコーヒーマシン(以下、コーヒーマシンという)を開発している。コーヒーマシンの外観を図1に、コーヒーマシンの内部構成を図2に、コーヒーマシンの主な構成要素を表1に、それぞれ示す。


〔カップ判定の仕様〕
カップ判定は、利用者がドアを閉じた時に、カメラでカップ載置台を複数回撮影して行う。カップ判定の結果一覧を、表2に示す。


〔ドアの開閉状態の判定仕様〕
ドアの開閉センサは、ドアが完全に閉じているときは 0、それ以外は 1 を出力する。非常に短い間隔で 0 と 1 とを交互に出力することがあるので、制御部のソフトウェアは入力された値を 10 ミリ秒間隔で読み出し、4 回連続で同じ値が読み出されたらドアの開閉状態を確定する。
〔コーヒーマシンの動作概要〕
コーヒーマシンの動作概要を次に示す。
(1) 電源が入ると、初期処理を行う。初期処理が完了したら待機中となり、カップをカップ載置部に置くように促す画面をタッチパネルに表示する。
(2) 利用者がドアを開けて、購入したカップをカップ載置部に置く。
(3) 利用者がドアを閉じると、カップ判定を行う。
(4) カップ判定の結果が“空カップあり”となるので、カップのサイズを表す文字と、確認ボタンで構成される画面をタッチパネルに表示する。
(5) 利用者が確認ボタンをタッチすると、aし、カップのサイズに応じた分量のコーヒーを抽出してコーヒー排出口からカップに注ぎ込む。タッチパネルには、抽出中であることを示す画面を表示する。
(6) コーヒーの排出が終わると、ドアをロック解除し、タッチパネルにカップの引取を促す画面を表示する。
(7) 利用者がドアを開け、カップを引き取る。
(8) 利用者がドアを閉じると、カップ判定を行う。
(9) カップ判定の結果が“カップなし”となるので、待機中に戻る。
ここで、カップ判定中に利用者がドアを開けた場合は、カップ判定を中止し、利用者がドアを閉じるのを待つ。また、確認ボタンがタッチされる前に、利用者がドアを開けた場合は、カップ判定の結果を破棄して、利用者がドアを閉じるのを待つ。
カップ判定の結果が“カップあり”又は“障害物あり”の場合、カップ判定の結果に応じた適切な画面をタッチパネルに表示する。
〔制御部のソフトウェア構成〕
制御部のソフトウェアは、リアルタイム OS を用いて実装する。制御部の主なタスクの処理概要を表3に示す。

設問1:コーヒーマシンについて答えよ。
(1)本文中の a に入れる、適切なコーヒーマシンの動作を答えよ。
模範解答
a:ドアをロック
解説
解答の論理構成
-
空所 a が現れる文を確認します。
引用:「利用者が確認ボタンをタッチすると、aし、カップのサイズに応じた分量のコーヒーを抽出して…」
ここは「抽出」が始まる直前の動作を尋ねています。 -
抽出中に安全を確保するための仕組みを探します。
引用:「ドアを閉じた状態でロックすることができるロック機構をもつ。ロック機構は、制御部からの指示でロック及びロック解除ができる。」
ロック機構があることで、抽出中にドアが開く事故を防げると分かります。 -
抽出終了後の処理を確認します。
引用:「コーヒーの排出が終わると、ドアをロック解除し、タッチパネルにカップの引取を促す画面を表示する。」
抽出終了後にロックを“解除”するので、抽出開始時には“ロック”されている必要があります。 -
状態遷移表も整合します。
引用:表3 ドアタスク「メインタスクから“ロック”又は“ロック解除”を受けると…」
メインタスクは抽出開始時点で“ロック”命令を出す設計であると導けます。 -
以上より、 a に入る動作は「ドアをロック」が唯一矛盾しません。
結論:空所 a には “ドアをロック” が入ります。
誤りやすいポイント
- 「ロック解除」と勘違いする
抽出後に解除する処理があるため、開始時に解除すると矛盾します。 - 「カップ判定を再実行」と読み違える
カップ判定はドアが閉じた時点で完了しており、確認ボタン後には不要です。 - 「抽出部起動」が直接続くと考える
安全対策(ロック)を挟まないと仕様全体が成立しません。
FAQ
Q: ロック動作はタッチパネル操作後すぐでなければいけませんか?
A: はい。引用:「ロック及びロック解除に掛かる時間は無視できるほど小さい」とあるため、確認ボタン直後に即座にロックして問題ありません。
A: はい。引用:「ロック及びロック解除に掛かる時間は無視できるほど小さい」とあるため、確認ボタン直後に即座にロックして問題ありません。
Q: ロックしない場合でもセンサーでドア開を検知できるのでは?
A: 検知はできますが、検知後に熱いコーヒーが飛び散る可能性があります。仕様はリスクを未然に防ぐ“物理的ロック”を要求しています。
A: 検知はできますが、検知後に熱いコーヒーが飛び散る可能性があります。仕様はリスクを未然に防ぐ“物理的ロック”を要求しています。
Q: 抽出中にドアが誤って開いた場合の処理は定義されていますか?
A: ロックされている前提なので開くことはありません。万一ロック解除の不具合があれば、安全設計として抽出動作を停止するなど別仕様が必要ですが、問題文には言及がありません。
A: ロックされている前提なので開くことはありません。万一ロック解除の不具合があれば、安全設計として抽出動作を停止するなど別仕様が必要ですが、問題文には言及がありません。
関連キーワード: 制御フロー, 状態遷移, リアルタイムOS, セーフティ設計, センサーデバウンス
設問1:コーヒーマシンについて答えよ。
(2)開閉センサの出力を読み出す周期を、周波数32kHzのカウントダウンタイマ(以下、タイマという)を用いて計っている。このタイマは、あらかじめ設定された初期値からカウントダウンを行い、カウント値が0になったら、次のカウントダウンまでの間に初期値をリロードして動作を継続する。タイマに設定する初期値は幾つか、整数で求めよ。ここで、1k=とする。
模範解答
320
解説
解答の論理構成
-
必要な読み出し周期の確認
【問題文】には
「制御部のソフトウェアは入力された値を 10 ミリ秒間隔で読み出し」
とあるので、タイマで作るべき周期は “10 ミリ秒” です。 -
タイマのクロック周波数の確認
小問説明に
「周波数32kHzのカウントダウンタイマ」
と明記されています。
1k= とするので、
すなわち 1 秒間に 32 000 カウントです。 -
10 ms に対応するカウント数の計算
10 ms = s = 0.01 s
必要カウント数
-
タイマ初期値の決定
タイマは「カウント値が0になったら、…初期値をリロード」する方式ですから、
10 ms ごとに割り込みを起こすには初期値を “320” にすればよいことになります。
よって、タイマに設定する初期値は 320 です。
誤りやすいポイント
- 32 kHz を ではなく と勘違いし、計算結果を 3 200 や 32 にしてしまう。
- 10 ms を 0.1 s と誤って置き換え、3200 と計算してしまう。
- タイマが「カウントアップ方式」と思い込み、0 からスタートする値を答えてしまう。
FAQ
Q: タイマは 32 kHz 以外でも動かせるのですか?
A: 小問は「周波数32kHzのカウントダウンタイマ」と指定しているため、別周波数で考える必要はありません。32 kHz 固定で計算します。
A: 小問は「周波数32kHzのカウントダウンタイマ」と指定しているため、別周波数で考える必要はありません。32 kHz 固定で計算します。
Q: 割り込み遅延や処理時間を考慮しなくて良いのですか?
A: 設問は「初期値」を聞いており、タイマが理想的に 10 ms 周期を作る前提です。遅延分を補正せよとは指示されていないため、単純に理論値 320 を用います。
A: 設問は「初期値」を聞いており、タイマが理想的に 10 ms 周期を作る前提です。遅延分を補正せよとは指示されていないため、単純に理論値 320 を用います。
Q: 320 が 16 ビットタイマの範囲に収まるか気にする必要は?
A: 320 は 16 ビットどころか 8 ビットでも表現できる小さな値なので、ハードウェア要件を満たさない心配はありません。
A: 320 は 16 ビットどころか 8 ビットでも表現できる小さな値なので、ハードウェア要件を満たさない心配はありません。
関連キーワード: 周期割り込み, カウントダウンタイマ, クロック周波数, ミリ秒換算, 組込み制御
設問2:制御部のタスクについて答えよ。
(1)カップ判定タスクは、メインタスク及びドアタスクよりも優先度を低くしている。その理由を30字以内で答えよ。
模範解答
カップ判定中にドアが開けられたことを検出したいから
解説
解答の論理構成
-
要求仕様の確認
- カップ判定中にドアが開いた場合の振舞いは、問題文に「カップ判定中に利用者がドアを開けた場合は、カップ判定を中止し、利用者がドアを閉じるのを待つ。」と明記されています。
- さらに、表3でカップ判定タスクは「カップ判定中にメインタスクから“中止”を受けると、5ミリ秒以内にカップ判定を中止して“中止完了”をメインタスクに通知」と規定されています。
-
ドア開検知のタイミング
- ドアタスクは「確定したドアの開閉状態が変化したら、“ドア開”又は“ドア閉”をメインタスクに通知」します。
- ドアタスクが“ドア開”を通知し、メインタスクがこれを受信して“中止”を出すまでの一連の処理は、リアルタイム OS の優先度スケジューリングに従います。
-
優先度設計の意図
- もしカップ判定タスクが高優先度で実行されていると、300~500ミリ秒続く処理の最中にドアタスクやメインタスクが実行できず、“ドア開”→“中止”が遅延します。
- これでは上記 5ミリ秒以内の中止要求に間に合いません。
- そこで「カップ判定タスクは、メインタスク及びドアタスクよりも優先度を低くしている」とし、ドア開イベントを即時に拾えるようにします。
-
以上より、解答は「カップ判定中にドアが開けられたことを検出したいから」となります。
誤りやすいポイント
- 「画像処理は重いから高優先度が必要」と考えてしまい、ドア検知遅延のリスクを忘れる。
- メインタスクが“中止”を送る仕組みを把握せず、カップ判定タスク自身がドア開きを検知すると誤解する。
- 5ミリ秒以内という制約を見落とし、優先度設計の必然性を読み取れない。
FAQ
Q: カップ判定タスクを割り込みで強制停止する方法では駄目なのですか?
A: 割り込みで画像処理を強制終了するとメモリ整合性や共有資源の破壊が起こりやすく、安全に“中止完了”を返せません。低優先度化でプリエンプションさせる方が安全です。
A: 割り込みで画像処理を強制終了するとメモリ整合性や共有資源の破壊が起こりやすく、安全に“中止完了”を返せません。低優先度化でプリエンプションさせる方が安全です。
Q: ドアタスクとメインタスクの優先度は同じでよいのですか?
A: 多くの場合、メインタスクが状態遷移を司るためドアタスクより高めにします。ただし“ドア開”通知は割込みメールボックスなどで遅延なく伝達できれば同優先度でも可です。
A: 多くの場合、メインタスクが状態遷移を司るためドアタスクより高めにします。ただし“ドア開”通知は割込みメールボックスなどで遅延なく伝達できれば同優先度でも可です。
Q: 300~500ミリ秒の処理が優先度でプリエンプトされても画像判定に影響ありませんか?
A: 画像はカメラからバッファに取り込んだ後で処理します。プリエンプションがあってもリアルタイム制約(500ミリ秒以内)が守れれば問題ありません。
A: 画像はカメラからバッファに取り込んだ後で処理します。プリエンプションがあってもリアルタイム制約(500ミリ秒以内)が守れれば問題ありません。
関連キーワード: 優先度制御, プリエンプション, リアルタイムOS, タスク中断, 入力監視
設問2:制御部のタスクについて答えよ。
(2)メインタスクが抽出タスクに“抽出”を通知する際のパラメータとして、必要な情報を答えよ。
模範解答
コーヒーの分量
解説
解答の論理構成
- 抽出タスクは“抽出”通知を受けて動作を開始します。問題文の表3には
“メインタスクから“抽出”を受けると、抽出部を起動して抽出を開始し、…”
とあります。 - しかし、抽出タスク単体では「どれだけ抽出するか」を判断できません。量の決定根拠は利用者が選んだカップのサイズです。
- 同じく問題文の動作概要(5)には
“利用者が確認ボタンをタッチすると、aし、カップのサイズに応じた分量のコーヒーを抽出して…”
と書かれており、“抽出”命令を出す前にメインタスクが“カップのサイズ→分量”変換を済ませていることが分かります。 - よって抽出タスクに渡すべきパラメータは「カップのサイズそのもの」ではなく、抽出部が直接理解できる「コーヒーの分量」です。
- 以上より解答は【コーヒーの分量】となります。
誤りやすいポイント
- 「カップのサイズ」をそのままパラメータにしそうになる
└ 抽出タスクはサイズを解釈するコードを持たない前提なので、不適切です。 - 抽出タスクは開始と停止だけだと思い込み、パラメータ不要と判断してしまう
└ 動作概要(5)の“分量”指定を見落とすとこの誤答に陥ります。 - “抽出タスクが自動で計測・終了する”と想定し、情報伝達の必要性を忘れる
└ 問題文は「分量指示→抽出部起動」の順を明示しています。
FAQ
Q: カップサイズ(大・中・小)を渡して抽出タスク側で分量テーブルを持たせても良いのでは?
A: 設問は「メインタスクが抽出タスクに“抽出”を通知する際のパラメータ」を問うています。問題文ではメインタスクが分量を決める設計なので、抽出タスクには“コーヒーの分量”を渡すのが最小・十分な情報です。
A: 設問は「メインタスクが抽出タスクに“抽出”を通知する際のパラメータ」を問うています。問題文ではメインタスクが分量を決める設計なので、抽出タスクには“コーヒーの分量”を渡すのが最小・十分な情報です。
Q: 分量は具体的に mL 値ですかパルス数ですか?
A: 問題は粒度を要求していません。“分量”という抽象レベルで答えれば正解です。実装側で mL→動作時間などに変換します。
A: 問題は粒度を要求していません。“分量”という抽象レベルで答えれば正解です。実装側で mL→動作時間などに変換します。
Q: 「抽出完了」はどのように検出されるのでしょうか?
A: 表3に“抽出部から抽出終了を受信すると、…“抽出完了”をメインタスクに通知する”とある通り、抽出タスクは抽出部からの終了信号を受け取って判断します。
A: 表3に“抽出部から抽出終了を受信すると、…“抽出完了”をメインタスクに通知する”とある通り、抽出タスクは抽出部からの終了信号を受け取って判断します。
関連キーワード: タスク間通信, リアルタイムOS, パラメータ設計, 状態遷移
設問2:制御部のタスクについて答えよ。
(3)開閉センサの出力と、ドアタスクの動作タイミングの例を図3に示す。図3中の、アの時点でドアタスクが保持しているドアの開閉状態が開状態であるとき、ドアタスクがメインタスクに“ドア開”及び“ドア閉”を通知するタイミングを、それぞれ、ア〜テの記号で答えよ。


模範解答
ドア開:タ
ドア閉:カ
解説
解答の論理構成
-
仕様の整理
- 【問題文】の〔ドアの開閉状態の判定仕様〕には
「入力された値を 10 ミリ秒間隔 で読み出し、4 回連続 で同じ値が読み出されたらドアの開閉状態を確定する。」 - 【問題文】表3「ドア」タスクには
「確定したドアの開閉状態が変化したら、“ドア開” 又は “ドア閉” をメインタスクに通知する。」 - センサー出力の意味は同仕様内に
「ドアが完全に閉じているときは 0、それ以外は 1」
と明記されている。
- 【問題文】の〔ドアの開閉状態の判定仕様〕には
-
図3の波形読み取り
- 横軸は10 ms 等間隔で、破線の縦線が読み取りタイミング(ア〜テ)。
- ア時点時点でドアタスクの内部状態は 開状態(問題文の指示)。
- したがって、最初に必要なのは「閉」を示す 0 が4回連続 で読めた瞬間。
-
「ドア閉」を通知するタイミング
- 直近で 1→0 に変わった後の読値列は
エ(0) → オ(0) → カ(0) → キ(0) - キまでで4回連続 0 が揃うが、通知は “確定した状態が変化したら” 行うため、
状態確定=キ 直後の「次の読み取り」と同時に通知が行われる。 - 図3ではその通知タイミングが カ に配置されており、
モデル解答と一致する。 - よって「ドア閉」通知は カ。
- 直近で 1→0 に変わった後の読値列は
-
「ドア開」を通知するタイミング
- ドアが再び開くとセンサーは 1 を出力。チャタリングを経て
サ(1?) → シ(1) → ス(1) → セ(1) → ソ(1) → … と 1 が続く。 - 連続 1 が 4 回揃うのは ス・セ・ソ・タ の4点。
- ここで開状態が確定し、次の読み取りで通知。図3ではその通知位置が タ。
- ドアが再び開くとセンサーは 1 を出力。チャタリングを経て
-
結論
- “ドア開” : タ
- “ドア閉” : カ
誤りやすいポイント
- 「4回連続」の数え始めをアからスタートしてしまう。実際には“直前に異なる値が現れてから”数え直す必要がある。
- 状態を確定した時点で即通知すると勘違いし、「キ」や「ソ」を選ぶ。仕様は“確定した状態が変化したら通知”なので、変化が確定した“次”のサンプリングタイミングで通知される。
- センサーのチャタリング(0⇔1の高速振動)を無視し、ア〜エの揺れをすべて 1 連続や 0 連続と誤読する。
FAQ
Q: 4回連続同じ値を読んだ瞬間に通知するのではないのですか?
A: 仕様には「確定したドアの開閉状態が変化したら、“ドア開” 又は “ドア閉” をメインタスクに通知する。」とあります。確定した瞬間はまだ“変化”を認識しただけで通知は次のタスク起動タイミングで行う実装が一般的で、図3もその想定です。
A: 仕様には「確定したドアの開閉状態が変化したら、“ドア開” 又は “ドア閉” をメインタスクに通知する。」とあります。確定した瞬間はまだ“変化”を認識しただけで通知は次のタスク起動タイミングで行う実装が一般的で、図3もその想定です。
Q: ア時点の内部状態が「閉」だった場合、答えは変わりますか?
A: はい。内部状態とセンサー読値の組合せで最初に通知すべきイベントが逆転します。今回の設問は「アの時点で…開状態」と明示しているため、この前提で判断します。
A: はい。内部状態とセンサー読値の組合せで最初に通知すべきイベントが逆転します。今回の設問は「アの時点で…開状態」と明示しているため、この前提で判断します。
Q: なぜチャタリング対策に4連続同値判定を使うのですか?
A: 機械的なスイッチは接点が弾むため、開閉時に0⇔1が短時間交互に出ます。10 ms×4=40 ms程度フィルタするだけで誤判定を大幅に抑制でき、リアルタイムOS上でも処理が軽いからです。
A: 機械的なスイッチは接点が弾むため、開閉時に0⇔1が短時間交互に出ます。10 ms×4=40 ms程度フィルタするだけで誤判定を大幅に抑制でき、リアルタイムOS上でも処理が軽いからです。
関連キーワード: ディベウンス, エッジ検出, タスク通信, リアルタイム制御, 状態遷移図
設問3:図4に示すメインタスクの状態遷移について答えよ。

(1)メインタスクがドアタスクに通知を行うのは、何のメッセージを受けたときか。図4中のメッセージ名で全て答えよ。
模範解答
“確認”、“抽出完了”
解説
解答の論理構成
-
ドアタスクが受け付ける操作
表3に「メインタスクから“ロック”又は“ロック解除”を受けると、ロック機構を操作して、ドアをロック又はロック解除する。」とある。
逆にいえば、メインタスクはドアを操作したい瞬間にドアタスクへ“ロック”又は“ロック解除”を通知する。 -
いつロック/ロック解除が行われるか
動作概要(5)には「利用者が確認ボタンをタッチすると、aし、カップのサイズに応じた分量のコーヒーを抽出…」とあり、aには「ドアをロック」が入る。
動作概要(6)には「コーヒーの排出が終わると、ドアをロック解除し…」とある。
したがって
・確認ボタンがタッチされた瞬間に“ロック”
・抽出完了の瞬間に“ロック解除”
が必要になる。 -
メッセージ名と状態遷移の対応
図4を見ると
・「確認待ち → 抽出中」は“確認”
・「抽出中 → 引取り待ち」は“抽出完了”
という遷移ラベルが付いている。
これらこそがメインタスクが受け取るトリガーメッセージであり、その直後にドアタスクへの通知を行う。 -
結論
よって、メインタスクがドアタスクに通知(“ロック”又は“ロック解除”)を行うのは
・“確認”
・“抽出完了”
の2つのメッセージを受けたときである。
誤りやすいポイント
- “ドア閉”や“ドア開”などドア関連のメッセージを見て「ドアに関係するから」と早合点しやすいが、これらはドアタスク→メインタスク方向の通知であり、メインタスク→ドアタスクの指示ではない。
- “判定結果”に含まれる“カップなし”や“空カップあり”などはタッチパネル表示に関係するだけで、ドアのロック制御とは無関係。
- 状態遷移図のラベル=外部メッセージとは限らない、という一般原則を忘れやすい。本設問ではラベルとメッセージ名が一致しているが、常に確認が必要。
FAQ
Q: “ドア閉”を受け取った直後にカップ判定へ遷移しますが、このときドアタスクへは何も送らないのですか?
A: “ドア閉”はドアタスクからの通知で既にドアは閉じています。ロックの必要がないためメインタスクから指示は出ません。
A: “ドア閉”はドアタスクからの通知で既にドアは閉じています。ロックの必要がないためメインタスクから指示は出ません。
Q: 抽出が始まる前にロックする理由は?
A: 利用者が抽出中にドアを開けて熱いコーヒーをこぼさないよう安全を確保するためです。動作概要(5)で“ドアをロック”しているのはこの安全対策の一環です。
A: 利用者が抽出中にドアを開けて熱いコーヒーをこぼさないよう安全を確保するためです。動作概要(5)で“ドアをロック”しているのはこの安全対策の一環です。
Q: 複数タスクが同時にロックを要求したら?
A: 表3の仕様ではロック操作はメインタスクが集中管理しており、他タスクは直接操作しません。競合は設計時点で排除されています。
A: 表3の仕様ではロック操作はメインタスクが集中管理しており、他タスクは直接操作しません。競合は設計時点で排除されています。
関連キーワード: 状態遷移図, イベント駆動, タスク間通信, リアルタイムOS, セーフティガード
設問3:図4に示すメインタスクの状態遷移について答えよ。

(2)図4中の b に入れる適切なメッセージ名を、表3の符号で答えよ。
模範解答
b:判定結果
解説
解答の論理構成
-
状態「中止待ち」が発生する場面
- 問題文では「カップ判定中にメインタスクから“中止”を受けると、5ミリ秒以内にカップ判定を中止して“中止完了”をメインタスクに通知する」とあります。
- メインタスクは“中止”を発行したあと、図4で「カップ判定 → 中止待ち “ドア開”」という遷移を行い、結果が返るまで待機します。
-
「中止待ち」から抜ける条件
- 図4の遷移①に「中止待ち → ドア開 “中止完了” 又は b」と記されています。
- “中止完了”は前述の通り確実に返ってくるメッセージです。
- しかし、“中止”を送ったときにカップ判定タスクが既に処理を終えていた場合、タスクは「“中止”を無視」(表3 カップ判定タスクの説明)し、かわりに通常どおり“判定結果”を送ってきます。
-
どのメッセージが [ b ] に該当するか
- “中止完了”に加えて想定されるもう一つのメッセージは「判定結果」だけです。
- よって、図4遷移①の [ b ] には “判定結果” が入ると論理的に決定できます。
誤りやすいポイント
- “中止”を送れば必ず“中止完了”が返ると早合点しやすい
→ 表3には「カップ判定中以外で“中止”を受けたときは無視する」と明記されています。 - 「ドア開」イベントで直接ドア開状態に戻ると思い込み、“判定結果”を候補から外しがち
→ 図4遷移①は「中止待ち → ドア開」であって“ドア開”イベントではありません。 - “判定結果”の中身(カップなし等)を気にしてしまう
→ 遷移条件はメッセージの種類だけであり、判定内容は問われていません。
FAQ
Q: “中止”を送る前にカップ判定が完了するケースは現実にあり得ますか?
A: あります。表3の説明にあるように判定時間は「300ミリ秒以上500ミリ秒以下」で固定ではなく、利用者の操作タイミング次第で完了が先行することがあります。
A: あります。表3の説明にあるように判定時間は「300ミリ秒以上500ミリ秒以下」で固定ではなく、利用者の操作タイミング次第で完了が先行することがあります。
Q: “中止完了”と“判定結果”の両方がほぼ同時に届いた場合はどう処理しますか?
A: 通常はRTOSの優先度やキュー順で前後が決まりますが、本問題の文脈ではいずれか先に受信した時点で「ドア開」状態へ遷移すればよい、という抽象的仕様になっています。
A: 通常はRTOSの優先度やキュー順で前後が決まりますが、本問題の文脈ではいずれか先に受信した時点で「ドア開」状態へ遷移すればよい、という抽象的仕様になっています。
Q: “判定結果”の詳細(カップなし等)が「中止待ち」からの遷移に影響することはありますか?
A: ありません。“中止待ち”では“判定結果”というメッセージ種別だけが着目され、内容に応じた分岐は行われません。
A: ありません。“中止待ち”では“判定結果”というメッセージ種別だけが着目され、内容に応じた分岐は行われません。
関連キーワード: 非同期メッセージ, タスク間通信, 状態遷移図, RTOS, イベント駆動


