日本建築学会技術報告集 第 26 巻 第 64 号，1246-1251，2020 年 10 月
AIJ J. Technol. Des. Vol. 26, No.64, 1246-1251, Oct., 2020
DOI https://doi.org/10.3130/aijt.26.1246

BIMとデータ分析手法を用いた
BIM とデータ分析手法を用いた設備システムのモデル生成に関設備システムのモデル生成に
する研究
関する研究

RESEARCH ON DATA MODELRESEARCH ONOF
DATA
MODEL
GENERATION
BACS
USING
GENERATION
OF
BACS
USING
BIM
AND DATA ANALYSIS METHOD
BIM AND DATA ANALYSIS METHOD

粕谷貴司ー ーーー＊ 1, 2

Takashi KASUYAーーーー＊ 1, 2

＊1, ＊2

Takashi KASUYA

粕谷貴司＊1, ＊2
キーワード：
キーワード：
BIM，BACS，IoT，データ分析，メタデータ
BIM，BACS，IoT，データ分析, メタデータ

Keywords:
Keywords:
BIM,
BACS,IoT,
IoT,Data
Data
analysis,
Metadata
BIM, BACS,
Analysis,
Metadata

With the spread of AI and IoT, BACS (Building Automation and Control
With the spreadof becomeAI and IoT,
BACS
(Building Although
Automationand ofControl
Systems)
has alsomoresophisticated.
many
these
Systems)arehascloud-based,also become themoresophisticated.
many of thesesystemslackof metadataAlthoughin data collectedfrom
systems are cloud-based, the lack of metadata in data collected from local
local
BACS creates problems such as inconsistency with local devices
BACS creates problems such as inconsistency with local devices andanddifficultyin cross-cutting
data analysis.
In thiswepaper,
we metadata
proposedifficultyin cross-cutting
data analysis.
In this paper,
proposemetadata
and information
model methods
generationforassignmentassignment
and information
model generation
formethods
cloud-based
cloud-based
BACS
BIM andanalysis.
developed
BACS using BIM
andusing
data analysis.
Wedatadeveloped
andWe
evaluateda toolandtoevaluateda toolto automate
extraction
ofinfer
spatialandoftoa
automate theextractionof spatialthe
structureand tothe structure
suitable classpoint theof BACSby datainfer
suitableclassanalysis.
of a point of BACS by data analysis.

１．はじめにBuilding Automation and Control Networks）と呼ばれるプロトコ

IoT（Internet of Things）や AI(Artificial Intelligence)など

ルが用いられている。BACnet は BACS の制御，操作および監視用にの技術革新やクラウドの普及などの背景を受けて，建物の自動管理設計された国際標準であり，1995 年に ASHRAE で発表されてから，制御システム（BACS：Building Automation and Control System）

時代に応じた多くの拡張がなされている。

も高度化している。ウェアラブルデバイスや無線センサなどを使う

BACnet は，対象データを「オブジェクト」という抽象概念で規定ことで，一般的な BACS では扱いが難しいヒューマンファクターや，し，ネットワーク接続されるデバイスをオブジェクトの集合体とし

きめ細かな環境情報が取得可能となる。これら IoT を活用して省エてモデル化しており，それぞれのオブジェクトのプロパティを読み

ネと快適性の両立を実現する技術 1)や，AI を使って運用コスト削減，

書きし，相互に受け入れ可能なサービスを実行することによってデ2)が普及してきた。こうしたバイス間の通信を実現する。この際，サブシステム間の連携作業効システムの多くはクラウドサービスとの連携を前提として設計され率化のために，デバイスがどのようなオブジェクトとプロパティを

異常検知の自動化と省人化を狙う技術

ている

3)

が，標準のデータモデルや命名規則などが普及していない

ため，異なるアプリケーションでのデータ再利用が難しい 4)5)。
一方，BIM(Building Information Model)が普及し，建物の設計・有しているかを確認するために，CSV ファイルフォーマット 6)が規定されている。なお，BACnet オブジェクトから制御・監視されるデータは，一般的にはポイントと呼ばれる。

生産のデジタル化が加速している。2019 年 6 月には，国土交通省に

我々は，それらの課題分析のため，BACS と連携するクラウドシス

よって建築 BIM 推進会議が設置され，BIM 活用のあるべき姿に向けテムの構築手順をヒアリングにより整理した。図 1 に BPMN(Businessて目標が設定された。BIM ライブラリーコンソーシアムによる BIM

Process Model and Notation)による構築フローを示す。

オブジェクト標準の制定も進んでおり，BIM モデルに入力すべき設

空間構成や関係性といったセマンティクスを含んだ BACS 用のデー
タモデル生成の自動化が可能であると考えられる。
上記の背景を受け，本研究ではクラウドを前提とした BACS において，BIM とデータ分析を用いたデータモデル生成手法の提案を行う。

（詳細）
設計仕様作成通信仕様
作成

ネットワークベンダー

まれる情報を活用することで，設備機器属性などのメタデータや，

ｸﾗｳﾄﾞｼｽﾃﾑベンダー

どで，BACS においては活用されていない。しかしながら，BIM に含既存のクラウドシステム構築プロセス

はツール間でのデータ受け渡しのために整備されているのがほとん

設備システム
ベンダー

設計者

備機器の標準的なプロパティセットの定義も進んでいるが，現状で

ポイント
リスト作成

システム構築・試験計画作成ネットワーク
インフラ構築・試験計画作成ﾈｯﾄﾜｰｸ・
通信仕様

単体試験

単体試験

総合連動
試験

ポイントリストｼｽﾃﾑ設計要件
通信仕様作成システム構築・試験計画作成単体試験

図 1 B A C S 連 携 し た ク ラ ウ ド シ ステ ム の 構 築 フ ロ ー
２．現状分析と提案手法
2.1 現状分析

まずは設計仕様に基づき，各設備システムベンダーは通信仕様やBACS において，照明設備・空調設備といったサブシステム間連ポイントリストを作成する。それぞれの仕様をネットワークベンダ

携 に は 一 般 的 に BACnet （ A Data Communication Protocol forーやクラウドシステムベンダーに引き渡し，システム構築や単体試＊1
東京大学情報理工学系研究科大学院生
大学院生
東京大学情報理工学系研究科（〒
113-8656 東京都文京区本郷
7 7丁目（〒113-8656
東京都文京区本郷丁目3-1）
3-1）*2㈱竹中工務店情報エンジニアリング本部課長 課長＊2(株)竹中工務店 情報エンジニアリング本部

*1

1246

*1
Graduate Student,
Graduate
SchoolGraduateof Information
Science andTechnology,	Graduate
Student,
School of Information
Scienceand Technology, The
The University of Univ.
Tokyoof Tokyo*2
Manager, ICT Engineering Dept., Takenaka Corporation＊2
Manager, Takenaka Corporation, ICT Engineering Department＊1

験の準備を行う。ネットワークベンダー，クラウドシステムベンダた形状（ソリッドモデル）と形状に付帯する属性などを保持していーの構築，単体試験が終了し準備が整った時点で総合連動試験が行る。空間構成などのセマンティクスも保持するために，IFC から適われる。

切な情報を抽出することで，BACS のデータモデル生成の一部自動化

クラウドシステムベンダーはポイントリストを受領し，ポイントが可能であるといえる。

名（オブジェクト識別子，オブジェクト名，デバイス名）をもとに，

BIM を活用したメタデータ生成フローを図２に示す。図１に記載

制御・監視対象の特定を行うとともに，システムで利用するポイン

あるポイントリストを受領した後のフローとなっている。リスト受

ト表示名の変更・登録を行うが，受領したポイントリストのメタデ

領後，分析モジュールを使って BIM から空間グラフを生成する。空ータ欠如によって，デバイスとポイントの不整合といったヒューマ

間グラフとは，空間的な包含関係を有したグラフ構造のデータモデ

ンエラーが起きやすいことが課題となっている。これらの課題は，

ルであり，例えば「敷地→建物→フロア→部屋」といった階層的な

BACnet のオブジェクトに対して，それが空調システムのポイントな構造を指す。IFC には，IfcSite, IfcBuilding, IfcBuildingStoreyのか，どの空間を対象としているのかといったセマンティクスの記といった，上記に対応するクラスが定義されており，それらを抽出・述がないことに起因していると考えられる。Semantic Tags と呼ば構造化することで，空間要素の階層化が可能である。

れるプロパティにより，セマンティクス付与も可能だが，付与のインセンティブもなく，現段階ではほとんど普及していない。

次に BACS のポイントを空間グラフにマッピングする。例えば，温度センサのポイントを計測対象の部屋に紐づける。これらはポイン
ト名に，
「2FL」
「会議室１」などが付いていれば自動化できる。マッ
ピング後のデータに対して，関係性やクラスを付与するとともに，構築し運用している 1)3)。クラウドへのデータ発出には MQTT を用い必要に応じて IFC から抽出した属性などのメタデータを付与する。

ており，１棟当たり 1000 点を超えるポイントに対して手動でメタデ

最後にシステムで利用する表示名を付加するとともに，データア

ータ（表１）を付与し，それを Topic や Payload といったフィール

クセスのためのアドレス（URI）を付与し，対象データへの参照を保ドに埋め込むことでデータの判別をしている。小規模な建物であれ持しポイントマスターとする。これによって，クラウド側のシステば命名規則などを設計者がすべて管理できるが，大規模の場合，利ムで BACS のポイントを利用する準備が完成する。

用する語彙などは各ベンダーにゆだねることが多く，そのため施設ごとに異なる語彙が用いられる。そのためデータの集約はされてい設備ｼｽﾃﾑベンダー

一方，我々は BACS のポイントに対して独自にメタデータ付与を行い，制御アプリケーションのためのクラウド・プラットフォームを手動実施

必要に応じてタグ付け、ｽｷｰﾏ定義ポイントと空間グラフのマッピング

ﾃﾞｰﾀ・
ﾓﾃﾞﾘﾝｸﾞ/ﾒﾀﾃﾞｰﾀ付与

ツール等でるものの，計測・計量データの横断的な分析が難しくなっている。

IFCから自動生成

No

属性

01
02
03

Where/

Key

例

事業者

com / org / etc.

敷地 site

THX / R90 / TAK-E /etc.

棟 building

棟名階 floor

階数 / outdoor

05

エリア area

フロア分割貸事務所など

06

カテゴリ category

空調/照明/電力/防犯/防災/衛生07

種別 kind

対象種別 温度/湿度/LED/型 type機器メーカ / 型式 など

09

名称 name

機器の識別名称 topic 内で一意10パラメータ名 key

温度 / 湿度 / 照度 など

読・書

R/W

04

08

11

Who

what

R/W

設備システム
エンジニア

空間グラフ
の生成

ポイント名を、ｼｽﾃﾑで利用する
URI等に変換

ポイント名・
変換/生成

ポイント
ﾏｽﾀｰ登録ｼｽﾃﾑ構築エンジニア

表 1 M Q TT の To p i c 命 名 規 則 （ 付 加 さ れ た メ タ デ ータ ）クラウドベンダー

ポイントリスト受領

クラウド
ｼｽﾃﾑ構築データモデルポイントマスター

UIデザイン方針

BIM（IFC）

図 2 B I M を 使 った メ タ デ ー タ 生 成 フ ロ ー(2) ビルプロ（建物活動プロファイル）の活用
設備，IoT のポイントについてのメタデータを付与する研究としては海外を中心に多くの研究があるが，①ポイント名から類推するもの 4)7)，②データから類推するもの 8)9)，③ツールを使ってメタデータ付与をサポートするものがある 5)10)。①は，ポイント名から正規表現等を使って類推するものであり，例えば「AHU-1-RAT」は空気

2.2 提案手法
本研究では，前述の課題解決のため，BACS におけるデータモデル
生成の簡易化のための手法を提案し，評価・検証する。提案手法の技術的な方針としては，BIM とデータ分析を使ってセマンティクス
やクラス，タグ，メタデータ付与の自動化・半自動化を実現すること，セマンティックウェブの手法を導入することとした。
(1) BIM の活用
本稿では，BIM のデータ交換のための標準形式の１つである IFC（Industry Foundation Classes）の利用を前提とする。IFC は 2013
年に ISO 16739 として国際標準化されており，BIM のデータ交換用
フォーマットとして活用されている。IFC は，BIM モデルから抽出し調和機の１番の還気温度と推定する。いずれの手法も有効であるといえるが，①は日本におけるサンプルが少なく汎用化が難しいため，
本研究では②を採用する。
②において，Hong らは BACS におけるポイントデータのクラス分類を，取得した時系列データを一定のタイムウィンドウで区切った
際の中央値，上下限値，分散などを特徴量として，Random Forest
等による分類を行っている 8)。80％以上の高い推定精度があるが，1週間程度の短い期間のデータによる試行であり，例えば夏のデータを使って冬のデータの推定をすることは難しい。長期的なデータ使った汎用的なクラス分類を行うため，我々はビルプロ 11)を使った分類を試みる。
ビルプロは，BACS や IoT から取得される時系列のセンサデータに1247

対して，教師なし学習によるクラスタリングを行うことで，モードいる方針とした。

と呼ぶ離散値とダイナミクス（時系列データの生成モデル）をもつ
ハイブリッドシステムに変換する。翌日にセンサがどのような挙動をとるか確率的に推定することが可能になり，更には複数のセンサ
データを集約したモードを定義することで，建物全体の挙動の推定が可能になる。ビルプロによって得られるモードとダイナミクスは，
汎用的なセンサの挙動を示しているといえるため，事前に得られた結果と，新たに得られた未知のセンサデータを比較することで，データ種別の推定が可能と考える。図３はある物件における 2 年間分

図 4 B O T に よ る空 間 記 述 例の相対湿度のデータに対するビルプロの適用結果である。5 個のモードが検出されており，それぞれのモードのダイナミクスが確認で正式リリースはされていないが同様の空間グラフを用いたサービきる。これらの意味するところは，年間を通じて 5 種類の時系列パスとして，Azure Digital Twins(ADT)注３)がある。ADT はスマートビ

ターンに分類できるということであり，これらに対して距離・類似

ルのプロジェクトでの対応経験から抽出されたデザインパターンを度を定義することによって，未知の時系列データの推定を行う。

抽出してサービス化したものである。ADT では空間グラフと，そこに付帯するデバイスとその状態，ロジックを結びつけるもので，対応する形状の管理は行わない。現状では，空間グラフやデバイスのクラス定義等は，ユーザが RDF（JSON-LD）により記述する仕様になっており，語彙の定義や自動化の仕組みなどは提供されていない。
設備ドメイン以外で利用可能なオントロジーとしては，スマートシティの概念モデルとして BSI が公開している PAS182(Smart city
concept model)がある。多様なリソース間の関係性をイベントやエージェントという概念を用いてモデリングすることができるが，BACS における制御モデルからすると汎用的すぎるといえるため現

図 3 ビ ルプロ によ る 分 析 例(3) セマンティックウェブの導入

状では考慮しない。

３．提案手法の適用と評価

ASHRAE の AP-WG では，Building Automation Systems Information

前節で述べた方針に従って，BIM によるデータモデル生成・メタ

Model (BAS-IM)の標準化活動を行っている注 1)。目的はセマンティッ

データ付与のためのシステムを開発し評価する。図５に BACS や BIM

クな相互運用性を担保するための，データモデルの策定であり，からのデータ抽出とモデル生成のパイプラインを示す。本システム

RDF(Resource Description Framework)によりデータの関係性記述をはインターネットに親和性の高い技術を多く用いており，BACS や行い，それらを蓄積した知識ベースによるアプリケーション構築を

IoT のデータに加え， BIM から抽出した形状データも活用可能なデ提案している。記述のためのオントロジーとして，設備ドメインにジタルツインのためのシステム・アーキテクチャとなっている。

おいて中心的に利用されているのが Brick12)である。Brick では，中3.1 BIM からのデータ抽出

心的な Point，Location，Equipment の 3 つのクラスを用いて設備シ

図５における BIM から始まるデータ変換・抽出について述べる。

ステムのモデリングが可能である。それらの語彙に加えて Building，

BIM・IFC から必要な属性を抽出するとともに，形状データも抽出し，

Floor，Room といった空間的な語彙も存在するが，本研究では BOT

それらを DocumentDB（MongoDB など）やウェブサーバに格納するこ（Building Topology Ontology）注 2)を用いる方針とする。BOT は W3Cとで，インターネットから参照しやすくしている。なお，RDF からのコミュニティで検討されており，最小限の語彙でありながらの情報抽出については，一般的には SPARQL Endpoint が使われるが，

Brick を含めた多様なオントロジーとの共存を意識して設計されて現状想定しているユースケースにおいては複雑なクエリを使うこといる。BOT による空間構成の記述例を図４に示す。空間の記述粒度がないために，JSON-LD とも親和性の良い DocumentDB を用いる。

としては，先に述べた IFC のクラス構造とほぼ等しい。

まず，BIM ツールから変換した IFC を，開発した Parser モジュー

Brick は設備システムを精度よくモデリングすることができるが，ルを使って属性と形状に分離する。IFC から BOT を用いた RDF を出

現状のユースケースではそれらの情報が使われることは少ない。例

力ツールとして IFCtoLBD 注４)があるが，形状抽出ができないため，

えば，空調機と吹出口の関係性を feedsAir という語彙で記述するこIfcOpenShell 注５）を用いて開発した。IfcOpenShell はオープンソーとができるが，例えば AI による建物制御の一例では，入力（計量・スの IFC 操作用のライブラリであり，3DCAD 用のライブラリである

計測値など）と出力（制御指令）の関係しか見ない。そのため空間

OpenCASCADE を内包しているため，IFC に表現されたソリッドモデル

グラフの生成については，IFC から抽出した階層構造をもとに BOTを扱うことができる。BACS においては，壁や機器といった要素の形を用いて行うこととし，設備システムの関係性記述については将来

状よりも，それらを包含する空間を対象とすることがほとんどであ的な課題とした。ただし，BACS のポイントがどのようなスキーマやるため，本ツールでは IFC に表現された空間形状のみを生成・抽出

プロファイルを持つか定義するために，Brick のクラスやタグを用することとした。具体的には以下のような処理を実行する。

1248

図 5 デ ー タ 抽 出，メ タ デ ー タ 生 成 のパイ プラ イ ン①

IfcSite/IfcBuilding を特定し，対応する BOT のクラス
（Site/Building）に当てはめるとともに属性を抽出し，RDF

表 2 I FC から出 力 した RDF（ 抜 粋 ）{"@id": "http://hongo.wide.ad.jp/001/51_2858","@type": "https://w3id.org/bot#Space","GlobalId": "3q4P0iC9P33P2WOFzvBOXb","InteriorOrExteriorSpace": "INTERNAL","LongName": "トイレ","Name": "51","containsElement": [{"@id": "http://hongo.wide.ad.jp/001/小便器_-_壁掛け_185515"},{"@id": "http://hongo.wide.ad.jp/001/カウンタートップ_135950"},{"@id": "http://hongo.wide.ad.jp/001/洋式便器_6_135895"},{"@id": "http://hongo.wide.ad.jp/001/洗面器_1_135851"},{"@id": "http://hongo.wide.ad.jp/001/洗濯流し_2_135873"},{"@id": "http://hongo.wide.ad.jp/001/洋式便器_6_135827"},{"@id": "http://hongo.wide.ad.jp/001/小便器_-_壁掛け_185537"}],"id": 2858,"type": "IfcSpace"

リソースを生成②

IfcBuilding に含まれる IfcBuildingStorey を抽出し，①と同様にクラス（Storey）を当てはめ RDF リソースを生成③

IfcStorey が内包する IfcSpace を抽出し，①と同様にクラス（Space）当てはめ RDF リソースを生成④

IfcSpace に IfcExtrudedAreaSolid や IfcFacetedBrep といったソリッドモデルの定義がある場合，3 次元メッシュの一
般的なファイル形式である OBJ や，ウェブへの親和性向上を意図して GLTP に変換⑤

IfcSpace が IfcBuildingElementProxy などの要素を持つ場
合，包含する要素として RDF リソースを生成}

出力後のデータ例を表２に示す。@id が空間を表すユニークな ID
であり，@type が該当するクラスを表している。GlobalID 以下は IFCから抽出した属性情報であり，例えば LongName に「トイレ」という名前が抽出されている。また，containsElement という BOT の関係
性語彙に，空間内に配置された要素（便器など）も抽出されている。
図６は出力データの可視化例である。ここで確認できる木構造の空間グラフのそれぞれのノードに対して，BACS のポイントのマッピン

形状の出力例を表３，図７に示す。表３は OBJ 形式のファイル抜粋である。g(グループ)要素に表２と同じ GUID が確認できる。なお，
GLTF においても IfcSpace に定義された一意な GUID を参照として保持しており，GUID をキーにして該当エリアの検索が可能であるため，
例えば図７の空間を選択して，そこにポイントをマッピングすることも技術的には可能である。

グを行う。現状では専用の CSV フォーマットを用いてデータモデルの生成を行っているが，将来的には BuildingDepot10)のようなウェ
ブ UI の開発も検討している。

表 3 I FC から出 力 した 形 状 データ（ 抜 粋 ）g 3q4P0iC9P33P2WOFzvBOXb
v 10.96057102927976 -6.802963308029869 8.200000000000049
v 10.96057102927976 -6.802963308029869 11.700000000000049
v 10.96057102927976 -7.20296330802987 8.200000000000049
v 10.96057102927976 -7.20296330802987 11.700000000000049…中略
f 1078 1062 1070
f 1074 1076 1072
f 1076 1078 1072
f 1078 1070 1072

3.2 ビルプロによるクラス推定
本節では，図５の「Metadata Annotation」に該当する未知のポイ
ントに対するクラスの自動推定機能について述べる。
前提として，推定対象の設備ポイントのデータは，既にある程度
図 6 I FC から出 力 した RDF のデータ構 造

蓄積していることし，それらに対してビルプロで分析済みの学習データが十分にある環境を想定する。

1249

が同一であれば，対象とするデータのスキーマやタグを共通化することができるためで，例えば Outside_Air_Temperture_Sensor が
表 4 既 存 の デ ー タ セ ッ ト と ビ ル プロ 適 用 結 果

図 7 I FC から出 力 した 空 間 形 状

本検証では，都内近郊のオフィスビル（TAK 新砂ビル，竹中工務店東関東支店 1））の約 10 カ月分(2019/3-2020/1)のデータセットを
既知のデータとして利用し，推定対象のデータセットとしては，半年分(2019/8-2020/1)の EQ House13)のデータを利用する。分析対象のデータは 30 分毎の計測値であり，区分化された 1 日のデータとしては 48 次元の固定長となる。これらに対して欠損値補間などの前処理を行ったデータを利用する。
問題設定として，BACS の稼働後すぐにクラウドシステムで取得しKey

ポイント種別

対応するBrickクラス

Air_Direction

風向Wind_Direction_Sensor

データ数 モード数
24025

Air_Pressure

気圧（無線ｾﾝｻ）

Building Air Static Pressure Sensor

671

1

Air_Pressure-E

E側屋内外差圧圧力

Air_Differential_Pressure_Sensor

158

5

Air_Pressure-W

W側屋内外差圧圧力

Air_Differential_Pressure_Sensor

137

5

Air_Velocity

風速

Wind_Speed_Sensor

1081

Cal_Cum

ﾁﾗｰ冷温水積算熱量

-

526

21

Cal_Inst

冷温水瞬時熱量

-

1248

22

CHW_Cal_Cum

冷温水積算熱量

-

274

13

Cop

成績係数（単体）

-

770

7

DewPoint

露点温度（無線ｾﾝｻ）

Dewpoint_Sensor

652

8

Downside_Temp

蓄熱槽下層温度

Temperature_Sensor

229

1

Downside_Water_Temp

熱交換杭チューブ温度下部

Water_Temperature_Sensor

994

25

Downstream_Temp

集熱器下流温度

Temperature_Sensor

154

6

Humidity

湿度（無線ｾﾝｻ）

Relative_Humidity_Sensor

593

11

Illuminance

照度（無線ｾﾝｻ/人感ｾﾝｻ）

Illuminance_Sensor

6893

24

Indoor_Enthalpy

室内ｴﾝﾀﾙﾋﾟ

Air_Enthalpy_Sensor

458

1

Indoor_Humidity

室内湿度

Zone_Air_Humidity_Sensor

428

4Indoor_Temp

室内温度

Zone_Air_Temperature_Sensor

472

1

Input_Return_Water_Temp

再生温水入口温度

Hot_Water_Supply_Temperature_Sensor

190

3

Input_Temp

集熱器往き配管温度

Temperature_Sensor

190

5Input_Water_Temp

冷温水入口温度

Hot_Water_Supply_Temperature_Sensor

2108

10

Loudness音（無線ｾﾝｻ）

-

295

22

Middleside_Water_Temp

熱交換杭チューブ温度中部

Water_Temperature_Sensor

992

22

Outdoor_Enthalpy

外気温度ｴﾝﾀﾙﾋﾟ

Outside_Air_Enthalpy_Sensor

225

4

たデータに対して Brick クラスを当てはめることを考える。そのた

Outdoor_Humidity

外気湿度

Outside_Air_Humidity_Sensor

224

5

Outdoor_Temp

外気温度

Outside_Air_Temperature_Sensor

198

2

め，未知のデータとしては，数日分のみが利用可能であるとする。

Output_Return_Water_Temp

再生温水出口温度

Return_Water_Temperature_Sensor

197

3

Output_Temp

集熱器還り配管温度

Temperature_Sensor

149

5

Output_Water_Temp

冷温水出口温度

Return_Water_Temperature_Sensor

2109

7

であれば Outside_Air_Temperature_Sensor という Brick のクラスをRadiate_Thermometer-E

東側窓放射温度

Radiant_Temperature234

1

予め当てはめておく。2.2 節で述べたように，既知のデータセット

Radiate_Thermometer-W

西側窓放射温度

Radiant_Temperature

224

1

Rain_Detected

感雨ｾﾝｻｰ

Rain_Duration_Sensor

212

7

RainFall

感雨量

-

218

25
22

クラス推定のため，既知のデータセットに対して，例えば外気温度から得られたモードのダイナミクスと，未知のデータセットの距
離・類似度を定義することでクラスの推定が可能と考える。
距離の定義として DTW(Dynamic Time Warping)を採用する。DTW
は 2 つの時系列の各点の距離を総当りで比較した上で，系列同士の距離が最短となるパスを見つける手法であり，周期や次元数が異なる場合でも距離定義が可能である。対象のデータは固定長であるため，一般的なユークリッド距離も有効といえるが，比較を行ったところ，それぞれに傾向の違いはあるが，DTW の方が正しく推定した確率が高かった。

Return_Water_Flow

再生温水積算流量

Water_Flow_Sensor

212

Solar_Radiation

日射量

Solar_Radiance_Sensor

78

25

Surface_Temp

放射ﾊﾟﾈﾙ表面温度

Temperature_Sensor

2263

22

System_Cop

成績係数（システム）

-

769

8

Target_Temp

蓄熱槽温度設定

Temperature_Setpoint

2667

5

Temp

温度（無線ｾﾝｻ/人感ｾﾝｻ）

Air_Temperature_Sensor

51106

13

Toplight_Temp

ﾄｯﾌﾟﾗｲﾄ温度

Temperature_Sensor

208

1

Upside_Temp

蓄熱槽上層温度

Temperature_Sensor

261

3

Upside_Water_Temp

熱交換杭チューブ温度上部

Water_Temperature_Sensor

999

25

Upstream_Temp

集熱器上流温度

Temperature_Sensor

154

6

Water_Flow

冷温水流量

Water_Flow_Sensor

2070

22

Water_Flow_Cum

積算流量

Water_Flow_Sensor

246

5

Water_Level

揚水井戸水位

Water_Level_Sensor

223

19

Water_Temp

温水送水温度/揚水温度/etc..

Water_Temperature_Sensor

429

25

表４に分析に用いた既知のデータセットの概要とビルプロの適用
結果を示す。表１に示したメタデータが既に付与されているため，
Key を仮想的なクラスとしてグループ化しビルプロを適用した。対応する Brick のクラスについては，語彙定義が公開されていないため，名称をもとに設定したが，ZEB を含む特殊な建物のデータセッ
トであるためか不足する語彙も多かった。
「データ数」は区分化時系
列データの数であり，グループ化された数が多いほど大きくなっている。図 8 にビルプロ適用によって得られたモードのダイナミクス
例を示す。Temp，Outdoor_Temp はそれぞれ 13 個,2 個のモードが検図 8 推 定 し た モ ー ド の ダ イ ナ ミ クス

出されている。これらダイナミクスの平均値（mean）と，未知のデ
表 5 クラス推 定結 果

ータセットの時系列の距離を DTW ですべて比較し，距離が一番短いものを該当のクラスとする。
クラス推定の結果を表５に示す。評価に際しては未知のデータセットから 1 日ごとの区分化時系列をランダムに 100 回抽出し，距離比較を行い推定結果とした。なお，正解率は推定された結果が，対応するクラスでない場合も，カテゴリ（親クラス）が同じと判断できるものは正解としてカウントしている。理由としては，親クラス

1250

ﾎﾟｲﾝﾄ名（Key）

ﾎﾟｲﾝﾄ種別 対応するBrickクラス

Air_Pressure

気圧

Building Air Static Pressure Sensor

正解率[%] 最頻値
100 Building Air Static Pressure Sensor

Humidity

外部湿度

Outside_Air_Humidity_Sensor

69 Outside_Air_Humidity_Sensor

Rainfall

感雨量

Rain_Duration_Sensor

36 Cal_Inst (冷温水瞬時熱量）

Solar_Radiation

日射量

Solar_Radiance_Sensor

75 Solar_Radiance_Sensor

Temperture

外部温度

Outside_Air_Temperature_Sensor

88 Water_Temperature_Sensor

Wind_Direction

風向Wind_Direction_Sensor

90 Wind_Direction_Sensor

Wind_Speed

風速

Wind_Speed_Sensor

33 Rain_Detected (感雨ｾﾝｻｰ）

Water_Temperature_Sensor と検出されたとしても，単位や小数点以トに対して 70％程度の精度でクラス推定が可能であった。

下の扱いなどはほとんど変わらないためである。ただし，最大値・現在，提案手法をもとにした建物制御システム構築を進めている。

最小値などは変わる可能性があるため，それらの特定が必要な場合

提案手法による空間グラフ生成を行うとともに，階層化された BACS

は施設管理者が適切なサブクラスをつける必要がある。

のポイント情報を WoT（Web of Things）注６）に基づいて，インター

気圧や外部温度・湿度，風向については高い正解率が確認できた

ネットから RESTful API で取得・制御することが可能なデジタルツ

ものの，感雨量と風速は低い結果となった。対象のデータを分析しイン・アプリケーションのためのアーキテクチャであり，BACS・BIMてみたところ，感雨量は既往のデータセットに対して，1/10 程度のとインターネット技術の融合の加速することを狙っている。

値が検出されており，検出する際のスケールの問題であった可能性がある。風速については，33％は正確に推定しており，場所による謝辞

傾向の違いが大きな原因といえる。

本研究は東大グリーン ICT プロジェクトの BIM 基盤 WG の研究活動の４．考察を表します。

一環として実施した。調査等に多大な協力を頂いた事に深甚の謝意

4.1 BIM を用いたセマンティクスの付与について
3.1 節では IFC を使った空間グラフの生成について述べた。ここ

注ではそれぞれのノードに BOT のクラスを当てはめたが，IFC から抽

1) ASHRAE AP WG: http://www.bacnet.org/WG/AP/index.html

出したメタデータをもとに，「2FL」「3FL」などのタグ情報の付与す

2) Building Topology Ontology: https://w3c-lbd-cg.github.io/bot/

ることもできる。なお，空間グラフは理解しやすいといえるが，施

3) Azure Digital Twins: https://azure.microsoft.com/ja-jp/services/digital-twins/
4) IFCtoLBD: https://github.com/jyrkioraskari/IFCtoLBD

設管理の視点では，例えば設備種別ごとに集約したグルーピング（照5) IfcOpenShell: http://ifcopenshell.org/

明，空調など）が好ましい場合もある。それらを正確にモデリング6)

Web of Things: https://www.w3.org/WoT/

するとセミラティス構造になるが，建物種別や管理者ごとに固有であるため，それらは都度手動でのモデリングが現実的といえる。
また，Brick で提案されているモデリングは，BIM のセマンティク
スだけでは自動化すること難しいといえるが，例えばクラウドから
制御コマンドが発行できる場合，反応する設備を特定することで，

参考文献
1)

田中規敏，粕谷貴司：ウェアラブルデバイスを活用した空調システム，
空気調和・衛生工学 91⑻，pp.837-842，2017.

2) 倉田昌典：IoT とクラウド，AI 技術を活用した空調設備最適運用への取り組み，建築設備 第 828 号，pp.46-53, 2020.1

ある程度の自動化は可能と考えられる。これらについては，遠隔制

3) 粕谷貴司, 他９名：スマートシティのための MQTT プラットフォームの検御が必要であるため今後の課題としたい。

4) Balaji, B., et al.: “Zodiac: Organizing large deployment of sensors to

4.2 ビルプロによるクラス推定
本検証においては，クラス推定に関しては平均して約 70%の正解率となった。ただし，表５の最頻値で確認できるように意図したクラスとは別のクラスが一番多く検出されている項目もある。原因としてはスケールの違いや場所性などが考えられるが，これらはより多くのデータセットを得ることで解決される可能性がある。なお，
未知のデータが十分にある場合，ビルプロを適用することで，それぞれの生成モデルが得られるため，類似度の指標に 2 つの確率分布の差異であるカルバックライブラー情報量が利用可能で，それにより分散などの統計量を考慮した比較が可能になる。検証を行ったと
ころ， DTW による計算と比較して，計算量・計算時間については，かなり低減することができた。しかしながら，ビルプロの計算には
概ね 60 日以上のデータがないと適切なモード数にならないため，
BACS の稼働後すぐに適用するのは難しいといえる。

証, 情報科学技術フォーラム講演論文集 13(4), pp.1-6, 2014.8
create reusable applications for buildings”, BuildSys 2015, pp.13-22,
2015.115) Holmegaard, E., et al.: “Metafier - A tool for annotating andstructuring building metadata”, SmartWorld/SCALCOM/UIC/ATC/
CBDCom/IOP/SCI 2017, pp.1-8, 2017.8
6) 一般社団法人電気設備学会：BACnet®システム インターオペラビリティ
ガイドライン, 一般社団法人電気設備学会，2017.3
7) Bhattacharya, A., et al.: “Automated Metadata Construction To
Support Portable Building Applications”, BuildSys 2015, pp.3-12,
2015.118) Hong, D., et al.: “Sensor-Type Classification in Buildings”, arXiv.org,
20159) Hong, D., et al.: “The Building Adapter: Towards Quickly Applying
Building Analytics at Scale Categories and Subject Descriptors”,
Buildsys 2015. pp.123-132, 2015.11
10) Weng, T., et al.: “BuildingDepot 2.0: An Integrated Management
System for Building Analysis and Control,” Proceedings of the 5th
ACM Workshop on Embedded Systems For Energy-Efficient Buildings,
2013.

５．まとめ
本稿では，BACS のポイントに対して，空間との関係性などのセマンティクスを与えるために，IFC から階層構造を抽出し，セマンティックウェブの技術を用いてデータモデルを記述する手法を提案した。IFC を解析するツールを開発し，空間グラフと形状を抽出するとともに， JSON-LD で記述したデータモデルを自動生成することで，インターネットのアプリケーションとの親和性向上を狙った。
また，データ分析による BACS ポイントのクラス推定技術について

11) 高井 勇志 :建物活動プロファイル：建物内活動のモデル化と学習, 人工知能学会全国大会論文集, JSAI2016 巻, 2016.6
12) Balaji, B., et al.: “Brick: Metadata Schema for Portable Smart
Building Applications”, Applied Energy vol.226, pp1273-1292. 2018.9
13) 粕谷貴司：最新の IoT/AI を活用したスマートビルの実施例

EQ House における AI による無人制御への挑戦，建築設備 第 827 号，pp.24-30,
2019.12［2020 年 2 月 4 日原稿受理2020 年 5 月 8 日採用決定］提案した。ビルプロの分析結果を用いることで，未知のデータセッ

1251