はじめに

本ドキュメントは、kae-made/tutorial-generated-library-from-conceptual-model-with-azure-services (github.com) で公開しているコンテンツの、日本語による詳細解説版です。

ビジネスで扱うエンティティ群、及び、シナリオを元に、概念モデリングの専用ツールの BridgePoint を使って可視化した、概念モデルを、変換による実装のテクニックを使って、様々な成果物を自動生成し、Azure IoT Hub、Azure Digital Twins、Azure Functions 等のサービスを使って、デジタルツインや IoT ソリューション、デジタルトランスフォーメーションの実現の基盤となる、スケーラブルなソリューションを最小限のコストで構築する手順を解説します。

モチベーション

概念モデリング？、BridgePoint？だと思いますが、ビジネスをモデル化することの重要性は、「ビジネスシステムにおける概念モデルの重要性」をご一読いただくことにしますが、ここで簡単にまとめておきます。デジタルツインは、現実世界におけるビジネスの対象となるモノ・コト・役割等の写しを IT システム上に作るのが基本です。モノ・コト・役割等といった概念のデジタル化はモデル化と同義であり、結果としてデジタルツインを実現するには概念群をモデル化したもの、つまり、”概念モデル”の作成（＝”概念モデリング”）が必須であることになります。デジタルトランスフォーメーションもまた、デジタルツインと同様、業務で扱う様々な対象を IT システム上でデジタル化することがはじめの一歩であり、こちらも”概念モデル”の作成が必要です。デジタルツイン、デジタルトランスフォーメーションという流行りのバズワードを挙げなくても、ビジネスや業務の改善・改革を行うには、現状に対する正しい認識が必要であり、正しい認識を行うためには、改善・改革対象のモデル化が必要であることは容易に理解できることと思います。
作成した”概念モデル”は、対象のビジネスや業務に関連する全てのステークフォルダーが見て理解できるもので作成する意味がありません。結果として、”概念モデル”の表現は数学の公式や定義の様な決まりごとが必要です。ビジネスや業務を表現するモデル化記法とモデル作成方法は、コンピュータテクノロジーの発達に伴い、複数の方法が過去に提案されています。本稿で活用している”概念モデリング”もその一つです。
皆さんご存じの通り、システム化したいビジネス、業務は大抵の場合、複雑怪奇であり、概念モデルはその複雑怪奇な内容を正確に記述できるだけの表現力が必要です。”概念モデル”はその要件を満たしていますが、実際に実用に足る概念モデルを作成するには、それなりのモデリングスキルが必要であり、また、時間の経過や社会状況の変化によって、モデル化対象のビジネスや業務もまた変化していくため、一度出来上がった概念モデルは、その変化に応じて修正していかなければなりません。概念モデルを描くのに専用のツールがあると便利です。その専用ツールが BridgePoint です。BridgePoint に限らずツールを使って概念モデルを作成すれば、”概念モデル（＝ビジネス・業務を可視化したもの）”がデジタル化されます。一定のモデル化記法に従って作成された概念モデルの全ての内容は系統的に取り出すことができ、実 IT システムを構成するコードや設定ファイルに変換が可能です。この変換の過程を自動化してやれば、”ビジネスや業務を定義した概念モデル”からのソフトウェア開発工程を全て自動化できます。
”簡単に”と前置きした割には長文になってしまいましたが、本稿で紹介する手順は正に、この、”ビジネスや業務を定義した概念モデル”からのソフトウェア開発工程を全て自動化するための環境の使い方の手順であり、本稿はその手順書として作成しています。

本稿が扱うソフトウェア開発プロセスの最大の欠点は、”ビジネスや業務を元に作成した実用レベルの概念モデルが作成可能でなければならない”という点です。
概念モデルとは何かは、「Art of Conceptual Modeling」で詳解しているので、そちらを読み込んでください。この概念モデリング技法は、1990年初頭に提案された Shlaer-Mellor 法（現、eXecutable & Translatable UML）がベースになっています、著者は既に20年以上前に、Shlaer-Mellor 法と BridgePoint を活用してソフトウェアを開発し、開発されたソフトウェアが搭載された実製品は実際に市場で販売されたという経験を持っています。また、マイクロソフト在籍中のお客様の数百に及ぶ実案件支援において、この技法の有用性を検証してきました。著者が30年来の応用と実践・体験を元に、最新の IT 技術の活用とビッグデータ系クラウドソリューション向けに再編成した技法が、「Art of Conceptual Modeling」で紹介されています。他に、より実用的な概念モデルを作成するために「概念モデリングチュートリアル集」も公開しているので参考にしてください。また、概念モデルを元にした、”変換による実装”の詳細技術に関しては、「Technique of Transformation」で解説しているので、こちらもご覧いただければ幸いです。
読者を少し安心させる補足コメントを追加しておきますね。IT ソリューションの開発に関わる全ての人が、”概念モデルを構築できるようにならなければならない”必要はありません。一つの組織に一人いれば最悪十分です。

概念モデリングや変換による実装のスキルアップを目的としたワークショップの開催や、本稿で紹介する環境の実案件での利用支援は、有償で承りますので、ご興味のある方は、master@kae-made.jp まで、ご連絡ください。

なお、本稿で紹介している、”概念モデルからの変換による実装”を活用した自動生成に一切のマジックは存在しません。開発する IT システム（この場合は、リアルタイムのデータストリームを扱うビッグデータ系システム）を一般化して導き出された非機能要件を元に設計・開発・実装したアプリケーションフレームワークをベースに、厳格に定義した設計ルールで概念モデルの中身を実コードに変換しているにすぎません。フレームワークの設計やプログラミングの基本については、「Essense of Software Design」で詳述しているので参考にしてください。また、実プロジェクトにおいては、ソフトウェア開発を進めるためのエンジニアリング活動が必要になります。「Practices of Software Engineering」で紹介している Practice 群は、”変換による実装”テクニックを活用した際に最大限に効果を発揮すると考えてください。

何ができるのか？

概念モデリングにしろ、Microsoft Azure のサービス群にしろ、門外漢の皆さんには珍紛漢紛でしょうし、それぞれの技術要素に精通した方々にとっても、一体このドキュメントで語られている手順で何が出来上がるのか想像できる人は少ないと思われるので、先ずは、どんな IT ソリューションが出来上がるのかを解説することから始めます。

出来上がる IT ソリューションの全体像は以下の通りです。

図では、IoT の要素も含んでいますが必須ではありません。IoT 要素が無いデジタルツイン、デジタルトランスフォーメーション のソリューションでも利用可能です。

Azure Digital Twins は、ビジネスの今の状態を保持しています。右側のオレンジ色の二つの Azure Function のロジックは、ビジネスロジックです。Domain Operation は、ビジネスシナリオのトリガーと考えてください。HTTP Trigger で起動される Domain Operation によって、ビジネスシナリオをモデル化した概念情報クラスの状態モデルとアクションの定義を元に生成された C# コードが、Azure Digital Twins の Twin Graph の状態を参照しながら実行され、実行の過程で生じた、概念インスタンスの生成・削除、特徴値の更新、Relationship のリンク・アンリンクを実行完了時点で、Twin Graphに戻します。この一連の過程は、右側のオレンジ色の四角の上の Azure Function が担います。
また、ビジネスの過程で生じる様々な事象は、Telemetry として、Twin Graph に Publish します。Twin Gprah に Publish された Telemetry は、右下のオレンジ色の四角の Azure Function が受信し、概念モデルの状態モデルで定義されたイベントにマップされ、概念情報クラスの状態モデルが動き、右上の Azure Function と同様、状態モデルのアクション実行の過程で生じた状態の変化を Twin Graph に戻します。

図の右の二つの Azure Function は、同時に複数並行して実行してかまいません。この仕組みにより、Twin Graph が大規模化した場合も、Docker や K8s の利用により、処理のスケーラビリティが保証されます。

詳しくは、「ビジネスシナリオを元に作成した概念モデルを、Azure Digital Twins、Azure Functions を使って実装する」をご参照ください。また、複数の Azure Function の同時並行実行が可能な理由の大本は、「概念振舞モデル」で詳述している、概念モデルの振舞を定義する際に従わなければならない、実行セマンティクスの定義に拠っています。これは、実用レベルの概念モデルを作成するための前提知識となるので、読み込んで理解を深めてください。

作業の全貌

作成した概念モデルから生成する成果物や、個々の概念モデルとは独立して再利用するソフトウェア等を図示します。

作業の流れ

図に掲載された、ジェネレータ群と固定コードは、全て、Github から公開されています。

固定コード

固定コードの名前を示します。

• ジェネレータ

  • DTDL Generator

    • BridgePoint で作成した概念情報モデルから DTDL で記述された Twin Model、及び、IoT PnP Model を生成

    • https://github.com/kae-made/dtdl-schema-generator

  • IoT App Generator

    • 生成された IoT PnP Model から、IoT Hub とのセキュア接続・双方向通信の機能を有する IoT デバイスアプリの雛形 C# コードを生成

    • https://github.com/kae-made/dtdl-iot-app-generator

  • C# Generator

    • BridgePoint で作成した概念モデルから、データ構造、振舞ロジックを含む Domain Model の C# ライブラリを生成する

    • https://github.com/kae-made/domainmodel-code-generator-csharp

• 固定コード

  • IoT Hub → Digital Twins

    • ReceiveD2CToTwinGraph

      • IoT Hub のメッセージルートで受信した D2C Message を元に、Twin Graph の Property 更新、Telemetry 通知を行う

      • ReceiveD2CToTwinGrap.cs

    • ReceiveReportedPropertiesToTwinGraph

      • IoT Hub のメッセージルートで受信した Device Twin 更新を元に、Twin Graph の Property 更新を行う。

      • RecveiveReportedPropertiesToTwinGraph.cs

  • Twin Graph → Domain Model C# Library

    • DomainModelExecutor

      • HTTP Trigger で Domain Operation、Class Operation を実行し、実行過程で生じた状態変化を Twin Graph に反映、イベントが送信された場合は、Telemetry を Publish

      • DomainModelExecutor.cs

    • TelemetryNotified

      • Twin Graph に Publish された Telemetry を受信し、概念振舞モデルのイベントにマップし、状態モデルを実行する。実行過程で生じた状態変化を Twin Graph に反映、イベントが送信された場合は、Telemetry を Publish

      • TelemetryNotified.cs

  • WebAPIAppViewerForADT

    • 概念モデルで定義された、データ構造、振舞の規定に従って、Twin Graph を更新、あるいは、Twin Graph の状態を元にした処理実行を行う Web アプリケーションフロントエンド

    • WebAPIAppViewerForADT project

  • Timer Service

    • 概念振舞モデルの、時間指定で発火するイベントの実装を実現するためのサービス

    • TimerService.cs

最後の二つは、他のモジュールと以下の様な関係にあります。

他に必要なピース

本稿で解説する方法で、実際の IT ソリューションの全てを構成することはできません。

図中の上下の赤の二重線で囲んだ部分は、BridgePoint で作成した概念モデルの情報だけでは生成できません。

View

上の View の部分は、ビジネスの本質的な主題群だけでなく、利用するオーディエンスの種別や、パソコン、Web、スマートフォン等、アプリの配置先、業態の特殊性で使い勝手が変わってくるため、固定的な設計ルールを定義できません。著者が UI 設計の専門家ではない事にもよります。
Twin Gprah の状態更新は、それを規定する Twin Model（＝BridgePoint の概念情報モデル）で定義された制約に従わなければなりません。そのため、View が Twin Graph に対して行えるのは、

• Twin Graph の参照

• Telemetry の Publish 

のみに制限します。制限は、「Azure Digital Twins をセキュリティで保護する」で解説されている方法で容易に設定可能です。
Twin Graph の更新は、BridgePoint で作成した概念モデルから生成した Domain Model C# ライブラリを介してのみ許可します。

このあたりの分離については、「ドメインとITシステム構築」で詳解しているので参考にしてください。

View のサンプルとしては、WPF Application によるシンプルなサンプルを、kae-made/domain-model-csharp-adaptor-samples: Domain Model Adaptor Samples for C# (github.com) から公開しています。概念モデルから生成した Domain Model C# ライブラリをとりあえず動かしてみたい場合は、こちらをお試しください。BridgePoint の Verifier より高機能です。
参考までにですが、View として 3D View を追加してやれば、メタバース的なシステムが出来るのではないでしょうか。
また、View の用途や機能・使い勝手を元に概念モデルを作成し、選定した View の実装技術に合致するコードやスクリプトを自動生成する仕組みを作る事は可能です。

他のサービスへの拡張ポイント

次は、図の最下層の ”Dashboard or Long term Storage” です。IoT や Digital Twins、Digital Transformation のソリューションは、基本的にビッグデータ系であり、データストリームとして捉えるのが良いアーキテクチャ設計です。Twin Graph の状態更新は、「イベント通知」で解説されている様に全て Event Grid を介して受信可能です。このシステムを流れるデータは、丁度、水道管に蛇口をつければ水が出てくるように、任意のタイミングで別のサービスに連結可能です。Twin Graph は”今の状態”しか保持しませんが、ロングタームでデータベースやブロブストレージにデータを蓄積したい場合は、このパスを使えばデータが受信できるので、この仕組みを使って構成することになります。また、今どうなっているかを表示するダッシュボード的な仕組みが必要であれば、Power BI や Power Apps を接続すれば容易に構成が可能です。
この様に、本稿で解説しているソリューションは、任意の時点でシステム拡張可能なアーキテクチャになっています。

Step by Step

1. 概念モデルの作成

先ずは、システム生成の元になる概念モデルを BridgePoint で作成します。BridgePoint の使い方は、「ビジネスをモデル化する ～ BridgePoint を使ってみよう」を、先ずは参考にしてください。
そうそう自分のモデルを作れる方は少ないと思われるので、サンプルとして公開している

tutorial-generated-library-from-conceptual-model-with-azure-services/SampleModel/ADTTestModel/models/ADTTestModel at main · kae-made/tutorial-generated-library-from-conceptual-model-with-azure-services (github.com)

を使ってみてください。以降の説明もこのモデルを前提に記述していきます。ちなみにこのモデル、自動生成の仕組みをテストするために作ったので、特に何かの業種のビジネス要件を元にしているものではないことにご注意ください。

2. Twin Model を定義した DTDL ファイルを生成する

概念モデルから Twin Model を定義した DTDL を DTDL Generator を使って生成します。この DTDL Generator は、Azure Digital Twins 用の Twin Model を定義する DTDL ファイルと、Azure IoT Hub に接続されるデバイスの IoT Plug ＆ Play（以下、IoT PnP）Model を定義する DTDL ファイルを生成します。
「Azure Digital Twins に IoT Hub テレメトリを取り込む」という Microsoft Docs の記事では、IoT Hub に接続された IoT デバイスが送信した D2C Message を、Twin Graph に存在する Twin の Property の値として使っています。ってことですよ、概念情報モデル的には同じ概念なのにも関わらず、IoT PnP Model では Telemetry なのに、Twin Graph 側の Twin Model では Property って事なんですね。え？となる読者さん多いのかもしれないですが、こちらも、著者が公開している「ドメインとITシステム構築」で紹介しているドメイン分割の考え方ならば、「あぁ、デバイス（機器メーカー）側とソリューション（ITビジネス）側は違うドメインなのね、そうだよね…」となるので、「Art of Conceptual Modeling」の重要な要素である”ドメイン”は是非マスターしてくださいね…
余談はこれぐらいにして。
そんなわけで、BridgePoint で作成した概念情報モデルの一つの概念情報クラスから、Twin Model 用、IoT PnP Model 用の DTDL を生成可能です。
BridgePoint で、定義した概念情報クラスの Description Editor を使って、

@iotpnp

と記述すると、両方の DTDL ファイルを生成するようになります。前述のサンプルモデルの、”Lief Device” の Description にこの記載をしています。
更に、その概念情報クラスの特徴値の Description で、

@iotpnp(telemetry)

と記述すると、Twin Model 側では、Property、IoT PnP Model 側では、Telemetry として生成されます。
更に、

@iotpnp(deviceid)

と記述すると、その特徴値は、IoT Hub に登録する際の Device Id に対応する特徴値であることの印がつけられます。自動生成の際、ジェネレータはこの記述を調べて、その特徴値の生成方法を制御できるわけです。
また、

@iotpnp(readonly)

と記述すると、IoT PnP 側の Property の定義で、"writable":false と生成され、結果として、その特徴値が、IoT Hub 上の Reported Property として定義されるようになります。この指定が無い特徴値は、IoT Hub 上の Desired Property として扱われます。

概念情報クラスの特徴値の中には、IoT 機器側が知らなくても良い情報も含まれます。（ドメインが違うので）
IoT PnP Model 側で省略したい場合は、

@iotpnp(exclude)

と記述します。この指定により、Twin Model 側のみに対応する Property が生成されます。
IoT 機器のデバイス Id は、IoT Hub に登録・保持されているので、敢えて毎度の D2C Message 送信で明示的に送信する必要はなく、結果的に、IoT PnP  Model でも対応する Property は生成する必要がありません。

@iotpnp(deviceid,exclude)

と記述すれば、Twin Model 側にのみ Property が生成され、その Property は IoT Hub 上の デバイス Id に対応する事がマークされた DTDL ファイルが生成されます。

他に、概念情報モデル上で定義された概念情報クラスの特徴値の識別子や参照に関する情報を DTDL の Comment に付与して生成するようになっています。
上で説明した色付けは、Azure IoT Hub がサポートする IoT Plug & Play Model に対応するための仕組みでした。これは”概念モデルを使った変換による実装”の技法でいうところの、2つの異なるドメインを統合する一形態です。別の色付け、生成ルールを設計・実装し、DTDL ジェネレータの拡張も可能です。

では、DTDL Generator の使い方を説明します。
DTDL Generator は、以下のコマンドラインで実行します。

ConsoleAppDTDLGenerator.exe --metamodel BridgePoint\tools\mc\schema\sql\xtumlmc_schema.sql --base-datatype BridgePoint\tools\mc\schema\Globals.xtuml --domainmodel "BridgePoint\workspace<i>ADTTestModel\gen\code_generation<i>ADTTestModel.sql" --dtdlns dtmi:com:company --dtdlver 1 --use-keylett false --gen-folder "WorkingDir\dtdl"

以下にそれぞれのオプションを解説しておきます。

• -- metamodel 文字列

  • BridgePoint のメタモデル定義ファイル xtumlmc_schema.sql のパスを指定

• -- base-datatype 文字列

  • BridgePoint の基本データ型定義ファイル Globals.xtuml のパスを指定

  • ※ 上の二つは、BridgePoint をインストールしたディレクトリの、mc\schema\sql、mc\schema にそれぞれ存在

• --domain-model 文字列

  • 生成したい概念モデルのファイルのパスを指定

  • ※ BridgePoint 上で Build Project を実行して生成された、sql ファイルのパス

• --dtdlns 文字列

  • 生成する DTDL の名前空間を指定する

• --dtdlver 数字文字列

  • 生成する DTDL のモデルId 等のバージョンを指定する

• --use-keylett　true|false

  • 生成する DTDL ファイル名の指定

    • true の場合、ファイル名で、BridgePoint の概念情報クラスの Key Letterが使われる

    • false の場合、ファイル名で、BridgePoint の概念情報クラスの名前が使われる

• --gen-folder 文字列

  • DTDL ファイル群を生成するディレクトリのパスを指定

DTDL Generator 本体は、Kae.Tools.XTUML.Tools.Generator.DTDL という名前で、NuGet パッケージとして公開しています。
DTDL Generator は、「BridgePoint で作成した概念モデルから DTDL 定義を自動生成する」で詳解しているので、参考にしてください。

3. IoT デバイスアプリの雛形生成

IoT 機器との接続を必要としないソリューションの場合は次のステップに進んでください。

IoT デバイスアプリの雛形は、IoT Device App Generator を使って生成します。
ジェネレータ本体は、Kae.IoT.PnP.Generator という名前で NuGet パッケージとして公開されています。生成は WPF の GUI を持つ、Kae.IoT.Tools.IoTAppGenerator を使うと便利です。使用方法は、dtdl-iot-app-generator/HowToUse.md at main · kae-made/dtdl-iot-app-generator (github.com) に記載しています。
このジェネレータを使えば、DTDL で定義された IoT Plug & Play Model から、C# で書かれたアプリケーションコードの雛形が生成されます。生成されたコードには IoT Hub との連携に関する以下の機能が自動生成されています。

• Azure IoT Hub とのセキュアな接続

  • SAS Key、X509証明書、Device Provisioning Serviceに対応

• Telemetry、Device Twins のデータ構造

• D2C メッセージ送信 ‐ 周期的、オンデマンドどちらも対応可能

• C2D メッセージ受信ハンドラ

• Direct Method Invocation 受信ハンドラ

• Desired Properties 更新通知ハンドラ

• Reported Propertis 更新

生成されたコードに、以下の機能を手書きで追加します。

• D2C メッセージとして送信するためのデータを用意（センサー読み取りなど）

• 以下のハンドラの実装

  • Direct Method

  • C2D メッセージ

  • Desired Properties

• Reported Properties 更新用のデータ用意、及び、更新

コードの生成時の指定で、実行形態の異なるアプリケーションを生成できます。.NET Core は、Windows だけでなく Linux でも実行可能です。

• Windows、または、Linux で実行可能なアプリケーション

• Windows Service、または、Linux のデーモンで実行するバックグラウンドサービス

• Docker 上で実行する、IoT Edge 対応のライブラリコード

IoT Device App Generator は、現在、C# コードのみを生成対象としていますが、将来的には、C/C++、Python、JavaScript のコード生成も追加していく予定です。

IoT Device App Generator、及び、生成されるコードの詳細は、「Art of Auto Software Development Deliverables Generation」で、”変換による実装”による自動生成の基礎と共に詳しく解説しているのでご参照ください。

Azure IoT Hub との連携に関する詳細は、「BridgePoint の External Entity とは何か？自動生成でどう扱うか、及び、応用としての Azure IoT Hub 対応」を参考にしてください。

4. 概念モデルからの Domain Model C# ライブラリ生成

C# Generator を使って、BridgePoint で作成した概念モデルから、データ構造、振舞を含む Domain Model C# ライブラリを生成します。
このジェネレータの詳細は、

• 「Bridge Point で作成した概念モデルを In Memory で動作する C# アプリケーションライブラリに変換する」

• 「BridgePoint で作成した概念モデルの振舞アクションを C# コードに変換する」

• 「概念モデルから Adaptor を生成してシステムに組み込む」

で詳しく解説されています。生成される C# ライブラリには、データ構造、振舞に加えて、

• Azure Digital Twins からの Twin Graph 状態取得

• Azure Digital Twins の Twin Graph の状態更新、Telemetry の Publish

• Azure IoT Hub を介した、Desired Properties 更新、Direct Method 起動

を行うためのコードが追加されます。ジェネレータのコマンドラインは、以下の通りです。

ConsoleAppCshaprGenerator.exe --metamodel BridgePoint\tools\mc\schema\sql\xtumlmc_schema.sql --base-datatype BridgePoint\tools\mc\schema\Globals.xtuml --domainmodel "BridgePoint\workspace<i>ADTTestModel\gen\code_generation<i>ADTTestModel.sql" --project ADTTestModel --dotnetver net6.0 --gen-folder "gen_folder" --action-gen true --adoptor-gen true --azuredigitaltwins dtmi:com:company;1 --azure-iot-hub true

コマンドラインのオプションは、以下の通りです。

• -- metamodel　…①

  • 文字列BridgePoint のメタモデル定義ファイル xtumlmc_schema.sql のパスを指定

• -- base-datatype 文字列　…②

  • BridgePoint の基本データ型定義ファイル Globals.xtuml のパスを指定

  • ※ 上の二つは、BridgePoint をインストールしたディレクトリの、mc\schema\sql、mc\schema にそれぞれ存在

• --domain-model 文字列　…③

  • 生成したい概念モデルのファイルのパスを指定

  • ※ BridgePoint 上で Build Project を実行して生成された、sql ファイルのパス

• --gen-folder 文字列　…④

  • プロジェクトファイル群一式を生成するディレクトリのパスを指定

• --project 文字列　…⑤

  • 生成する C# プロジェクトの名前。名前空間としても使われる

• -- dotnetver　…⑥

  • 生成する C＃ プロジェクトの実行フレームワークのバージョン指定

  • ※ 通常は、現時点で最新の LTS の 'net6.0' を指定

• --action-gen true|false　…⑦

  • true 指定の場合、概念情報クラスの状態モデルのエントリアクション、クラスオペレーション、ドメインオペレーションに記述された OAL によるアクション記述を元に振舞に関する実行コードを生成

  • false 指定の場合、上記のアクション記述からの自動生成は行わない。振舞を手書きしたい場合や、データ構造の管理のみ必要な場合に指定する

  • 省略可。省略した場合は、false 指定と同義

• --adaptor-gen true|false　…⑧

  • Azure Digital Twins と連動させる場合は、true に指定

  • 概念モデルから生成される基本機能のみ生成したい場合は、false を指定

  • 省略可。省略した場合は、false 指定と同義

• --azure-digital-twins 文字列　…⑨

  • Azure Digital Twins との連動機能を生成する。文字列は、”DTDL の名前空間;バージョン”の形式で指定する

  • 省略可

• --azure-iot-hub true|false　…⑩

  • true の場合、Azure IoT Hub との連動機能を生成する。--azure-digital-twins とは無関係に指定可能。

  • 省略可。省略した場合は、false 指定と同義

C# Generator の本体は、Kae.XTUML.Tools.Generator.CodeOfDomainModel.Csharp という名前で、NuGet パッケージとして公開しています。ここで紹介したコンソールアプリに加えて、利便性を考え、WPF GUI を持つアプリケーションも提供しています。

生成された Domain Model C# ライブラリは、前にも書いたように、kae-made/domain-model-csharp-adaptor-samples: Domain Model Adaptor Samples for C# (github.com) で提供している2種類の Viewr を使って実行可能です。

• WPF アプリによる Viewer

• Web アプリによる Viewer

後者を使えば、そのまま Azure App Service を使って、Web アプリケーションとしての配置が可能です。

5. 生成した Twin Model のアップロード

Step 2. で生成した DTDL ファイルを Azure Digital Twins Instance にアップロードします。アップロード方法は、「8. Azure Digital Twins を試す」を読んでください。

6. Twin Graph の初期状態を構築する

予め存在する Twin や Twin 間の Relationship を作成します。Azure Digital Twins Explorer を使ってもいいですが、生成された DTDL ファイルに定義された Twin Model の元になっている BridgePoint で作成した概念モデルの、より詳細な制約を全て満たすよう、Twin Graph を構成しなければならないので、「9. Twin Graph を操作する」で使っている、WpfAppADTOperation アプリを使うとよいでしょう。Relationship をリンク・アンリンクをした際、関連して更新しなければならない、概念情報クラスの参照特徴値を元に生成された DTDL の Property を一緒に更新してくれます。

7. Azure Function の配置

前の方で紹介した、Azure Function 群 を Azure 上に配置します。

先ずは、kae-made/-domain-model-csharp-azure-digital-twins-iot-hub-framework (github.com) を clone してください。このリポジトリの中の AzureDigitalTwinsAdaptorForCsharpFramework.sln を Visual Studio 2022 で開きます。このソリューションのフォルダーに、生成した Domain Model C# ライブラリのプロジェクトをコピー、あるいは、ソリューションのフォルダーのパスを指定して、Domain Model C# ライブラリを生成してください。

次に、AzureDigitalTwinsAdaptorForCsharpFramework プロジェクトに、Domain Model C# ライブラリプロジェクトをプロジェクト参照として追加します。

「13.  Azure Digital Twins ～ D2C データを元にした Twin Graph の更新」を参考に、このプロジェクトの Azure Function を Azure に配置します。
DomainModelExecutor、TelemetryNotified の二つの Azure Function が配置されます。

IoT シナリオの場合は、Kae.Domain.Csharp.AzureDigitalTwins.AzureIoTHubBinder  のプロジェクトに入っている、ReceiveD2CToTwinGraph と ReceiveReportedPropertiesToTwinGraph の二つの Azure Function を Azure に配置します。IoT Hub の設定、メッセージルートの作成などは、「5. メッセージルーティングの新機能を試す」をはじめとする、「Azure の最新機能で IoT を改めてやってみる」の関連する記事を参考にしてください。

生成元の概念振舞モデルで、時間指定で発火するイベントが使われている場合は、Kae.DomainModel.Csharp.AzureDigitalTwins.Timer の TimerService の配置も必要です。このサービスを使う場合は、DomainModelExecutor、TelemetryNotified に対して、TimerService を配置した URL の設定が必要です。接続文字列として、”timer-service-url”という名前で、このサービスの Endpoint の URL を設定してください。

5つの Azure Function は、いずれも、Twin Graph の状態を更新するので、Azure Digital Twins へのアクセス権限設定や、Azure Digital Twins Instance の URL、IoT Hub への接続文字列の設定等、忘れずに行ってください。

また、HTTP Trigger で起動可能な DomainModelExecutor に加えて、Web アプリケーションで配置して、同様な機能が使える、WebAPIAppViewerForADT  も公開しています。

以上で作業は完了です。
Digital Twins、DX、IoT ソリューションの基盤がこれで完成します。

最後に

以上で、説明は全て終了です。
冒頭で触れたように、Digital Twins、DX を活用したソリューションに必須の、ビジネスや業務の概念モデルをきちんと作成すると、IT ソリューションの基盤を構成するソフトウェアを自動で得ることができます。
View の作成は、Cloud Native のモダーンな開発スタイルにおいては、Information Worker が、それぞれが担う役割に応じて作成するのが一般的です。ソリューションの基盤の設計・実装を省力化することにより、本当にやらなければならない本質的な部分への人的・時間的リソースの投入が可能になります。
また、Digital Twins、DX、IoT の活用は、手段であって目的ではありません。
バズワードで惑わされがちな作り込みの部分を自動化することにより、本来重要な「何をするのか・何をしたいのか」に、読者、及び、読者が所属する組織がより注力できるように、本稿で紹介している技術体系が役立てば幸いです。