ビルOSのデータ構造について整理してみた。

こんにちは。ANDPAD ZEROの佐々木です。
ちょうど１年前に「スマートビル」や「ビルOS」に関する記事を投稿しました。
今回は、さらに少し踏み込んで「ビルOS」のデータ構造について整理してみようと思います。

前回の記事のおさらいになりますが、「スマートビル」というのは、IoTやクラウド、AIといった技術を活用し、設備の稼働状況・人流データ等を把握したり、得られたデータをもとに、ビルの各設備やサービスを高度に制御したりコントロールしたりできるビルを「スマートビル」と呼ばれています。

図1.スマートビルの果たすべき役割(引用元：スマートビル総合ガイドライン,p9,独立行政法人情報処理推進機構)

そして「ビルOS」とは、「スマートビル」が取得したデータを収集・蓄積し、他のサービスなどと連携することができる「データ連携基盤」のことをいいます。
「ビルOS」の具体的な機能として建物関連データの保存や設備機器の稼働データの保存、設備機器の遠隔制御やなどを取得することで、設備機器の効率的な運用や保守の効率化、さらにはビル自体のエネルギー効率の向上などを行い、ビルの運用と管理を最適化することが期待されています。
今回のnoteでは、このように多岐にわたって期待されている「ビルOS」の中でも、建物の「維持管理」について焦点あてて「ビルOS」のデータ構造を考えてみたいと思っています。

「維持管理」のために必要なデータ

まず始めに、ビルを管理する維持管理業務とはどんな業務があるか、それに必要なデータは何か、について考えてみます。
維持管理業務について詳しくかかれている『建築保全業務共通仕様書』『公式ファシリティマネジメント』を参照してみると、「維持管理」と一口にいっても、「点検・保守」「保全(修繕・改修)」という大別の中に様々な細かい業務があることがわかります。

さらに、これらの様々な維持管理業務を行う際に、必要な情報として以下の情報が挙げられます。

維持管理業務では建物の性能や機能の確保や建物利用者のニーズの変化に伴い点検・保守・修繕・改修などを行うため、建物の過去データや適切な維持管理を行うための将来にわたる計画など目的に応じたのデータの蓄積が求められています。

図2.ビルOSと維持管理業務のイメージ

これらの情報を各社が独自管理していくと、管理会社を変更する際や建物を売却をした際などにデータの引継ぎがとても大変になりますよね。また、システム観点では様々なシステム間で連携する際に正確な情報をシームレスに伝達をするために「"データの標準化"を図りましょう」というアプローチが2016年頃からあります。
これからデータの標準化を図るための「ビルOS」の代表的な3つのスキーマ(データ構造の定義)をお伝えしていきたいと思います。

ビルOSにおけるデータ構造

ビルOSに必要な情報のデータの持ち方として、代表的なデータ構造を３つ紹介します。
１:RealEstateCore　
２:Brick Schema
３:W3C Building Topology Ontology

それぞれのスキーマ(データ構造の定義)の目的やフォーカスに違いがあるため、解説していきたいと思います。

「RealEstateCore」のデータ構造

スマートビルアーキテクチャガイドラインでスマートビルのデータモデルと親和性の高いデータ構造として考えられているものの１つが「RealEstateCore」です。

「RealEstateCore」は、Microsoft社がスウェーデンの不動産業界団体「RealEstateCore」と協力し、建物所有会社や建設会社、取引先会社などが建物に関する情報をデジタル情報で伝達および共有するためのデータ構造をオープンフォーマット化し、様々なシステムで相互に運用可能なデータ構造を構築することを目指すものです。
そのため、不動産全般の管理にフォーカスし資産管理や契約管理などを扱う不動産業界のデータ構造という特徴があります。

「RealEstateCore」では次のようなデータ構造となっています。
①建物情報：建物の基本情報や建物ドキュメントなどの情報
②資産情報：設備機器、建材、什器などの種類、性能、耐用年数などの情報。
③空間情報：各部屋や設備、配置などの情報。
④関係者情報：管理者情報や取引先情報などの会社、ユーザーに関する情報。
⑤監視点情報：IoT機器等のセンサーによる設備機器の問題や故障の監視結果情報。
⑥イベント情報：保守計画や保守スケジュール、過去の保守実施状況やリース情報などの情報。

RealEstateCoreを活用して表現できるユースケース例としては
「建物A（①建物情報）の空調設備の耐用年数（②資産情報）が近づいているので、まずはB階の事務所の天井に設置された空調設備（③空間情報）について、設備管理会社（④関係者情報）に対して、過去の点検情報（⑤監視点情報）も踏まえて、新たに点検（⑥イベント情報）してもらう」といったユースケースの際に利用できるのではないでしょうか。

図3:RealEstateCore(引用元：https://www.realestatecore.io/introduction/)

「Brick Schema」のデータ構造

スマートビルアーキテクチャガイドラインで、「RealEstateCore」と同様にスマートビルのデータモデルと親和性の高いデータ構造として考えられているのが「Brick Schema」です。

「Brick Schema」は「Brick Consortium, Inc」という建物の運用管理に関するデータの標準化と統一を目的とした非営利組織が運営しているコンソーシアムで開発されたオープンソースです。
「RealEstateCore」では不動産業界に関連するデータの標準化でしたが、「Brick Schema」は空調や照明、センサーなどを階層的なデータ構造で表現し、ビルディングオートメーションを促進するためのデータ構造という特徴があります。
①場所情報（Location）：区画単位や機器グループなどの情報。
②装置情報（Equipment）：設備機器に対する制御装置の情報。
③センサー等監視点ポイント情報（Point）：空間や機器に設置するセンサーや監視点の情報。

Brick Schemaを活用して表現できるユースケース例としては
「事務所（①場所情報）の空調設備（②装置情報）の湿度センサーが湿度を自動測定した結果（③センサー等監視点ポイント情報）を記録する」といったユースケースの際に利用するようなイメージです。

図4:Brick Schema(引用元：https://docs.brickschema.org/intro.html)

「W3C Building Topology Ontology」のデータ構造

最後に業界標準のデータ構造として、「W3C Building Topology Ontology」を紹介します。
「W3C Building Topology Ontology」は、主に空間情報要素にフォーカスした分類で構成されたデータ構造となっており、建物内のさまざまな要素間の関係性を標準化された方法で建設業界とその他の業界間で円滑なデータ連携を実現するための最小限の構成となってます。
①敷地情報（site）：1 つ以上の建物を含むエリア情報。
②建物情報（building）：空間構造を持つ1つの建物単位の情報。
③階情報（storey）：建物の階数単位の情報。
④空間情報（space）：物理的または概念的にカテゴライズされたグループ情報。

W3C Building Topology Ontologyを活用して表現できるユースケース例としては
「駅前に所有する区画（①敷地情報）の自社ビル（②建物情報）の3階（③階情報）の事務所（④空間情報）の空調設備を点検する。」といったユースケースの際に利用できそうなイメージです。

図5:W3C Building Topology Ontology(引用元：https://w3c-lbd-cg.github.io/bot/)

まとめ

今回は、スマートビル、ビルOSという話題から一歩踏み込んで、ビルに関するデータ構造について、３つの具体例を示しながら整理してみましたがいかがでしたでしょうか。それぞれのデータ構造の特徴や、フォーカスしているポイントについても少し雰囲気が伝わったのではないかと思います。

施設を維持管理する際に必要なデータについて、目的やニーズ、ビルの規模などに応じてデータ構造やスキーマをうまく選択することで、建物のデジタル化やデータ連携などの最適化が進むことで維持管理業務が円滑化できるのでは、と考えています。さらに、新たなサービスとの連携、副次的な効果があると施設利用者にとって利用しやすくなることにも期待したいですよね。

最後にはなりますが、将来的にはこのようなデータ構造の標準化により、より多くのデータが有効活用できると、ビルや都市のスマート化が実現していき、都市全体でのSociety5.0が掲げる「持続可能性と強靭性を備え、国民の安全と安心を確保するとともに、一人ひとりが多様な幸せ（well-being）を実現できる社会」に繋がっていく将来も有りうるのないでしょうか。