応用情報技術者 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し、カップのサイズに応じた分量のコーヒーを抽出して…」
ここは「抽出」が始まる直前の動作を尋ねています。 -
抽出中に安全を確保するための仕組みを探します。
引用:「ドアを閉じた状態でロックすることができるロック機構をもつ。ロック機構は、制御部からの指示でロック及びロック解除ができる。」
ロック機構があることで、抽出中にドアが開く事故を防げると分かります。 -
抽出終了後の処理を確認します。
引用:「コーヒーの排出が終わると、ドアをロック解除し、タッチパネルにカップの引取りを促す画面を表示する。」
抽出終了後にロックを“解除”するので、抽出開始時には“ロック”されている必要があります。 -
以上より、 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中の、アの時点でドアタスクが保持しているドアの開閉状態が開状態であるとき、ドアタスクがメインタスクに“ドア開”及び“ドア閉”を通知するタイミングを、それぞれ、ア〜テの記号で答えよ。


模範解答
ドア開:タ
ドア閉:カ
解説
解答の導き方
- 判定と通知の仕様を確認する
【問題文】の〔ドアの開閉状態の判定仕様〕に「ドアが完全に閉じているときは0、それ以外は1を出力する。」「入力された値を10ミリ秒間隔で読み出し、4回連続で同じ値が読み出されたらドアの開閉状態を確定する。」とあります。
表3のドアタスクには「確定したドアの開閉状態が変化したら、“ドア開”又は“ドア閉”をメインタスクに通知する。」とあります。つまり、4回連続で同じ値を読み、その値が今保持している状態と違うときに、その時点で通知します。 - 図3の各時点で読み出される値を拾う
ドアタスクが値を読むのは破線の時点だけです。図3を読むと、次のようになります。
ア=1、イ=1、ウ=0、エ=0、オ=0、カ=0、キ〜コ=0、サ=1、シ=0、ス=1、セ=1、ソ=1、タ=1
ウとエの間にある短い1のパルスは、どの破線とも重ならないので読み出されません。 - “ドア閉”のタイミング
アの時点で保持している状態は開状態です。ア・イは1なので状態は変わりません。ウから0が続き、ウ・エ・オ・カで4回連続の0になるので、カで閉状態に確定します。開から閉に変化したので、カで“ドア閉”を通知します。 - “ドア開”のタイミング
その後、コまでは0が続くので閉状態のままです。サで1が読まれますが、シで0に戻るため連続は途切れます。ス・セ・ソ・タで4回連続の1になるので、タで開状態に確定し、閉から開に変化したのでタで“ドア開”を通知します。 - したがって解答は「ドア開:タ、ドア閉:カ」です。
誤りやすいポイント
- ウとエの間の短いパルスで数え直してしまい、エから数えて「キ」と答える。ドアタスクは破線の時点でしか読み出さないので、このパルスは判定に影響しません。
- サの1から数え始め、シの0を見落として「ソ」と答える。シで0が読まれた時点で1の連続は途切れ、スから数え直しになります。
- アやイの時点で“ドア開”を通知すると考える。アの時点で既に開状態を保持しているので、1が続いても状態は変化せず、通知はしません。
FAQ
Q: 4回目の同じ値を読んだ時点で通知するのですか?
A: はい。4回連続で同じ値が読み出された時点で状態が確定し、確定した状態が保持している状態から変化していれば、その時点で通知します。確定の次の読み出しまで待つ仕様ではありません。
A: はい。4回連続で同じ値が読み出された時点で状態が確定し、確定した状態が保持している状態から変化していれば、その時点で通知します。確定の次の読み出しまで待つ仕様ではありません。
Q: なぜ1回の読み出しで判定せず、4回連続を条件にするのですか?
A: 【問題文】に「非常に短い間隔で0と1とを交互に出力することがある」とあるように、開閉センサーの出力は切り替わり時に揺れ動く(チャタリング)ことがあるためです。4回連続で同じ値を読むことを条件にすると、揺れによる誤った“ドア開”“ドア閉”の通知を防げます。
A: 【問題文】に「非常に短い間隔で0と1とを交互に出力することがある」とあるように、開閉センサーの出力は切り替わり時に揺れ動く(チャタリング)ことがあるためです。4回連続で同じ値を読むことを条件にすると、揺れによる誤った“ドア開”“ドア閉”の通知を防げます。
関連キーワード: チャタリング、デバウンス、ポーリング、リアルタイム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, イベント駆動




