第 1 章 — SoS とは何か
この章では、本書の題材である System of Systems（SoS）とは何か、SoS の規則を書くのになぜ専用の言語が要るのか、CADL（Contract Architecture Description Language）がそのために何を書く言語なのかを説明します。手を動かすのは第 2 章からです。
1.1 本書で何をするか
SoS とは、それぞれが独立して運用される複数のシステムが集まって、どのシステムも単独では果たせない目的を果たしている状態のことです。本書の題材は、配送ロボットの群、配送を割り当てる中央の管制（ディスパッチャ）、注文を出す顧客からなるロボット配送の SoS です。どれも独自の目的と独自のソフトウェアを持っています。シミュレーションするロボットは、小型の自律走行ロボット Raspberry Pi Mouse（ラズパイマウス） です（シミュレータの名前 cadl-raspimouse-simulator はここから来ています。実機は ROS 上で動きますが、本書はシミュレータだけで完結します）。
SoS を設計する人の仕事は、構成するシステムのコードをすべて書くことではありません。全員が従う「ゲームのルール」を決めることです。誰が誰に何を頼めるのか、何をしたら違反になるのか、違反したらどうなるのかを決めます。
本書で身に付けることは 3 つです。
- 構造を記述する：CADL で SoS の構造を書きます。誰がいて、誰が誰と何をやり取りするかです（第 4 章）。
- 規範を記述する：CADL の SoS-DSL 拡張で SoS の規範を書きます。1 件ごとの契約がいつまでに何をすべきか、違反したらどうなるかです（第 5 章）。
- 1 つの仕様から動くものを作る：同じ仕様から図、実行可能なコード、シミュレーションの設定を作り、シミュレーションの中で規範への違反が検出されるのを確かめます（第 6〜8 章）。最後に、観測した結果から仕様を直します（第 9 章）。
1.2 身近な例：食事配達アプリ
ロボット配送に入る前に、身近な SoS を 1 つ見ておきます。
| 主体 | やること | 誰が動かしているか |
|---|---|---|
| レストラン | 料理を作って渡す | 自分の店。営業時間も価格も自分で決める |
| 配達員（ギグワーカー） | 自転車やバイクで運ぶ | 自分自身。働く時間帯も自分で決める |
| プラットフォーム（アプリ） | 注文と配達員を結び付ける | アプリの会社。ただし、レストランも配達員も雇っていない |
| 顧客 | 注文し、支払う | 自分自身 |
「30 分以内に料理が届く」という全体の振る舞いを設計した人はいません。この振る舞いは、独立した主体がそれぞれの都合で動いた結果として成り立っています。独立に動くシステムが集まって、より大きな仕組みを成しているこの状態が SoS です。
1.3 SoS かどうかを見分ける：Maier の 5 条件
ある対象を SoS と呼べるかどうかは、Maier（1998）の 5 条件 [1] で判定するのが一般的です。SoS の分類そのものは、国際規格 ISO/IEC/IEEE 21841:2019 [2] で定められています。
| # | 条件 | 確かめること | 食事配達では |
|---|---|---|---|
| 1 | 運用上の独立性 | SoS 全体が止まっていても、各構成要素は単独で動くか | レストランは配達アプリがなくても店として営業できる |
| 2 | 管理上の独立性 | 各構成要素は、別の所有者や意思決定者を持つか | 配達員はギグワーカーで、アプリ会社の社員ではない |
| 3 | 地理的分散 | 構成要素は離れた場所にあり、物やエネルギーより情報をやり取りしているか | レストラン、配達員、顧客はそれぞれ別の場所にいる |
| 4 | 創発的振る舞い | 全体が、どの構成要素にも単独ではできないことをしているか | 「30 分で届く」は、誰も明示的に設計していない集団としての性質 |
| 5 | 進化的発展 | 構成要素は、SoS が使われている間に加わったり抜けたり変わったりするか | 参加する店も配達員も日々入れ替わる |
(1) と (2) は必須と考えてよく、(3)〜(5) はたいていそれに伴います。たとえば、スタッフが同じ店で働き、オーナーが全員を管理しているコーヒーショップは、(2) を満たさないので SoS ではありません。
ロボット配送に当てはめる
本書のロボット配送では、次のようになります。
- ✓ (1) 各ロボットは、配送を割り当てられていなくても自律的に動き回れる。
- △ (2) 全ロボットが同じディスパッチャを共有しているため、管理上の独立性は弱い。
- ✓ (3) ロボットはグラフ状の道路網に分散している。
- ✓ (4) 全体としての配送量は、どの 1 台も単独では生み出せない。
- △ (5) 本書のシナリオでは台数は固定だが、シミュレータは台数の増減に対応している。
(2) が弱いので、この題材は典型的な SoS というより、複数のロボットを並行して制御する問題に近いところにあります。それでも、契約でロボットの振る舞いを決める練習の題材としては扱いやすい大きさです。管理上の独立性がはっきり成り立つドメイン（たとえば食事配達）は、本書を終えたあとのコース C で扱います（第 11 章）。
1.4 SoS の 4 類型
同じ SoS でも、中央の指揮権の強さによって性質が変わります。ISO/IEC/IEEE 21841 [2] は、次の 4 類型を定めています。Maier が示した Directed、Collaborative、Virtual の 3 類型 [1] に、Dahmann と Baldwin が Acknowledged を加えたもの [3] です。
| 類型 | 中央の指揮権 | 例 |
|---|---|---|
| Directed（統率型） | 強いトップダウンで集中的に管理する | 防空ネットワーク |
| Acknowledged（認知型） | SoS 全体の指揮権が定まっているが、各構成システムは所有権と独自の管理を保つ | 国際宇宙ミッション、本書のロボット配送、大手の配車プラットフォーム |
| Collaborative（協調型） | 単一の指揮権はなく、共通の取り決め（プロトコルや規約）を介して自発的に協力する | インターネット |
| Virtual（仮想型） | 中央の管理も合意された目的もなく、調整は自然に生じる | World Wide Web、大規模災害の直後に個別に立ち上がった避難所の群れ |
本書のロボット配送の CADL ファイルは type: Acknowledged と宣言します。各ロボットを、自前の制御ソフトウェアと自律性を保ちながら、配送の割り当てについてはディスパッチャを SoS 全体の権威として認める構成システムとしてモデル化しているからです。
類型は対象そのものだけで決まるわけではありません。同じ食事配達でも、プラットフォームの指揮権に注目すれば Acknowledged、参加者の自発的な協力に注目すれば Collaborative に近いと見ることができます。また、時間とともに移ることも珍しくありません。災害の直後は Virtual に始まり、自治体の災害対策本部が動き始めると Collaborative になり、指揮権限が法的に定まれば Acknowledged に近づく、というように変わっていきます。
なお、CADL の type: は説明のためのラベルです。ツールはこれを記録し、レポートや生成する設定に書き出しますが、ファイルの他の記述と突き合わせて検査することはしません。
1.5 普通のプログラミング言語では足りない理由
SoS の規則を、C++ や Python といった普通のプログラミング言語だけで書こうとすると、次のような場面で困ります。
| 書きたいこと | 普通の言語での書き方 | 残る問題 |
|---|---|---|
| ロボットは割り当てに 5 秒以内に応答する義務がある | コメントや口頭での合意 | コードとは別の場所に書かれるので、いずれ食い違う |
| 5 秒を過ぎたら違反とする | どこかに if 文を書く | 何から数えた 5 秒か（送信した時刻か、受信した時刻か）がコードの文脈に依存する |
| バッテリが 20% 未満のロボットに新しい配送を割り当てない | 各実装に if 文を書く | 同じ規則がいくつもの場所に散らばる |
| 同じ規則を Unity と Python の 2 つのランタイムで検査したい | 言語ごとに別々に実装する | どちらかの実装が古くなる |
構成要素は独立に動き、それでも全体としては一定の規則を守らせたい、という 2 つを両立させる書き方を、普通の言語は用意していません。
1.6 CADL が補うもの
CADL は、複数のシステムが守るべき決まりを、実装コードとは別の 1 つのファイルにまとめて書くための記述言語です。ファイルは YAML の形式で書きます。
| CADL のキー | 書くこと | ロボット配送での例 |
|---|---|---|
actors: | SoS に関わる主体と、その自律性の程度 | DISPATCHER、ROBOT[1..N]、CUSTOMER[1..M] |
contracts: | 主体の間の合意（前提と保証） | 配送のサービス水準の合意 DELIVERY_SLA |
protocols: | 主体の間のやり取りの手順 | 割り当て → 受諾 → 完了の報告 |
lifecycle: | 1 件の合意がたどる状態機械 | Proposed → Assigned → Accepted → Delivering → Completed |
monitors: | 契約の実行中に見張る規則 | バッテリ残量が 20% 未満になっていないか |
この 1 つのファイルから、次のものが作られます。
- 検査の結果：
cadl checkが書き方の誤りを、cadl verifyが前提と保証の矛盾を見つけます。 - 中間表現（IR）：
cadl sim-irが、ファイルの内容を JSON に変換します。以降のツールは IR を読みます。 - 図：cadl-explorer が、IR から状態機械の図を描きます。
- コード：
cadl codegenが、IR から Unity の C# コードを生成します。 - 答え合わせ用の実行：Python 参照ランタイムが IR を直接読み込んで解釈、実行します。こちらは生成物ではありません。
どれも同じファイルから作られるので、規則を書く場所は 1 か所で済み、規則を変えるときもそのファイルだけを直せば済みます。
構造の層と規範の層
上の表の actors:、contracts:、protocols: は CADL の本体にあるキーで、SoS に何が存在するか（構造）を書きます。lifecycle: と monitors: は SoS-DSL 拡張が加えるキーで、何が起こるべきか（規範）を書きます。構造だけを書きたい場合は本体だけで足りるので、規範を一級の概念として扱う部分を拡張として分けています。拡張を使うファイルは、extensions: に sos-dsl: 0.1 と書いて宣言します。
2 つの層の書き方は第 3 章で説明し、第 4 章で構造の層を、第 5 章で規範の層を書きます。
おさらい
SoS は、独立に運用されるシステムが集まって、どのシステムも単独では果たせないことをしている状態です。Maier の 5 条件のうち運用上と管理上の独立性が要で、中央の指揮権の強さによって 4 つの類型に分かれます。本書のロボット配送は Acknowledged 型としてモデル化します。SoS の規則を実装コードの中に書くと、規則が散らばり、ランタイムごとに食い違います。CADL は規則を 1 つのファイルに書き、そこから検査、図、コード、実行を作ることでこの問題を避けます。
さらに読む
本書だけで先に進めますが、背景をさらに知りたい場合は次を参照してください。