0. さぁ、はじめるぞ！
はじめに
2022年の2月まで、マイクロソフトで、IoT Solution の技術支援をしていました。2006年から2010年代初頭まで、組込み系の Evangelist を担当していたので、エンベデッドジョージというニックネームで呼ばれていた Evangelist の講演を聞いたことがある読者もいるのではないでしょうか？
2008年にマイクロソフトのクラウド Azure が発表され、その後、.NET Micro Framework や Windows Embedded Compact、Windows 8 の周辺機器連携等とクラウドを組み合わせて Sensor Cloud のプロトタイプや実案件支援をやっていたら、IoT というキーワードが出てきて、2013年ぐらいから、ずっと IoT 系の技術普及啓発・実案件支援を続けてきていました。当時は、定番の Azure IoT Hub は影も形もなかったので、ありものを組み合わせて実現していて、そうこうしている内に、Event Hubs、Stream Analytics、IoT Hub、IoT Edge、Azure Digital Twins、…と IoT 向けのサービスが次々とリリースされ、2月末に退職するまで、マイクロソフトの IoT 関連サービスの進化を間近で感じつつ、最新サービス・技術をキャッチアップしてお客様に技術情報を届けてきたわけです。3月に卒業してから約半年、粛々と、概念モデリングと概念モデルからの変換による実装、ソフトウェア設計のエッセンス、ソフトウェアエンジニアリングの実践プラクティス、と執筆を終えて今一段落。
久しぶりに、Microsoft Azure Blog を眺めてみたら、「あら色々変わっているのね」と。既出のコンテンツにも、Azure IoT 系のネタは散りばめていて、IoT Solution 開発のチュートリアルはもう一本ぐらい作ろうかなと思ってました。
2月までと今現在の違いは、私がマイクロソフトの中の人で、未公開情報にも触れ放題、サービス開発チームとのコミュニケーションも取り放題、優秀な同僚たちともディスカッションし放題の3放題だったのが、今は外の人になり、正式な技術情報ソースは一般の人達と同じく、Microsoft Docsだけになったわけです。まぁ、Microsoft Docs から公開されている技術情報は膨大で、必要な情報にたどり着くのは大変ですが、既に理解している技術屋さんには十分な情報が公開されているので問題はない（筈）んですけど、みんなが使ってくれなかった（？）が故のサービス廃止や、「え？そんな機能前からあったらこの機能作らなくてよかったじゃん」というような素敵な新しい機能のリリースは、一般の皆さんと同様に不意打ちを食らうわけですね。Microsoft Azure に限らず第三者が提供するサービス・技術を使って自社のサービスを構築する時の宿命でもあるのですが。
前置きが長くなりましたが、外の人になった状態で、最新のサービス・技術群を使った、あるいは追従して、IoT Solution を構築していくための具体例を少しづつこのマガジンで公開していく事にします。
Microsoft Azure で IoT や Digital Twins の実 Solution を開発したい技術者の皆さんを支援する内容になる事を心がけるとともに、また、もちろん、構築に当たっては、概念モデリングや変換による実装の技術を駆使するので、そちらに興味のある皆さんのスキルアップさにつながる内容にしたいと思っています。
記事に関するご質問は大歓迎です。外の人として答えられる限りの回答をさせていただきます。
どうでもいい雑音は極力排除させていただきたいということで、定期購読の有料マガジンでの公開とさせていただいています。ご了承くださいませ。
では、はじまりはじまり～
構築する IoT Solution の全体像
実プロジェクトとして IoT Solution を開発する場合は、”工場の”とか”運送の”、”電力系の”、”農業の”、”家の”、…等々、IoT や Digital Twins を活用して改善したい、あるいは新しい価値を提供したい具体的なビジネスが前提としてなければなりませんが、このマガジンでは、Microsoft Azure の IoT 系を使ってどうやって構築していくかという実装面にフォーカスを当てるので、具体的なビジネス領域を特定せずに説明をしていきます。逆に言えば、ほぼどんなビジネス領域でも適用できる内容になるということですね。
"概念モデリングと概念モデルからの変換による実装"では、「ドメインと IT システム構築」で解説している様に、具体的なビジネス側の主題領域を独立したアプリケーションドメインととらえ、現実の機器を IT システムと連携するのが基本の IoT 的なシナリオで必要な、
複数の機器が IT システムにセキュアに接続される
複数の機器で生まれたデータを IT システムに送信する
IT システム側から機器側にコマンド送信や設定を行う
IT システム側に送信されたデータ群を処理し現実世界の構造に従って蓄積する
IT システム側に送信されたデータ群で一定の条件に合致する状況が生じたときは、連携するサービス等に通知を行う
機器側のアプリケーションやファームウェアの更新、機器の交換等ができる
といった機能群を IoT 実装ドメインとして扱い、必要なコードや実装ルールを作ってやれば、実ビジネスの IoT アプリケーションを概念モデル化し、対応付けつつコードを生成してやれば、動くシステムが出来上がると考えます。
マイクロソフトは、クラウドソリューションを構築する際のガイドを、「Azure アーキテクチャセンター」から公開しています。このサイトでなされている説明と”概念モデリングと概念モデルからの変換による実装”による開発の進め方は何ら矛盾がありません。それぞれのビジネスにおける IoT Solution を、”IoT アプリケーション”と”IoT 実装”の二つの独立したドメインに分割することによって、IoT で何をやりたいのかが明確になり、”IoT 実装”ドメイン側の技術革新への対応が容易になります。
また、成功した IoT Solution は利用ユーザーも増え、接続される機器も増えていき、扱うデータ量もそれにつれて増えていきます。せっかく苦労してシステムを開発して運用を開始したら利用ユーザー数や接続機器数が増えてキャパオーバーで作り直しになってしまったら悪夢以外の何物でもありません。そんな事態を防ぐために、”IoT 実装”ドメインには、同一のサービス構成で、機器接続数やユーザー数がそこそこな時にはそこそこの運用コストで、機器接続数やデータ量が膨大になったらそれなりの運用コストで運用可能な、スケーラビリティが必要です。また機器の接続だけでなく、利用ユーザーに対する必要十分なセキュリティも必要です。これらは IoT だけでなく、その他のクラウドソリューションでも適用可能なものです。
必要十分なスケーラビリティとセキュリティを提供するクラウドサービスを採用することによって、IoT ソリューション構築にかかる開発コストと運用コストが低減します。
これらを踏まえ、現在提供されている IoT 系サービス群の技術情報を元に、IoT ソリューションの推奨構成は、著者の知識と体験も踏まえて、
の様な感じになります。実際にはいろいろな微調整が入るので、必ずこの様な構成にしなければならないと決まっているわけではないですが、この構成で大抵の IoT Solution は実現可能です。
それぞれのサービスの詳細に興味のある方は、Microsoft Docs で確認してい見てください。
このマガジンの一連のコンテンツ群は、この構成を実現するためのピースを順番に説明していきます。
例えば、Azure IoT Hub のサービスリソース作成手順など、Microsoft Docs に詳細に説明されているものは、マガジンの記事では追加の説明が特に必要ない場合は割愛するものとします。
実案件での実装支援をご希望の方は、別途有償で対応させていただきますので、master@kae-made.jp までご連絡ください。
ここから先は
IoT・Digital Twins を極めよう！
2022年3月にマイクロソフトの中の人から外の人になった Embedded D. George が、現時点で持っている知識に加えて、頻繁に…
この記事が気に入ったらチップで応援してみませんか？
