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

解答の導き方

誤りやすいポイント

• バイトのまま通信速度で割らないようにします。通信速度はビット／秒なので、データ量もビットにそろえます。
• 1kビットを1,024ビットとして計算しないようにします。この問題では1kビット＝1,000ビットです。
• 時間を秒で求めた後、ミリ秒に直すために1,000を掛ける必要があります。
• 指定は「小数第3位を切り上げ」です。小数第2位で四捨五入するのではなく、指定された桁で切り上げます。

FAQ

解答の導き方

1. 品切れ情報が登録された後の処理を確認します。本文には、品切れ情報は「テーブル端末全てに送信され、該当する料理の注文の受付を中止にする」とあります。つまり、テーブル端末が品切れ情報を受け取ると、その料理は注文できなくなります。
2. 一方、注文は利用者がスマホから行い、テーブル端末を介して制御装置に送られます。したがって、品切れ情報がテーブル端末に届く前は、端末が品切れを認識しておらず、該当する料理の注文を受け付ける可能性があります。
3. 品切れ情報が登録されてから各テーブル端末に届くまでには時間差があり得ます。その間に該当する料理が注文されると、その注文はキッチン端末にも送信されてしまいます。これが、料理人が注文をキャンセルする必要が生じる場合です。

誤りやすいポイント

• 品切れ情報を登録した時点で、全てのテーブル端末が同時に品切れを認識すると思い込まないようにします。端末への情報伝達には時間差があり得ます。
• 「品切れ情報を登録した後に注文された」とだけ考えるのではなく、テーブル端末がその情報を受け取る前か後かに注目します。
• 品切れ情報を受信した後の注文受付停止と、受信前にすでに行われた注文は、別のタイミングの処理として考えます。

FAQ

解答の導き方

誤りやすいポイント

• サーバと関係するデータを扱うタスクを、すべて該当すると判断しないようにします。表2にサーバとの通信が記述されているかを確認します。
• テーブルタスクがメニュー情報を扱うことだけを根拠に、サーバ通信タスクと連携すると判断しないようにします。メニュー情報の更新はキッチンタスクがサーバと通信して行います。
• 図2でサーバ通信タスクへの矢印が省略されていても、表2の処理概要から連携するタスクを特定できます。

FAQ

解答の導き方

1. 注文キャンセル時の処理です。表2には「キッチンタスクから注文のキャンセルを受けると、a から b を削除し」とあります。注文のキャンセルによって取り除くのは、注文履歴に記録されているキャンセル対象の料理です。したがって、削除元は注文履歴情報、削除するものは該当する料理と分かります。
2. 精算完了後の通知先と通知内容です。表2では、精算処理が完了すると領収書などの印刷指示を送った上で、c に d を通知するとあります。動作概要⑨では、精算完了後に指示端末へ片付けの指示などを表示します。また表2の指示タスクは、片付け指示を受けると指示端末にその内容を表示します。このため、通知先は指示タスク、通知内容は片付け指示です。
3. 片付け完了後に空きへ戻す情報です。表2には、片付け完了の通知を受けるとeを空きに設定するとあります。テーブルタスクは、空席管理情報の自テーブルを「確保済み」に設定する処理を行います。片付け後に空席状態へ戻す対象も同じテーブルの管理情報なので、eは空席管理情報の自テーブルです。

誤りやすいポイント

• キャンセルした料理を、注文情報全体から削除すると考えないようにします。ここで削除する対象は、注文履歴情報に記録された該当する料理です。
• 精算処理を行うタスクと、片付け指示を受けて指示端末へ表示するタスクを混同しないようにします。精算完了後の片付け指示は、指示タスクへ通知されます。
• 片付け完了後に「空き」に設定するのは、テーブル番号そのものではなく、空席管理情報にある自テーブルの状態です。

FAQ

解答の導き方

1. 問われているのは、キッチンタスクが品切れ情報を受信した後の処理です。本文では、品切れ情報を受けた制御装置から「品切れ情報がテーブル端末全てに送信され、該当する料理の注文の受付を中止にする」と説明されています。したがって、各テーブル端末に品切れを反映させる必要があります。
2. 表1では、メニュー情報に「品切れの場合は、その情報」も含まれるとされています。そのため、品切れ情報を受信したら、共有しているメニュー情報を品切れ状態に更新する必要があります。
3. 表2のテーブルタスクは、「メニュー更新の通知を受けると、テーブル端末にメニュー情報を送信する」とされています。つまり、キッチンタスクがメニュー情報を更新した後、全てのテーブルタスクにメニュー更新を通知すれば、各テーブル端末へ更新後のメニュー情報が送られます。

誤りやすいポイント

• 品切れ情報を受け取った後、テーブル端末に通知するだけで、メニュー情報自体を更新しないと考えることです。テーブルタスクは、通知を受けた後にメニュー情報を送信するため、先にメニュー情報を更新しておく必要があります。
• 品切れの料理を注文できなくする対象を、一部のテーブル端末だけと考えることです。本文ではテーブル端末全てへの送信が示されているため、全てのテーブルタスクへの通知が必要です。
• キッチン端末からテーブル端末へ直接送信する処理と考えることです。表2では、キッチンタスクがテーブルタスクへ通知し、その後、各テーブルタスクがテーブル端末へメニュー情報を送信する流れです。

FAQ

解答の導き方

誤りやすいポイント

• ロボ搬送ボタンを押しただけで搬送が始まると考えないようにします。ボタンを押した後も、指示タスクとロボットタスクで条件が確認されます。
• 料理がロボに格納されていることだけでは不十分です。着座人数が0人なら、着座人数が1人以上になるまで搬送指示は通知されません。
• 着座人数が1人以上であることだけでも不十分です。ロボに料理が格納されていなければ、ロボへの搬送指示は送信されません。

FAQ

解答の導き方

1. 問われているのは、テーブル端末で料理受取が操作された後に、テーブルタスクが行う処理です。表3では、料理受取を受信すると、まずロボットタスクに通知するとあります。
2. 料理受取は、利用者がロボから料理を取り出したことを示す操作です。つまり、その料理の配膳が完了したことを確認できるタイミングです。
3. 表2では、配膳完了の通知を受けたテーブルタスクが、注文履歴情報の該当する料理を配膳済みに更新します。したがって、料理受取を受信したときにも、対応する料理の注文履歴を配膳済みに更新する処理が必要です。ロボットタスクへの通知はロボを戻すための処理であり、注文履歴の更新はテーブルタスクが担います。

誤りやすいポイント

• ロボットタスクへの通知だけを書いて終わらないようにします。設問は、通知の後にテーブルタスクが行う処理も含めて問うています。
• 料理受取を、精算や注文の受付完了と混同しないようにします。この操作が示すのは、料理が利用者に渡ったことです。
• 注文履歴情報全体ではなく、受け取られた該当する料理の状態を更新します。

FAQ

解答の導き方

1. 表3で問われているのは、ロボットタスクから「搬送のキャンセル」を受けたとき、指示タスクが搬送エラーを解除した後に行う処理です。
2. 本文の動作概要では、ロボが障害物で停止した場合、店員がロボから料理を取り出して代わりに配膳します。その後、店員がロボの搬送キャンセルボタンを押すと、指示端末に該当する料理の「配膳完了ボタン」が表示され、店員は配膳を終えてからそのボタンを押します。つまり、搬送キャンセルは料理の注文自体を取り消す操作ではなく、ロボによる搬送をやめて店員による配膳に切り替える操作です。
3. 配膳完了ボタンを押すと、既存の処理では指示タスクから該当するテーブルタスクへ配膳完了が通知されます。テーブルタスクは、その料理を注文履歴情報上で配膳済みに更新します。そのため、搬送エラーを解除するだけでなく、店員が配膳を完了したことを入力できるよう、指示端末に配膳完了ボタンを表示する処理が必要です。

誤りやすいポイント

• 「搬送キャンセル」を、料理の注文そのもののキャンセルと混同しないようにします。ここで取り消すのはロボによる搬送です。
• 搬送エラーを解除するだけでは、店員が代わりに配膳したことを記録できません。配膳完了を入力するためのボタン表示も必要です。
• ロボの搬送キャンセル後に、利用者が操作するテーブル端末ではなく、店員が操作する指示端末にボタンを表示します。

FAQ