情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

futaba：スマートビルのためのビッグデータ・プラットフォーム
粕谷 貴司1,2,a)

江崎 浩1

受付日 2020年5月19日, 採録日 2020年12月1日

概要：本研究では，スマートビル専用のデータ・プラットフォームである futaba を提案する．リアルタイムのビッグデータ処理技術であるラムダ・アーキテクチャと Web of Things による RESTful API を用いることで，リアルタイム制御とバッチ処理が両方が可能でスマートビルの多くのユースケースに対応できる高い汎用性を得た．また，スマートビルに有用なセマンティクスの提案を行い，プラットフォームのデータモデルに組み入れることで，サードパーティの新規参入障壁を下げ，アプリケーションの再利用性を向上させた．加えて，PaaS の採用と機能最適化により，毎分 5 万件のデータを想定した場合でも，ビッ
グデータ処理部が月額 1 万円以下で運用可能であることを確認した．
キーワード：スマートビル，ビッグデータ，セマンティックウェブ，web of things

futaba: Bigdata Platform for Smart Building
Takashi Kasuya1,2,a)Hiroshi Esaki1

Received: May 19, 2020, Accepted: December 1, 2020

Abstract: We propose futaba, a data platform dedicated to smart buildings. We obtained a high level ofversatility by using the Lambda Architecture and the RESTful API with Web of Things, that enables bothreal-time control and batch processing for many use cases of smart buildings. We also proposed semantics
applicable for smart buildings and incorporated them into the data modeling of the platform, lowering thebarrier to entry for third parties and improving the reusability of applications. In addition, by adopting PaaS
and optimizing functions, it was confirmed that the big data processing unit could be operated for less than
10,000 yen per month even assuming 50,000 data items per minute.
Keywords: smart building, big data, semantic web, web of things

1. はじめに
近年，建設業界において，設計・施工・維持管理業務のデジタル化が進んでおり，スマートビルと呼ばれる高度な由としては，技術革新に加え，3 次元形状や部材の属性情報なども含んだ総合データベースといえる BIM（Building

Information Modeling）の普及，震災による省エネ・BCP
需要の高まり，人材不足などの社会的要請がある．

制御機能を有した建物も増えてきている．スマートビル

スマートビルの普及が進む一方，実際にビル設備とクについては多様な定義が存在しているが，クラウド，IoT

ラウド・IoT・AI などを連携させようとした場合，多くの（Internet of Things），人工知能（AI: Artificial Intelligence）

課題が顕在化する．具体的には，多種多様なデバイスへなどを用いて，省エネや快適性・利便性の向上などを実現の対応が困難であること，収集されたデータに対してメするビルという理解がされている．スマートビル増加の理

タデータやセマンティクスを与える慣習がないこと，シ1

ステム運用に多額のコストがかかることであり，スマー

2
a)

東京大学
The University of Tokyo, Bunkyo, Tokyo 113–9656, Japan
株式会社竹中工務店
Takenaka Corporation, Koto, Tokyo 136–0075, Japankasuya@hongo.wide.ad.jp

c 2021 Information Processing Society of Japan

トビルの普及と新規参入を防ぐ大きな障壁となっている．
そのため我々は多様なユースケースに適合する汎用性を持つ，スマートビルの専用データ・プラットフォームであ867情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

Dawson-Haggerty らは，センサや BACS といった物理デ
バイスの情報をシンプルかつ効率的に交換するための技術である sMAP（Simple Measuring and Actuation Profile）
を提案している [2]．sMAP はインターネットを介した運用を前提とした RESTful なウェブサービスであり，デー
タモデルとインタフェースを規定している．デバイスの現在値の取得だけではなく，メタデータの取得や，WebSub
によるデータ取得も可能である．
図 1 建物設備制御システムの構成イメージ

彼らはさらに，BACS をよりプログラマブルにすること

Fig. 1 Building automation and control system.

を目的に，ハードウェアの抽象化を行い，アプリケーションの移植性を高め，耐障害性を高めるために BOSS（Building

る futaba（Facility Unified digital-Twin Architecture forOperating System Services）を提案した [3]．ビル用 OS を

Building Automation）を提案する．

目指し，sMAP をベースとした命名規則とセマンティクス

本論文では，2 章でビルの設備制御の中心である BACSを用いて分散環境におけるリソースの抽象化を行い，それ（Building Automation and Control System）を説明し，らを柔軟に扱うために独自のクエリ言語を開発し [4]，デー

3 章で関連研究について述べ，4 章で本研究の目的を述べ

タのバッファリングやリソースの発見機能，排他的制御をる．5 章で対象とするスマートビルの要件分析を行い，6 章実現するためのトランザクションやアクセス制御機能を提で futaba の設計要件について述べ，7 章でそれぞれの実装

供している．時系列データ処理のためのサービスを有してと評価について述べる．8 章で futaba によるアプリケー

おり，クレンジングなどの前処理の機能を組み込むことにション例について述べ，9 章で本論文の結論を述べる．

よって，アプリケーションの開発効率の向上を狙った．

2. BACS

Fierro ら は BOSS を 拡 張 し た XBOS（An Extensible
Building Operating System）を提案している [5]．XBOSBACS とはビル向けの中央監視制御システムを示すもの

はスマートビルのためのより高度なビル用 OS であり，特であり，ISO 16484 シリーズで定義されている．具体的に徴的なのは，ビルシステムのライフサイクル管理のためのは，ビルにおける電気，ユーティリティ，照明，空調，給排プロファイル（Building Profile）を定義していることであ

水衛生などの諸設備を中央監視室で一元的に監視，制御おる．Building Profile は空間階層のセマンティクスや，ビよび管理する機能を有し，設備の稼働状況を人的または自ルシステムの記述に必要なメタデータを含むが，独自記

動的に常時監視し，またトラブル発生時に適切に対応し，法を採用しており，拡張性に乏しい．そのため，Balaji ら

良好なメンテナンスを図るためのシステムである [1]．

は BACS に特有な語彙と関係性を定義したメタデータ・ス

図 1 に BACS の構成を示す．おおむね 1 万 m2 以上のキーマである Brick [6] を提案した．

ビルでは，空調・照明などのサブシステムをモニタリング・

Fierro らはさらに，上記の技術を組み合わせ，Mortar と制御する BACS が設置され，管理員が集中監視業務を行っ呼ばれるデータ・プラットフォームを開発した [7]．実在ている．一般的にサブシステムはそれぞれ構築ベンダが異するビルのデータ（90 棟）を集めており，それぞれ Brick

なり，スタンドアロンで動作するよう構築される．それらによるメタデータが付与されたうえで公開されている*2 ．

がゲートウェイ機器を通じて BACnet *1 などの専用プロト

Mortar は，スカラー値の保存の適したスケーラブルな時系

コルでシステム間の通信を行う構成となっている．BACS

列データベースである BTrDB [8]，データモデルストレー

は閉域網による構成を前提としていたが，近年インタージとして Brick に最適化された HodDB [9]，Go 言語で実装

ネット上のシステムとの連携事例が増えてきており，柔軟したクエリプロセッサなどで構成される．アプリケーショ

な連携の対応が求められている．なお，BACS で扱われるンの実行環境としては GRPC による API を提供しており，データは「ポイント」と呼ばれ，デバイスの状態値である

クエリプロセッサを介してデータ取得が可能である．

計測・計量・警報・状態・設定など表している．

3. 関連研究

SDB プロジェクトによる，BACS の高度化の貢献は大きいといえるが，課題としては，スカラー値以外は未対応
であること，システムの運用にサーバクラスタの稼働が必BACS にインターネットなどの技術を適用して，高度要があるため運用コストが高くなること，大量のポイント化を図る研究としては U.C. Berkeley の SDB（Softwareを有するビルの場合，人手でのデータモデリングが困難でDefined Building）プロジェクトで，多くの研究がされてあることがあげられる．

いる．
*1

https://www.iso.org/standard/71935.html

c 2021 Information Processing Society of Japan*2https://mortardata.org/

868

情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

ほかにも，SOAP を用いたストレージを中心としたアー

困難で参入障壁が高く，かつ構築したアプリケーショ

キテクチャによってエネルギー管理システムを構築した研ンの再利用性が乏しい．そのための適切なメタデータ

究 [10]，中小ビルのエネルギーマネジメントシステムの構と合理的なデータモデルを付与し，共通化した API を築を目的とした BEMOSS [11]，独自のドメインモデルに基提供することで，開発した機能モジュールの再利用がづいたアーキテクチャを提案している BaaS（Building as

可能な構成とする必要がある．

a Service）[12]，Lilis らによるメッセージ指向ミドルウェ

建設プロジェクトへ適用可能 既往研究では，コストや保ア [13] があるが，プロジェクトごとに利用しているメタ

守性などを考慮していないことが多い．たとえば，

データやオントロジが異なるために，横断的なデータ分析

HodDB や BTrDB は拡張性を確保するため，サーバ

や BACS の専門業者以外の新規参入が難しい，またはビックラスタを必要とするが，オンプレミス環境であってグデータ処理や AI 適用のユースケースを想定していないもそれらの保守・運用のコストと高額になる．ビル管などの課題がある．

理業務は費用削減がつねに求められているため，運用

一方で，Jara ら [14] は，IoT の相互接続性を向上させコストは可能な限り抑えて提案する必要がある．まるための仕組みが，Restful なアーキテクチャに基づいた

た，保守性の向上のために責任範囲の明確化が重要でWoT（Web of Things）であると述べている．WoT とはあり，プラットフォームを介したシステムの不具合が実空間上のオブジェクトである Thing に対して，インター

BACS に影響を与えない構成とする必要がある．

ネットの技術により情報取得や操作などの機能を提供する技術仕様であり，W3C で規定されている*3 ．WoT をス

5. スマートビルの要件分析

マートビルに適用する事例としては Bovet らの取り組みが本章ではスマートビルのユースケース分析を行う．実際

ある [15]．ローカルの分散環境下のデバイスに WoT のミのプロジェクトで構築した特徴的なユースケースを紹介

ドルウェアを組み込むとともに，独自のセマンティクス拡し，それらの分析から得られた要件と，スマートビルに必張を施したものであるが，BACnet を用いた既往の中央監

要なセマンティクスについて述べる．

視制御システムとの連携については考慮されていない．
本研究の提案は，位置情報などの多次元データといったスカラー値以外のデータに対応し，多様なユースケースに

5.1 想定ユースケース
5.1.1 IoT デバイスを用いた快適制御

対応するための柔軟なテレメトリ・スキーマ定義の導入，

IoT を使った BACS の事例として多いのが，快適性や利安価に運用を可能にするための PaaS を前提としたビッグ

便性の向上のための無線センサの活用である．粕谷らは，無データ処理基盤，BIM とポイントリストを用いたデータモ

線環境センサにより細かい温湿度などをとらえ，Bluetooth

デリングおよびセマンティクス付与，および WoT によるビーコンによって執務者の位置情報を取得するとともに，API の提供である．

ウェアラブルデバイスによって計測した心拍数，加速度か4. 本研究の目的

ら計算した代謝量をリアルタイムに計算している [16]．それらの情報と執務者の不快感申告も考慮したうえで，風量本研究の目的は，幅広いユースケースに適合する汎用制御が可能なパーソナルファンと天井の放射パネルの温度性を持つ実践的なスマートビル専用のデータ・プラットを制御することで，快適な温熱環境の提供を目指したウェフォームの構築である．前述の課題とプロジェクト経験か

ルネス制御システムを構築した．

ら設計指針として以下を定めた．

5.1.2 強化学習による高度な設備制御

多様なユースケース対応する高い汎用性 スマートビルに一般的な BACS では，ビル管理員や入居者の目標値設

おいては，即応性が求められるもの，1 日ごとのバッ

定や，熱源機器などはスケジュールに従って動作する．熱チ処理が必要なもの，複数ビルを制御するものなど，源機器の温度設定や運転スケジュールなどは，竣工時に決多様なユースケースが存在する．それらに対応するこめられた後にチューニングされることは稀で，されたとしとに加え，データ種別としてスカラー値以外の情報もても人手による制御では，省エネと快適性を両立させるよ扱える高い汎用性が求められる．

うな高度な制御の実現は難しい．そのためビル制御への再利用性の高いアプリケーション スマートビルのアプリ

AI 適用事例が増えており，たとえば強化学習を使って自ケーションは，IoT/AI を用いるなど BACS の専門会

律的にパラメータの最適化を行いながら制御する試みがあ社以外のサードパーティとの協業が多い．BACS でる [17]．ここではバッチ処理で抽出したデータをもとに制は，ポイントの意味や関係性を表すセマンティクスが御対象である目標値を予測する AI と，決められた目標値与えられることがほとんどないため，データの理解がから報酬を定め，それに従って行動（制御）をリアルタイ
ムに決める強化学習 AI の 2 つがあり，それぞれが独立し*3

https://www.w3.org/WoT/

c 2021 Information Processing Society of Japan

て学習を行う構成となっている．なお，強化学習によって869

情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

最適な設備の制御値を求める研究は Han らの調査 [18] に詳しい．この調査では，限定的な環境や制御対象での評価が多いが，文献 [17] のように多くの特徴量を前提とした制御も，実用段階に入ってきたといえる．

5.2 機能分析と設計要件
上記ユースケースに加え，プロジェクト対応経験から，
データ・プラットフォームに対して以下の設計要件を得た．

図 2 スマートビルのアプリケーションに必要なセマンティクス

Fig. 2 Suitable semantics for smart building applications.

制御ロジックの変更容易性 スマートビルではチューニン
グのために，頻繁な機能やロジック，パラメータの変更が想定される．それらを現地の設備改修で行うこと

5.3 必要なセマンティクス
建設ドメインにおいて，多様なメタデータ・スキーマやは，コストや事務的な手続きにおいて負荷が大きく，
クラウドから容易に変更をデプロイできる構成が望ま

オントロジが提案されている [21]．Brick は BACS におい

しい．そのため，遠隔更新が可能なゲートウェイを開て最も参照されているオントロジであり，十分な記述能力

発するとともに，パラメータ変更のための API を提供を持ついえるが，我々の対応したユースケースにおいては，することとする．

ここまで詳細なセマンティクスを利用するようなユース

リアルタイム性の高い通信プロトコル デバイスの遠隔制

ケースはほとんどない．たとえば，空調機（AHU）がどの御のために，ウェブアプリケーションを提供するこ

VAV（可変風量の吹出口）に対して空気を提供しているととが多いが [19]，たとえばポーリング型のアーキテク

いったことは feedsAir という語彙で記述できるが，それらチャを採用した場合，十分なリアルタイム性が確保で

静的関係性は，AI による遠隔制御やモニタリングといっきず満足度が著しく損なわれることがあった．このたたユースケースにおいてはほとんど利用されない．

め，IoT に親和性が高い Pub/Sub 型のプロトコルであ

図 2 はユースケースから導出した，スマートビルに必要る MQTT（Message Queuing Telemetry Transport）

なセマンティクスである．空間階層と空間に包含されるデを採用する．これは BACS と IoT の連携評価を行っ

バイスやセンサがあり，それらに紐づくポイントがプロパた先行研究 [20] の評価による．

ティとして記述される．これによって，クラウドシステム

ビッグデータ保存のために安価なストレージ ユースケー

では対象の空間を指定することで，内包されるデバイスなスで必要となる BACS のデータは 1 棟あたり数千〜

どの取得が可能になる．利用するオントロジは，空間階層

数万ポイントとなり，取得周期はおおむね 10 秒〜300の記述に適した BOT（Building Topology Ontology）*4 と秒である．また複数棟のユースケースも考慮すると，デバイスの記述に適した Brick を採用し，データモデルは

それらは必然的にビッグデータとなる．安価な運用のRDF（Resource Description Format）によって記述する．

ため，Apache Hadoop 用の分散ファイルフォーマッ

これにより，ポイント単位でのエンジニアリングから脱却

ト（HDFS: Hadoop Distributed File System）を用いし，オブジェクト指向のモデリングにより，開発者に対したビッグデータ処理基盤を構築する．

てより直感的なインタフェースを提供する．

共通機能の提供 電力負荷予測のユースケースでは，日本

こうしたモデリングは，BACS に詳しい設備エンジニアの電力計測の慣習に合わせて 30 分ごと（1 日だと 48が行う必要があるが，オントロジにも精通している必要が次元）のデータ抽出が多いが，見える化システムなどあり，大型ビルの場合はポイント数も多く負荷もかなり大は 1 時間ごとのデータ抽出が多い．こうした多様な粒

きい．そのため，我々は BIM のデータ交換用のフォーマッ

度のデータ抽出への対応が必要である．また，ビル設トである IFC（Industry Foundation Classes）から，空間

備のデータ分析に特有な処理として，積算値差分や欠階層と包含される構成要素を抽出し RDF に変換するツー損値補間がある．積算値は最大値までカウントするとルを開発することでモデリングの効率化を試みた．

0 に戻る仕様があり，それらの計算間違いが問題にな

IFC には，BIM でモデリングされる形状情報と，空間ることもある．これらの機能もプラットフォーム側の階層および設備機器や部材の属性情報の双方が記録されて機能として盛り込むこととする．

いる．開発したツールは，IfcSite（敷地），IfcBuilding（ビ

実用的なセマンティクスの導入 サードパーティの参入障ル），IfcBuildingStorey（フロア），IfcSpace（部屋）といっ壁を下げ，アプリケーションの移植性を高めるためにた空間階層を探りながら，空間が内包する IfcElement の派必要である．詳細は次節で述べる．

生クラス（設備機器など）と属性情報を抽出し，BOT とBrick を用いて RDF に変換し，同時に抽出した IfcSpace*4c 2021 Information Processing Society of Japan

https://w3c-lbd-cg.github.io/bot/

870

情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

6. futaba の設計
前章の要件をもとに futaba を設計した．図 5 にシステ
ム・アーキテクチャを示す．リアルタイム・ビッグデータ処理のためのアーキテクチャの 1 つとして知られるラム
ダ・アーキテクチャ [22] をベースとしている．

futaba では，ゲートウェイなどを介して取得するデータ（テレメトリ）をリアルタイム処理のためのホットパス，
バッチ処理のためのコールドパスに分岐し，それぞれをス
ピードレイヤ，バッチレイヤで処理し，サービスレイヤを
図 3 IFC から抽出した空間階層構造

介してデータの利活用を行う．サービスレイヤでは，WoT

Fig. 3 Space graph extracted from IFC.

に準拠した RESTful API を提供しており，リアルタイム
データの取得，メタデータの取得，制御コマンドの発行，

inst:Entrance a bot:Space ;蓄積されたデータ抽出などが可能である．オープンシステ

rdfs:label "Entrance" ;ムと PaaS を前提としており，保守性の向上と運用コスト

bot:hasElement inst_device:CO2-W-3,の低減可能な構成を目指した．なお，futaba は日本語の二

inst_device:MS-W-2,
inst_device:MS-W-3,
inst_device:TEP-C-3-RT .

葉（双葉）からとられており，特徴的なラムダ・アーキテ
クチャ，デジタルツインを想起させることを意図して命名した．以降でそれぞれの機能について述べる．

inst_device:CO2-W-3 a inst_class:CO2-W-3 ;rdfs:label "CO2-W-3" ;rdfs:comment "CO2 濃度" ;6.1 スピードレイヤ

brick:hasPoint inst_point:CO2-W-3 .

6.1.1 データ入力部（ゲートウェイ）

inst_point:CO2-W-3 a brick:Sensor ;BACS で取得できるポイントデータを，MQTT などに

rdfs:label "CO2 濃度" ;変換して Data Ingest に送信するためには，ゲートウェイ

inst:topic "takenaka.co.jp/Site_Name/EQ_House/-/Entrance（GW）によるプロトコル変換が必要である．BACS では/Utility/Sensor/WebCNT3/CO2-W-3/CO2_Level/R" .

図 4 建物メタデータの例（抜粋）Fig. 4 Example of building metadata.

BACnet 以外にも多様な通信規格が用いられるため，対応プロトコルの追加・変更と遠隔更新を容易にすることを目的として，OSGi *8 や Docker *9 を用いて開発する方針とした．

の形状出力も行う．なお，IFC から RDF への変換ツール

6.1.2 データ処理部

として IFCtoLBD *5 があるが，日本語対応などに課題があ

建物から受信したテレメトリを事前に定義したルールにるため，IfcOpenShell *6 と rdflib *7 を用いて開発した．

基づき前処理を行い，現在値の保存などのリアルタイム

図 3 にツールを使って出力した RDF の可視化例を示

データ処理を行う．データの受信は Data Ingest から行い，す．建物，フロアといった空間階層が抽出されているこ

たとえば MQTT Broker を介してテレメトリを取得する．

とが見てとれる．なお，ポイントと構成要素の突合には，

テレメトリには表 1 に示すスキーマを定めた．データは

ISO 16484-3 に定義されている BACS ポイントリストを用

values が格納されるが，多様なデータタイプに対応するたいる．ポイントリストにデバイス名などをユニークな IDめ，value のみを必須とし，ほかは自由に決められる仕様ととして付加し，ID を BIM に埋め込むことで上記ツールのした．図 6 にビーコンによる位置情報の例を示す．value

出力に含有させ，それらを突合するスクリプトによって，ポには userId が転記されており，バッチレイヤでの抽出時

イント情報を含んだ RDF（建物メタデータ）を生成する．

に，補間処理の対象データとして扱われる．data は文字列

図 4 に生成した建物メタデータの例を示す．Entranceとして抽出され，必要に応じてクライアントで処理される．

という空間が 4 つのデバイスを有しており，そのうちの 1

Message Broker からの取得したテレメトリは，Ingress

つのデバイスが CO2-W-3 というセンサのポイントを有し

Function と呼ばれるコンポーネントによって，必要な前処ていることが記述されている．

理が行われる．たとえば異常値の判定や，事前に定義されたスキーマ外のデータの除外などである．処理済みのデー

*5
*6
*7

https://github.com/jyrkioraskari/IFCtoLBD
http://ifcopenshell.org/
https://github.com/RDFLib/rdflibc 2021 Information Processing Society of Japan


*8
*9

https://www.osgi.org/
https://www.docker.com/

871

Vol.62 No.3 867–876 (Mar. 2021)

情報処理学会論文誌

図 5 futaba のアーキテクチャ

Fig. 5 System architecture of futaba.
表 1

テレメトリのスキーマ

Table 1 Schema for telemetry.
メタデータ

説明

pointID

ポイント識別子

eventTime

イベント発生時刻

topic

トピック名

values

値情報（任意型）

sequenceNumber

シーケンス番号．欠損値の検出に用いる．

{"pointID": "73AC698E-B03F-4F64-B365-8C009EF02777","eventTime": "2020-03-06T18:05:00 999+0900",

図 7

Thing Description の生成

Fig. 7 Generation of a thing description.

"topic": "takenaka.co.jp/Site/Building/Floor/Space/Location/Beacon/BLE/Area_4/Location/R","values": {6.2 バッチレイヤ
Message Broker から取得したテレメトリは Gateway"value": 31,"data": {Function によって，一時保管領域にファイルなどで格納さ"areaId": 4,"userId": 31,

れる．その後，Apache Spark を用いて 1 日 1 回〜数回の"locationTime": "2020-03-06T18:00:00+0900",

バッチ処理で HDFS に変換し，処理済みの一時ファイル"x": "-12.5068",

は削除する．Apache Spark Stream を用いる構成も可能で"y": "-22.1004","floor": "1"はあるが，サーバクラスタを起動させ続ける必要があり，クラウドでの稼働を前提とすると運用コストが増加する}},

ため，この構成とした．データ抽出のリクエスト時のパラ"sequenceNumber": 1234}

図 6 テレメトリの例

メータで抽出周期や期間を指定し，データ補完処理や異常
値検出，積算値差分なども行う．

Fig. 6 Telemetry example.

6.3 サービスレイヤ
タは，Digital Twin Repository と呼ぶサービスに保存さスピードレイヤで得られたリアルタイムのデータを公れ，この際に対象のポイントデータの ID と，5.3 節で示し開するための WoT Service と，バッチレイヤで蓄積された RDF をもとにして，サービスレイヤにおけるエンドポ

たデータを抽出するための Data Extraction Service，それイントでの参照値にマッピングする．公開されたエンドポ

らのサービスを利用するための認証を行う Authentication

イントから，ビル内設備の制御も可能であり，ポイントへ

Service から構成される．WoT Service は，5.3 節で述べの制御指示は，Egress Function によって，不正制御などをた建物メタデータと，対応するクラス・スキーマと組み合防ぐためのフィルタリングなどを施され，同様に Message

わせて URI と Thing Description（TD）を生成し，WoT

Broker を経由して，ビル設備の中に伝達される．

Service は TD をもとにエンドポイントを生成する（図 7）．
Data Extraction Service は，バッチレイヤで保存された

c 2021 Information Processing Society of Japan

872

情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

データ抽出のための非同期 API を提供している．リクエ
ストがあった時点で，サーバクラスタが起動することで，稼働時間を最小限にし，コスト最小化を実現する．

Authentication Service は，上記の 2 つのサービスを利用するため，OAuth などによる利用者認証 API を提供する．

7. 実装と評価
設計要件に基づいて，futaba の実装を行った（図 8）．

図 8 futaba 参考実装

Fig. 8 Reference implementation of futaba.

7.1 スピードレイヤ
図 9 に開発した BACnet ゲートウェイを示す．Read-

Property や WriteProperty といった BACnet サービスを使って，収集対象のポイントの値を定期的に収集，書き込みを行っており，それらを MQTT に変換して MQTT Brokerに発出している．OSGi で動くバンドルとして設計・実装されているため，1 つのゲートウェイにモジュール化された複数の機能を実装することができる．
スピードレイヤの実装は先行研究 [20] の基盤を利用す
図 9

る．ECL2.0 *10 上に構築されており，VerneMQ *11 で 5 棟

OSGi による BACnet ゲートウェイの実装

Fig. 9 Implementation of BACnet gateway with OSGi.

のデータが集約され，1 分あたり平均 16,773 件のデータを処理している．データは原則として VPN を介して収集しているが，一部の IoT 機器などは，インターネットを経由する構成があるため，認証・暗号化を行う外部連携用の Broker を経由して連携させている．Ingress / Egress

Function は簡易的に NodeRED *12 で実装しており，エンドポイントに公開するために必要な名前空間の変換などを行う．建物メタデータは静的な運用を想定し，事前に生成したものをサーバ上に保存している．
図 10 バッチレイヤでのデータ保存

Fig. 10 Store data in batch layer (after optimization).

7.2 バッチレイヤ
バッチレイヤは，安価で保守性の高い運用のため Mi-

crosoft Azure の PaaS を用いて構築した．Scala で実装したゲートウェイを介して Azure Event Hubs にデータを送り，PaaS の機能で 15 分ごとにキャプチャデータをファイル保存しており，それらを Azure Databricks を用いて，

1 日ごとのバッチ処理で Delta Lake に変換して保存する（図 10）．Azure Databricks は Apache Spark の分散実行基盤であり，バッチジョブを実行する際に，必要な計算資

で 2,400 円程度かかっているが，機能最適化検討の結果，Standard L4s（32 GB メモリ，4 コア，29 ノード）での処理で 13 秒程度となり，月額 877 円程度に抑えられることが分かった．Dalta Lake フォーマットによる圧縮効率も高く，たとえば 5 万件/分のデータを想定した場合においても，250 MByte 程度となる．Azure Data Lake Storage

Gen2 では，1 TB を保存しても 8,000 円程度といえ，十分なコスト効率であるといえる．

源を用意し，使用が終了すると解放するため，大量の計算資源を使用しながら，課金額を最小限に抑えることが可能となる．

7.3 サービスレイヤ
サービスレイヤでは，WoT Service 用のサーバを Mozilla

現状の実装では，サードパーティの要望に応じて，抽出の参考実装*13 を参考に，Play Framework *14 で実装した用のスクリプトをスケジューラに登録し，抽出したデー（図 11）．起動時に建物メタデータを解析し，そこからタを API を介して取得する実装となっている．データの永続化のための毎日のバッチ処理時間が 35 分，月額費用*10

https://ecl.ntt.com/news/service/ecl2/
https://vernemq.com/*12 https://nodered.org/*11

c 2021 Information Processing Society of Japan

Thing を生成し，ThingsContiner に保持する構成になっている．Thing からメソッドを介して TD が生成できるようになっており，サードパーティは TD とクラス・スキーマ*13*14

https://iot.mozilla.org/framework/https://www.playframework.com/873

情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

柔軟なテレメトリ・スキーマを導入したことで，スカラー値以外にも対応した．近年は位置情報以外にも画像処理によって得られる特徴量ベクトルなども IoT のデータとして扱うことがあり，そのようなユースケースにも対応可能である．
再利用性の高いアプリケーション BOT や Brick による
簡易なデータモデルを提案・採用し，BIM やポイント
図 11 WoT Service の参考実装

リストから生成した RDF をもとに，WoT のエンドポ

Fig. 11 Reference implementation of WoT service.

イントを生成している．メタデータとクラス・スキー
マを公開することで，データの構造や意味についての理解が容易になり，BACS の専門業者以外の新規参入が容易となったといえる．
また，WoT による RESTful な疎結合型のアーキテク
チャを採用し，ユースケースに適合した API を提供したことで，制御やモニタリングといったアプリケー
ション機能のモジュール化が容易になり，再利用性が高まったといえる．
建設プロジェクトへ適用可能 オープンシステムと PaaSを前提したことで，7.2 節に示したように，十分に安価な運用が可能であることを検証した．
保守性向上のため，BACS と futaba のデータ連携はゲートウェイを介して行う構成とし，遠隔制御の際に図 12 Thing Description 例（ブラウザからアクセス時）

はルールエンジンである Ingress/Egress Function や

Fig. 12 Thing description (Accessing from a browser).

認証機構によって不正制御防止がなされる構成として
いる．インターネット接続やプラットフォーム側に不を参照しながら，RESTful API のエンドポイントにアク具合があった際も，現地の BACS が問題なく動作する

セスする．図 12 は，エンドポイントに対してブラウザでような機能配置としており，責任範囲の明確化を実現

アクセスした際に得られる TD の例である．properties 以している．そのため，実際の建設プロジェクトにおい下に，デバイスが保持するポイントの情報が書かれていても十分に適用可能な構成といえる．

る．この例では，links をたどって当該プロパティのエンド
ポイントを特定した後，HTTP の GET でデータの取得，

8. アプリケーション

PUT でデータ書き込み，POST でデータ購読用のエンド

本章では，futaba の参考実装を利用して開発したシステ

ポイントを生成が可能である．なお，参考実装においては，

ムについて述べ，ユースケースの適合性について評価する．

Authentication Service の実装は行っていない．

対象ビルの EQ House は延床面積 88 m2 の展示施設・住居で，電気自動車が普及した際の新しい住居の在り方を提7.4 評価案するコンセプトハウスであり，多くのセンサを備えてい本節では，4 章で述べた設計指針に対する評価を述べる．

る（図 13，表 2）．小規模の建物であるが，全ポイント数

多様なユースケース対応する高い汎用性 futaba は ラ ム

は 1,304，空調関連だけで 854 あり，一般的な中小ビルとダ・アーキテクチャを採用しているため，リアルタ

同等以上のポイントを有し，家よりもビルに近い設備構成

イムおよびバッチ処理が必要なユースケースに適合すとなっている．空調関連のポイントに関連するデバイス

る．リアルタイム処理については，ポーリングだけでは 96，それらに対応するクラスは 20 である．図 14 にそなく，イベント購読用のエンドポイントの提供により，れらを構造化して，可視化した RDF を示す．Building がイベント駆動型のアプリケーションにも対応する．そSpace を持ち，Space には Device が配置され，Device がのため，5.1 節で述べたシステム以外にも，たとえばPoint を持つことが見てとれる．これらのデータは現地の即時的な制御が必要なパーソナルファン制御 [16] にもゲートウェイを経由して MQTT でクラウド環境に発出さ適用が可能である．バッチ処理についても，任意の時

れ，また外部からの制御を受け入れることもできる．

間間隔でデータ抽出ができるために，負荷予測やデー

EQ House では，5.1.2 項で述べた強化学習による省エネ

タ分析 [23] といったユースケースにもよく適合する．

と快適性を指標とした設備制御を試行している．提示したc 2021 Information Processing Society of Japan

874

情報処理学会論文誌

Vol.62 No.3 867–876 (Mar. 2021)

図 15 Archiphilia Engine による PMV の最適化

Fig. 15 Optimizing PMV with Archiphilia Engine.
図 13 EQ House 外観（井上登写真事務所）

Fig. 13 Exterior of EQ House.

前段階の教師あり学習モデルによる制御試行のデータである．制御ポイントの大部分を占める照明制御などは，温熱

表 2 EQ House の計測ポイント

Table 2 EQ House measurement points.

環境に無関係といえるため制御対象外とし，空調関連の 18
ポイントに限定している．ここでの PMV の計算は室温，

気象ステーション

風向・風速・雨量・気圧・日射量

湿度などが支配的であり，これらを制御対象とする空調シ

多機能人感センサ

在/不在・人数・表面温度・照度

ステムの時定数は 15〜30 分である [24]．図中の PMV の

表面温度計

パネル表面温度

反応はそれより遅いといえるが，通常冷房では 1 時間程度

CO2 センサCO2 濃度予冷運転をかけるため，実用上は問題ないといえる．

スマートウォッチ

加速度センサ・心拍・評価など

電力量計

電力量

マグネットセンサ

扉の開閉状況

輝度カメラ

輝度・明るさ感

EQ House ではほかにも，主として演出を目的として，音カメラ

画像解析による人・行動検知

声入力による指示やカメラによる人物・姿勢検出をトリガ

音声認識用マイク

音声認識による会話・語彙抽出とした環境制御を実装している．これらの制御データも，

PV・蓄電池関連

充電量，放電量など

他の設備情報と同様に MQTT を介してプラットフォーム

空調機関連

風量，送風温度，熱源の効率など

本節で述べたシステムは 2019 年 3 月から継続的に運用され，学習および制御アルゴリズムの改善を続けている．

に送信・保存され，モニタリング可能であるとともに，クラウドからの制御モード変更などのアプリケーションも運用している．十分な汎用性を持つといえるだろう．

9. まとめ本研究では，スマートビル専用のプラットフォームである futaba を提案した．ラムダアーキテクチャと WoT の仕様に基づく RESTful API を用いることで，多様なユース
ケースに対応した高い汎用性を得た．また，スマートビルに有用なセマンティクスの提案を行い，それらをデータモ
デルに組み入れることで，BACS の専門業者以外の新規参入障壁を下げ，アプリケーションの再利用性を向上させた．
図 14 EQ House におけるセマンティクス（抜粋）

加えて，PaaS による機能最適化により，たとえば毎分 5

Fig. 14 Semantics of EQ House (excerpt).

万件のデータを想定した場合でも，バッチレイヤ部が月額要件をもとに開発した AI は 696 の計測ポイントをバッチ

実物件において参考実装を適用し，その汎用性を検証した．

処理によって定期的に抽出し，予測用 AI の学習に利用し本論文では参考実装を示したが，2019 年度の国立研究開ている．同様にリアルタイムのデータも取得しながら，179

発法人新エネルギー・産業技術総合開発機構（NEDO）のの制御ポイントを対象とした強化学習による制御を行う．

助成事業において，futaba の実用化・事業化を目指し再実

1 万円以下で運用可能であることを確認した．さらには，

図 15 は，温熱快適性の評価指数である PMV（Predicted

Mean Vote）を，試験的に環境悪化させた状態から，簡易的な AI 制御によって快適範囲である ±0.5 の範囲まで回復装を進めている．これらの成果により，高度なスマートビ
ルの普及と，多様な業種の新規参入による新たな市場の誕
生と拡大を期待している．

させている様子を示している．なお，これらは強化学習のc 2021 Information Processing Society of Japan


875

情報処理学会論文誌

謝辞

Vol.62 No.3 867–876 (Mar. 2021)

本研究における調査などに多大な協力をいただいた東大グリーン ICT プロジェクト BIM 基盤 WG のメンバ

[17]に深甚の謝意を表します．また，この成果の一部は NEDOの助成事業の結果得られたものです．
[18]

参考文献
[1]
[2]

[3]

[4]

[5]
[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

[15]

[16]

豊田武二：ISO16484-1 BACS プロジェクトの概要，電気設備学会誌，Vol.33, No.2, pp.92–95 (2013).
Dawson-Haggerty, S., Jiang, X., Tolle, G., et al.: SMAP
– A Simple Measurement and Actuation Profile for physical information, pp.197–210 (01 2010).
Dawson-Haggerty, S., Krioukov, A., Taneja, J., et al.:
BOSS: Building operating system services, Presented
as part of the 10th USENIX Symposium on Networked Systems Design and Implementation (NSDI
13 ), pp.443–457, Lombard, IL (2013).
Krioukov, A., Fierro, G., Kitaev, N. and Culler, D.E.:
Building Application Stack (BAS), Proc. 4th ACM
Workshop on Embedded Sensing Systems for EnergyEﬃciency in Buildings, BuildSys ’12, pp.72–79 (2012).
Fierro, G. and Culler, D.E.: XBOS: An Extensible Building Operating System, Technical Report (2015).
Balaji, B., Bhattacharya, A., Fierro, G., et al.: Brick:Towards a Unified Metadata Schema For Buildings,
Proc. 3rd ACM International Conference on Systems
for Energy-Eﬃcient Built Environments, BuildSys ’16,
pp.41–50 (2016).
Fierro, G., Pritoni, M., Abdelbaky, M., et al.: Mortar:
An open testbed for portable building analytics, ACM
Trans. Sensor Networks, Vol.16, No.1 (2019).
Andersen, M.P. and Culler, D.E.: BTrDB: Optimizing
storage system design for timeseries processing, Proc.
14th USENIX Conference on File and Storage Technologies (FAST 2016 ) (2016).
Fierro, G. and Culler, D.E.: Design and Analysis of aQuery Processor for Brick, ACM Trans. Sensor Networks, Vol.14, No.3-4, pp.1–25 (2018).
Ochiai, H., Ishiyama, M., Momose, T., et al.: FIAP:
Facility information access protocol for data-centricbuilding automation systems, 2011 IEEE Conference
on Computer Communications Workshops (INFOCOM
WKSHPS ), pp.229–234 (2011).
Khamphanchai, W., Saha, A., Rathinavel, K., et al.:Conceptual architecture of building energy management
open source software (BEMOSS), pp.1–6 (2014).
Vicari, N., Kurt, G., Yalcin, B.O., et al.: Building as aService – BaaS Deliverable D05 – BaaS Reference Architecture, pp.1–144 (2016).
Lilis, G. and Kayal, M.: A secure and distributed message oriented middleware for smart building applications, Automation in Construction, Vol.86, No.June
2017, pp.163–175 (2018).
Jara, A.J., Olivieri, A.C., Bocchi, Y., et al.: Semantic
Web of Things: An Analysis of the Application Semantics for the IoT Moving towards the IoT Convergence,
Int. J. Web Grid Serv., Vol.10, No.2/3, p.244–272 (Apr.
2014).
Bovet, G. and Hennebert, J.: Distributed semantic discovery for web-of-things enabled smart buildings, 2014
6th International Conference on New Technologies,
Mobility and Security – Proc. NTMS 2014 Conference
and Workshops (2014).
粕谷貴司，田中規敏：IoT を活用した建物制御システム，c 2021 Information Processing Society of Japan


[19]

[20]

[21]

[22]

[23]

[24]

電気設備学会誌，Vol.38, No.8, pp.466–469 (2018).
粕谷貴司：最新の IoT/AI を活用したスマートビルの実施
例：EQ House における AI による無人制御への挑戦（特集 AI・IoT を活用した建築・設備における新たな価値の創出），BE 建築設備，Vol.70, No.12, pp.24–30 (2019).
Han, M., Zhang, X., Xu, L., et al.: A review of reinforcement learning methodologies on control systems forbuilding energy (2018).
粕谷貴司，岡野健二，茂手木直也，畠山英之，矢内雅浩，
小松孝司，大野翔平：ビッグデータリアルタイム解析による建物管理システム，空気調和・衛生工学，Vol.89, No.12,
pp.65–70 (2015).
粕谷貴司，近藤正芳，茂手木直也，松岡康友，矢野 雅，
秋山貴紀，境野 哲，貞田洋明，堀越 崇，畠山英之：ス
マートシティのための MQTT プラットフォームの検証，
情報科学技術フォーラム講演論文集 (2014).
Bhattacharya, A.A., Ploennigs, J. and Culler, D.E.:
Short Paper:
Analyzing Metadata Schemas for
Buildings:
The Good, the Bad, and the Ugly,
BuildSys@SenSys (2015).
Marz, N. and Warren, J.: Big Data: Principles andbest practices of scalable realtime data systems, Manning Publications (2015).
Kasuya, T., Takai, T. and Esaki, H.: Building Activity Profiling: Explainable and Predictive Modeling for
Building Automation, 2020 International Conferenceon Artiﬁcial Intelligence in Information and Communication (ICAIIC ), pp.242–247 (2020).
中村政治：IT 時代の計測・制御技術の動向 (5) IT 時代の空調制御理論と制御系設計ツール，空気調和・衛生工学，
Vol.80, pp.533–542 (2006).

粕谷 貴司 （正会員）
2007 年慶應義塾大学大学院政策・メディア研究科修士課程修了．2008 年（株）竹中工務店入社．2013 年より同社情報エンジニアリング本部．ビル設
備に対する情報エンジニアリング業務
や研究に従事．2017 年より東京大学
大学院情報理工学系研究科に社会人博士として所属．2020
年博士課程修了．博士（情報理工学）．

江崎 浩 （正会員）
1987 年九州大学大学院工学研究科電子工学専攻修士課程修了．同年（株）
東芝入社．1990 年米国ニュージャー
ジ州ベルコア社．1994 年コロンビア大学・客員研究員．1998 年東京大学
大型計算機センター助教授．2001 年
同大学大学院情報理工学系研究科助教授．2015 年同大学
院同研究科教授，現在に至る．博士（工学，東京大学）．

MPLS-JAPAN 代表，IPv6 普及・高度化推進協議会専務理事，WIDE プロジェクト代表，JPNIC 副理事長．

876