エンベデッドシステムスペシャリスト 2016年 午後1 問02

解答の導き方

1. 問われているのは、PCから受信する営業情報のうち、料理ごとに必要な情報です。料理の名称、単価、販売可能数は除くので、初期化時に受信する情報の一覧から、それ以外の料理ごとの情報を探します。
2. 本文では、営業情報として「販売する料理の名称、単価、販売可能数、メニューボタンの配置位置、料理の種別」などを受信すると説明されています。このうち、料理ごとに必要な情報で、設問で除外されている三つに当たらないのは、画面上で料理のボタンを置く位置と、その料理の種別です。
3. 料理の種別は、調理を担当する厨房を判断するために必要です。本文には、料理の種別ごとに対象となるキッチンプリンタの情報を受信し、購入された料理の調理を担当する厨房のキッチンプリンタに注文伝票を印字させるとあります。したがって、料理ごとの種別が分かれば、対応するキッチンプリンタを選べます。
4. メニューボタンの配置位置は、注文中画面で各料理のボタンをどこに表示するかを決めるために必要です。料理の名称や単価だけでは、ボタンの表示位置までは決まりません。
5. 一方、注文番号の初期値は料理ごとの情報ではなく、注文番号を管理するための情報です。また、キッチンプリンタの情報は料理ごとではなく、料理の種別ごとに対応付けられています。以上から、求める二つの情報は「料理の種別」と「メニューボタンの配置位置」です。

誤りやすいポイント

• 「種別ごとに対象となるキッチンプリンタの情報」を、料理ごとの情報として選ばないようにします。本文では、プリンタ情報は料理の種別に対応付けられています。
• 注文番号の初期値も営業情報の一部ですが、個々の料理に必要な情報ではありません。
• 名称、単価、販売可能数は設問で除外されています。受信する情報の一覧から、残りの項目を問われている観点に沿って絞り込みます。

FAQ

解答の導き方

誤りやすいポイント

• 販売可能数が０になると確定ボタンも反応しなくなる、と考えないようにします。確定ボタンが反応するかどうかは、購入候補リストが空かどうかで決まります。
• すべてのメニューボタンが反応しない状態と、購入候補リストが空の状態は別です。選択済みの料理がリストにあれば、確定ボタンは反応します。
• 取消ボタンは、販売可能数や購入候補リストの内容にかかわらず、注文を取り消す操作に使われます。

FAQ

解答の導き方

誤りやすいポイント

• 1バイトを8ビットとして計算しないようにします。この設問では「1バイトは10ビット」と指定されています。
• 100kビット/秒は、指定どおり$100\times 10^3=100,000$ビット/秒として計算します。
• ユニットの500マイクロ秒の処理時間は、各ユニットの応答データを送る前に発生するため、3台分を加えます。
• 制御部の100マイクロ秒の処理時間は、次のユニットへの送信前に発生します。最後のユニットの受信後には次のユニットがないため、加えるのは2回分です。

FAQ

解答の導き方

• 料理を選ぶときにタッチするのはメニューボタンです。図5の[ア]はメニューボタンの分岐です。
• 注文を確定するときにタッチするのは確定ボタンです。図5の[イ]は確定ボタンの分岐です。
• 注文を取り消すときにタッチするのは取消ボタンです。図5の[ウ]は取消ボタンの分岐です。

誤りやすいポイント

• [エ]には、料理の名称や購入数だけでなく、表2で更新対象とされている購入候補リストと合計金額を入れます。
• 現金を取り込んだ後に待つのは、現金出納ユニットからの排出完了通知ではありません。まず入金金額が合計金額以上になるのを待ち、釣銭を排出した場合に、その排出完了通知を待ちます。
• 取消しでは注文を終了するだけではありません。選択時に更新した販売可能数を元に戻す処理が必要です。

FAQ

解答の導き方

1. 図4では、営業情報がメモリを介して制御タスクと注文タスクの間で共有されています。表3によると、注文タスクは販売可能数を管理し、制御タスクは注文動作の終了を待ちます。このため、注文が終わると、販売可能数を更新した後の営業情報を制御タスクが確認できます。
2. 次に、確認するタイミングを考えます。表3には、制御タスクは注文動作が終了した時に、全ての料理の販売可能数が0なら営業終了状態に遷移するとあります。したがって、制御タスクが営業情報を読み出すのは、注文タスクから注文動作の終了が通知されたときです。
3. 読み出す理由は、販売可能数を確認し、待機中状態に戻るか、営業終了状態に遷移するかを判断するためです。全ての料理の販売可能数が0でなければ待機中状態に、0なら営業終了状態に遷移します。

誤りやすいポイント

• PCから営業情報を受信する初期化中のタイミングと、初期化中以外で営業情報を読み出すタイミングを混同しないようにします。
• 注文動作の開始時ではなく、注文タスクから終了が通知された後に読み出します。販売可能数の更新を反映して、次の状態を判断するためです。
• 注文が終われば必ず営業終了状態になるわけではありません。全ての料理の販売可能数が0の場合に限って営業終了状態へ遷移します。

FAQ

解答の導き方

誤りやすいポイント

• 販売可能数が1から0になる更新まで不可と考えないようにします。0になるのは、1から1を減らした結果なので有効です。
• 注文画面に表示された販売可能数だけで判断しないようにします。複数台では、別の券売機で先に販売され、表示が最新でない可能性があります。
• 問われているのは、販売可能数を増やす場合や注文を取り消す場合ではなく、販売可能数の減算を依頼された場合の判断です。

FAQ

解答の導き方

1. 表4中の下線②と表5中の下線③では、注文動作中に制御タスクから販売可能数の更新を受信したとき、注文中画面を更新する処理が追加されています。したがって、注文タスクは利用者の操作を待っている間にも、制御タスクからの更新メッセージを受け取れる必要があります。
2. 図5では、注文タスクが注文中画面の更新指示を送信した後、タッチパネルタスクからボタン情報が送信されるのを待ちます。これが、変更前に注文タスクが待っていた情報です。
3. 表3には、タッチパネルタスクが操作表示ユニットから通知された操作情報をボタン情報として注文タスクに送信するとあります。つまり、利用者のタッチ操作はタッチパネルタスクを介して注文タスクに伝わります。

誤りやすいポイント

• 操作表示ユニットからの通知を、そのまま注文タスクが受信すると考えないようにします。操作情報はタッチパネルタスクがボタン情報として注文タスクへ送信します。
• シリアル通信タスクはユニットとの通信を担当しますが、図5で注文タスクが待つ情報は、タッチパネルタスクからのボタン情報です。
• 今回追加する制御タスクからのメッセージと、変更前から待っていたメッセージを混同しないようにします。問われているのは、変更前に待っていた情報です。

FAQ

解答の導き方

誤りやすいポイント

• 親機の注文タスクが注文番号を直接管理すると考えないようにします。表4では、注文番号を管理するのは制御タスクです。
• 子機から制御タスクへ直接依頼するわけではありません。表5では、子機の注文タスクは親機に注文を通知する構成です。
• 求められているのは、注文番号そのものではなく、注文番号を取得する処理と、その依頼先です。

FAQ