概念モデリングチュートリアル ～ ビル管理

本ドキュメントの利用は、https://github.com/kae-made/kae-made/blob/main/contents-license.md に記載のライセンスに従ってご利用ください。

https://github.com/kae-made/kae-made/blob/main/contents-license.md

はじめに

このチュートリアルは、「Azure の最新機能で IoT を改めてやってみる」とコラボしたものです。
このマガジンの例として使っている、Microsoft Docs の Azure Digital Twins の解説の例もこのテーマを使っている、なんとなく需要もありそうなので、”ビル管理” をテーマに、

1. ビジネスシナリオを元にした概念モデル構築

2. 概念モデルからの必要な構成物の生成

3. Azure IoT Hub、Azure Digital Twins による実装

までをチュートリアル形式で解説していきます。
概念モデリングは、デジタルトランスフォーメーション、デジタルツインの実践においては必須の作業です。概念モデリングの重要性については、「ビジネスシステムにおける概念モデルの重要性」をご覧ください。
この記事は、最初から全てを記載した記事として公開するものではありません。「Azure の最新機能で IoT を改めてやってみる」での技術検証・確認の進捗に合わせて、説明を追加していく予定です。
記載する内容によっては、途中から有償とさせていただく可能性もありますが、ご了承くださいませ。

リファレンス

このチュートリアルは、以下のドキュメント群の解説を元にしています。先に読んでねとは言いませんが、必要に応じて合わせて解読していくと、理解度が増します。

• 「Art of Conceptual Modeling」 ～ 概念モデリングの基礎

• 「ビジネスをモデル化する ～ BridgePoint を使ってみよう」 ～ 概念モデリングツールの BridgePoint の使い方

• 「概念モデリングチュートリアル集」 ～ その他のチュートリアル

• 「Technique of Transformation」 ～ 変換による実装の技法解説

概念モデルを作る

では、さっそく概念モデルを作っていきます。
…とその前に…

ビジネスシナリオの定義

概念モデルは、何をモデル化するのか、その”ドメイン（主題領域）”の概要が必要です。ここでは、最近流行りの、デジタルツインやデジタルトランスフォーメーション、SDGs 等の要素を加味して、

1. 複数のビルの各部屋に設置された空調設備の管理を通じて

2. 空調設備、及び、設置された部屋の環境をリアルタイムで把握し

3. 部屋ごとに契約している顧客の満足度の最大化

4. 空調設備の電力量の最適化による CO2削減

を行うソリューションを構築するものとします。非常に観念的で曖昧なテキストですが、当初はこのレベルで構いません。
テキストだけだと、脳味噌への刺激が足りないので、絵を書いてみます。

こんな感じですかね？

ここでは、PowerPoint で絵を書きましたが、実際に皆さんが試すときには、ホワイトボードを使って複数人でわいわいやりながら描いていくと、発想が膨らみます。
ビルっぽいアイコンに加えて、工場のアイコンも敢えて入れてみました。このチュートリアルでは、商業用の賃貸ビルをメインテーマに据えて話を進めていきます。

実プロジェクトの場合は、工場、マンション（賃貸 or 分譲）、病院、等々、建物の絵を変えると、それぞれでシナリオの検討が盛り上がる事間違いなしです。脳内にあるイメージを全てホワイトボードに叩きつけて、チームメンバーと共有しましょう。

実プロジェクトへの適用時のコメント

概念情報クラスの抽出

ビジネスシナリオと絵を元に概念情報クラスを抽出していきます。あまり深く考えずに候補になりそうなものを挙げていきます。

• ビル　→ Building（B）

  • 名前、住所

• フロアー　→ Floor（F）

  • 階数

• 部屋　→ Room（R）

  • 部屋番号

• 空調機器　→ Air Conditioner（AC）

  • シリアル番号

  • モデル名

この辺りは、現実世界のモノとしてはっきり識別できるので直ぐ抽出できて、多くの人からの異論も出にくいでしょう。概念情報クラス名は日本語でも構わないのですが、抽象化した結果の概念情報クラスを指すことが明確になるように英語の名前を → の次に書いています。更に、BridgePoint で概念情報クラスを定義した場合に必要になるショートカット名（キーレター）を（）で括って書いています。また、それぞれの概念情報クラスの特徴値も書いています。
そして、現実世界のゆるぎない現実として、

• ビルは必ず1フロアー以上あるよね

• 部屋は必ずどこかのフロアーにあるよね

• そういえば、部屋が無いフロアーってあるよね

• 部屋には、空調機器が設置されている？

を元に Relationship を定義していきます。鉄壁の Relationship は、

Relationship 案

と思われます。ここで最も注目してほしいのは、R1、R2の右側の多重度の違いです。R1 の Floor 側の多重度を’1..*' にして、R2 の Room 側の多重度を’*’にしています。これは、前述のリストで挙げた「ビルは必ず1フロアー以上あるよね」なので、1以上を意味する’1..*’で、「そういえば、部屋が無いフロアーってあるよね」の議論を受けて、0以上を意味する'*’と定義したわけです。もしも、仕切りが無いフロアー全体を一つの部屋と考えるなら、「部屋が無いフロアーは存在しない」ことになるので、R2 の Room 側の多重度は、R1 と同様に、’1..*’ になります。これは、どちらが正しいかではなく、概念情報モデルの作成者が”どう考えたか”の判断であり、「私はこう定義したぞ！」という表明になります。
次に注目してほしいのは、R4 の多重度です。図では、Air Conditioner 側の多重度が'’*’、つまり、0以上としているので、部屋に空調機器が設置されていない場合も許容するモデルであるという事の表明になっています。また、'0..1' ではなく、'*' なので、一つの部屋に二つ以上の空調機器の設置が可能である事を意味しています。部屋がある程度広い場合、一つの空調機器では力不足なので複数設置されている状況はありそうなので、この多重度にしています。

また、R4 の Room 側は、’1’になっていますが、本当にこれで正しいのでしょうか？一つの機器が二か所以上に同時に存在することは絶対にないので、多重度の候補は、'1' か '0..1' のどちらかです。ここで、敢えて、'0..1'とし、それがどういう意味を持つか考察してみます。R4は Room 側から見ると Air Conditioner が設置されている、逆から見ると Air Conditioner の設置場所を R4 のリンクが表明していることになります。
概念情報モデルの図で定義されている概念情報クラスは分類であることを思い出してください、例えば、現実世界に存在する各部屋は、Room という概念情報クラスを雛形にした、概念インスタンスとしてあらわされます。二つの概念情報クラスの間に定義された Relationship は、両端で定義された多重度の制約に従って、概念インスタンス間にリンクが張られます。R4 を例にとれば、Room という概念情報クラスを雛形にしたそれぞれの Room インスタンスは、R4 の多重度にしたがって、Air Conditioner という概念情報クラスを雛形にしたどれかのAir Conditioner インスタンスとリンクをはり、ある Room インスタンスから R4 に従って張られた Air Conditioner インスタンスへのリンクは複数存在する、という事を意味します。概念情報モデルを読むときには、常に頭の中で、概念インスタンスとリンク群が思い浮かべられるようにしてください。

Air Conditioner から見て、設置場所の Room の概念インスタンスが無い、つまり、R4 のリンクが存在しない状況は、つまり、その空調機器が、どの部屋にも設置されていない事を意味します。この状況が正しいかどうかは、モデル化対象のビジネスが扱う主題領域の定義に拠ります。例えば、部屋に対する空調機器の設置も業務範囲に含まれるなら、設置前の在庫状態の空調機器が存在することになります。また、設置済みの空調機器が壊れてしまい、交換が必要な場合も、交換用の空調機器が存在することになり、この二つの状況を包含するためには、R4 の Room 側の多重度が、’0..1’でなければなりません。逆に言えば、敢えて ’1’とした場合は、ビジネス対象は、「部屋に設置済みの空調機器しか扱わないよ」、と表明したことになります。
繰り返しになりますが、どちらが概念モデリングとして正しいかではなく、どちらが、’よりビジネスを正しく記述しているか’が判断基準になります。

四角形とその間を結ぶ図を描くと、なんとなく、四角形の方に注意が行き、線の端の小さな定義はおざなりになりがちです。概念情報モデルの命は、Relationship の定義にあるといっても過言ではありません。図では、説明を簡単にするため（直観的に分かりやすいので省略したという意味もある）に、Relationship の両端の意味（名前）を書いていませんが、モデルを読む人に誤解を与えないように、少なくともどちらか一方は記載するようにしましょう。また、Relationship の候補を見つけたら、敢えて、両端の多重度を意図的に、'1'、’0..1’、’1..*’、’*’ に変えて、それがどういう意味を持つか時間をかけて検討してみましょう。見落としていたビジネスの片鱗が発見できるかもしれません。

ここまでで、出来上がっているモデルは、単に、”ビルがあってフロアーがあって部屋があってそこに空調機器”が設置されている”状況を表しているにすぎません。冒頭に挙げた4つのミッションステートメントのうちの1番目をカバーしただけです。
ここで意図的に仕組みを一つ追加することにします。
※他にも方法はあるかもしれませんが、モデルはモデル作成者の意図の表明なので、そんな風な心持で以降を読み進めてください。
空調機器を使って快適な部屋の環境を創出するには、当然ですが、部屋の物理量の計測が必須になります。（特定の体格の方の体感は違うかもしれませんが無視します）ここでは、ありがちな物理量として、

• 温度

• 湿度

• 大気圧

• 二酸化炭素濃度

を選択することにします。COVID-19が先日まで猛威を振るっていた昨今なので、二酸化炭素濃度には違和感は感じないと思いますが、「え？大気圧？天気に依存するから制御不可能では？」という声が聞こえてきそうですね。ある研究によれば、人間の精神状態に大気圧が影響するらしく気圧が低いとハイになるらしい（ホンマでっか？）のと、大気圧計測可能なセンサーは容易に手に入るのと、ウイルス対策で加圧されているとか、（どうでもいいんですけど笑）の理由でとりあえず、とってつけてみました。
話を本筋に戻しますね。これらの物理量を計測する装置が必要になるわけですが、比較的広い部屋で、ある場所は暑くてある場所は異様に（別に霊的現象が起きているわけではなくｗ）寒かったりした経験ありますよね。という事は、空調機器の設置場所とは独立に計測装置が設置できるといいよね…ということで、

• 計測機器　→ Measurment Instruments（MI）

  • シリアル番号、モデル名、現状の環境値、計測周期

という概念情報クラスを追加します。この概念情報クラスの概念インスタンス、つまり、個々の計測機器は、空調機器と同様、どこかの部屋に設置されるので、

Measurment Instruments の追加

の様に、概念情報クラスを追加してみます。新たに追加した、Room と Measurement Instruments 間の R3 に異論はないでしょう。
この図では、更に、Affection Target と R6 が追加されています。
皆さん、頭の中で、二つ以上の計測機器、二つ以上の空調機器が設置された比較的広い部屋を想像してみてください。どれかの計測機器で物理量を計測した時に、例えば温度が適温より高い、あるいは、低い場合、設置場所に影響を及ぼすはずの空調機器に対して、高い場合はより低い温度に、低い場合はより高い温度になるよう指示しなければなりません。人間なら目視である程度の検討はつきそうですが、IT システム上に構築した現実の写しのデジタル空間では、どの計測機器がどの空調機器に対応するかの対応付け情報が必要になります。この対応付けを抽象化した概念情報クラスが、”Affection Target” です。この概念情報クラスは、R6に点線でつながっているので、所謂 Associative Class と呼ばれるものです。R6 の両端の多重度を見ると、Measurement Instruments 側が’0..1’になっているので、空調機器（Air Conditioner の概念インスタンス）は、最大一個の計測機器（Measurement Instruments の概念インスタンス）から指示を受けるか、または、対応付けられた計測機器が無い場合もあるよ、と表明しています。無い場合は手動なんでしょうね、多分。逆に Air Conditioner 側の多重度は、’*’なので、一つの計測機器に対して制御対象の空調機器が無い（結果として部屋の環境情報を計測するだけ）か、対応付けられた空調機器が複数あって、計測の結果、それらに指示する事を表明しています。

R3、R6 の多重度についても、意図的に変えてみて、それがどういう意味になるかを検討してみましょう。
また、各自の頭で思い描いている状況が、全て、概念情報クラスの定義で表現可能かを検討してみましょう。

さて、サラッと書いてきましたが、「例えば温度が適温より高い、あるいは、低い場合」という文章が出てきました。概念モデリングの作成中は、この手の話題に敏感に反応しなければなりません。そう、”適温って何？”って事です。概念情報クラスの候補のリストに特徴値の候補も付記してきましたが、こんな値は見当たりませんでした。現実世界では無から有は生じません。概念情報モデル的には、その値を持つ特徴値がどこかになければなりません。厳密に言えば”適温”は正にその場その場にいる人の体感なのかもしれませんが、ここでは、Room という概念情報クラスの特徴値として追加することにします。また、部屋に設置された計測機器群（Room の概念インスタンスに R3 でリンクされた Measurement Instruments の概念インスタンス群）で計測された値の平均値を保持する、”現在の環境値”という特徴値も Room の特徴値として追加することにします。
この様に、概念情報クラスの特徴値の候補は、概念モデリングの過程で発見されるものなので、概念情報クラスを抽出する時点では、明らかにそれが特徴値であるものだけを拾っておけば十分です。モデリング中に発見された候補を都度都度追加していきましょう。

まだまだ、冒頭のミッションステートメントを網羅していないので、更に、概念モデリングを継続します。
空調機器を想像してみてください。この装置は、コンプレッサーやモーターをはじめとして様々な機械から構成されています。と、いう事は、故障することも十分あり得るわけです。乞われた状態を放置したら、利用者の満足度の向上は不可能でしょう。MTBF やMTTR の値を適度に保つことは、満足度を上げるだけでなく、ビル管理としては必須の作業のはずです。故障から正常状態への復帰までは、故障したというインシデントの生成、修理を行う担当者のアサイン、修理日程の確定、修理作業の実施、完了という一連のワークロードの管理が必要です。
冒頭で、”商業用の賃貸ビルをメインテーマに据えて”と書いていたことを思い出してください。Room の概念インスタンスである個々の部屋には借主がいるという事です。修理の日程は、借主の都合も考慮しないと満足度は上がりませんよね。ということは、それぞれのワークロードは、設備機器に対する修理作業ではありますが、部屋に対するワークロードと考えた方がよさそうです。

この様な考えに基づいて、概念情報モデルにこれらの概念情報クラス群を追加し、特徴値の定義も追加して、BridgePoint で描いたモデルを下図に示します。

ビル管理の概念情報モデル

追加された概念情報クラスの概要を説明しておきます。
先ず、ワークロード周辺ですが、

• Workload（WL）

  • R5 で Room と関係しています。一つの部屋につき、同時に二つ以上のワークロードは存在しえない多重度としています。

• Customer Engineer（CE）

  • 個々のワークロードを実際に担当して修理を行う技術者を表します。

• Workload Assingment（WA）

  • 個々のワークロードへの技術者の割当てです。R7 により、一つのワークロードに専念してもらうため、同時に1つだけのワークロードを担当する様な多重度になっています。また、責任の所在が曖昧にならないよう（ホンマかいなｗ）に、一つのワークロードに対しては唯一人の技術者を割り当てるようになっています。
    加えて、ワークロードは作られてから作業担当の技術者が割り当てられるまでに間があるはずなので、CE 側の多重度は、’0..1’になっていて、かつ、ブラックな職場環境にならないように（ｗ）のべつまくなしでワークロードが割り当てられないように、WL 側の多重度も、’0..1’としています。

• Customer（CS）

  • 部屋を借りている顧客を表します。

• Customer Contruct（CC）

  • 部屋の賃貸契約を表します。R8 の定義で、各部屋は、唯一人（法人、組織を含む）の顧客にのみ貸し出し、一人の顧客は複数の部屋を借りることができて、部屋ごとに契約を結ぶ様な多重度になっています。

この概念情報モデルは、https://github.com/kae-made/artifacts-building-management-tutorial から公開しているので、各自の workspace にインポートし、BridgePoint で詳細を確認してみてください。

概念モデリングの前提

モデリングの初学者にありがちな状況として、最初の方の、ビル、フロアー、部屋、空調機器の様な、目に見えるモノだけを抽出して、それ以上の概念情報クラスが抽出できない状態に陥りがちではないでしょうか。
その様な場合は、本ドキュメントで解説している様に、”ビジネスとしてそもそも何をしたいのか” から、潜在する概念情報クラスを抽出していくのが王道です。
デジタルツインやデジタルトランスフォーメーションを実践したいという事は、”ビジネスでどう活用するか” が必ずあるはずです。まずはそちらを確認してみましょう。
万が一、無い場合は、物理的なモノの抽象化が終わった後に、現実の世界を構成するブツからどんなデータが採れれば、自分のビジネスの改善に役立つかを考えて、概念情報モデルを作成し、現実の世界において、今何が起きているかを把握する仕組みを作るところから始めてみてはいかがでしょう。

※ 以下、Under Construction

概念モデルからの必要な構成物の生成

一応、ビル管理を定義する概念情報モデルが出来上がったので、Azure の各種サービスで必要な構成物を生成していきます。

Twin Model （DTDL）の定義生成

IoT Plug ＆ Play Model（DTDL）の定義生成

環境情報やワークロード等々の履歴管理

Azure IoT Hub、Azure Digital Twins による実装

最後に