前の一編は複数の装置が一つの画面にまとまる話だった。この一編は逆方向だ。一つの装置が複数の画面として開く。
操舵室に戻る
装置 (MCPサーバー + 画面の記述)
├── 操舵室コンソール → 制御権すべて
├── 機関室端末 → 一部制御 + 詳細計器
├── 船長タブレット → ダッシュボード + アラーム
└── 個人の携帯 → 状態閲覧のみ同じ設備だ。つないだ場所ごとに違うものが開く。
ここで大事なのは チャネルごとに違う画面ではなく チャネルごとに違う権限等級の画面だという点だ。携帯で弁のボタンが隠れているのではなく、その画面には最初からそのボタンがない。
そしてその等級を決めるのは 装置を記述する側だ。装置が画面の主なのだから、誰に何を見せ何を触らせるかも装置が決める。
この雑誌にすでにその形のサンプルがある。一つのサーバーが、つないだ機器に応じてキオスク画面、レジ画面、厨房画面をそれぞれ渡す。三つの画面は互いに違い、アプリは一組だ。
検証の主体が変わらない
これが安全上重要な領域で決定的になる。
船舶や重機が外部ソフトウェアを入れない理由は性能ではない。責任の所在だ。事故が起きたら誰が責任を負うのか。だから制御権を外へ渡す構造は、検討される前にふるい落とされる。
この構造で何が渡るのかを見れば答えが出る。渡るものがない。
装置メーカーが 規格に従って自分の手で移植し、自分でチャネル別の等級を決める。画面の記述もそちらのもの、道具もそちらのもの、何を出すかもそちらが決める。こちらが提供するのは規格と、それを描くランタイムだ。
外へ制御権を渡さずに画面を開ける。 そして検証の主体がそのままだ。もともとその設備を検証していた組織が引き続き検証する。
中から何も持ち出さず、責任の位置が動かない。
専用アプリをつくらない
副次的な自由がついてくる。
- 既存のダッシュボードはそのままでよい
- 車両の前にモニターをもう一枚付けてもよい
- 居間のTVで状態だけ見てもよい
- タブレット用・スマートフォン用アプリを別につくらない
最後のものが実務でいちばん大きい。これまで設備会社が顧客にモバイル画面を渡そうとすれば、アプリ開発プロジェクトを一つ立てる以外に方法がなかった。つくり、審査を受け、二つのプラットフォームを維持し、設備が変わればまたやる。
ここではチャネルが一つ増えるだけだ。記述は同じで等級だけ違う。
画面はつなぐ窓であって、機能は装置にある。
等級を決める側
一つのサーバーがつないだ場所に応じて違う画面を渡すことはサンプルで確認した。
等級をいくつに分けるか、どの席に何を開くかは、この構造が決めるのではない。その装備をつくった側が決める。 操舵室に制御権すべてを渡し甲板には通知だけ渡すのも、その逆も、同じ一行の記述で分かれる。
等級は装置が決め、画面はその決定に従って描かれる。決定そのものは装置の外に出ない。
makemind.dev 「探索」— 一つのサーバーがつないだ場所に応じて三つの画面を渡すのはサンプルで確認した。