第11部

特集11 SoftwareDefinedMediaコンソーシアム

第11部
特集11 SoftwareDefinedMediaコンソーシアム
SDM WGメンバー

第１章

第２章

はじめに

ビル管理におけるBIMに基づくデジタルツイン
基盤の研究

Software Defined Media（SDM）コンソーシアムは、2014
年に設立され、オブジェクト指向のディジタルメディア

スマートビルディングとは空間とIoTを融合させることと、インターネット環境が前提の映像・音響空間を用いで、建物内の設備を一元管理し、エネルギー効率の最適たビジネス創造を目指してきた。昨年までの報告書で化や快適性の向上などを目指すことである。我々はビは、SDMのコンセプトやアーキテクチャ、試作プラッ

ルを対象にBIMやIoTを駆使したスマートビルディング

トフォーム[129、130]、データ収録[130]、収録データの実証実験を行い、この実証実験では、事前に用意したベース設計[132、133、134]、SDMプラットホームを利BIMデータと静的センサなどによる各種データをもとに2用したアプリケーションであるSDM360 [135、136]や
2

LiVRation[137、138]、Web360 [139]などを報告してきた。

運搬ロボットの移動経路を動的に算出し、目的地への指令を出すなどの課題を解決することを試みた。課題として、人や什器などがオフィス内で常に変化しているため、

本報告書では、2021年度に実施した活動を報告する。

事前に用意したマッピングデータのみでは、ロボットは新しく設置された障害物や人にぶつかってしまい、目的
地にたどり着けないことが上げられる。これは配置が決まっていることが多い工場などと違い、インテリアのために什器が頻繁に置き換えることもあるオフィスなら

図1

行動計画システム概要図79

ではの問題である。また、ロボットは、ロボット本体がイズを含んだ自己位置推定ができており、その位置情報

SLAMを搭載している場合などには、移動しながら自身を活用できるものとする。この位置情報を中間処理層のに搭載されたセンサを元に自分の中にローカルマップを

二つ目の入力として使用する。最後にEuclid Clustering

生成するため、解決可能だが、データとしてはロボットと後述するロボットの推定方法により推定されたロボッからの情報に限られてしまい、実際には最短経路でない

トの位置情報と、最初の点群の集合体からロボットと経路を選択してしまうことも考えられる。

思われる点群クラスタを引いた障害物と思われる点群とを組み合わせ、ツイン上でロボットの移動経路を算

そこで、本研究では、物理空間に事前に設置した複数の出 す る。な お、こ の 際、BIMデ ー タ の 属 性 情 報 で あ る

LiDARセンサの協調知覚により、本課題を解決すること

IfcSpatialZoneを使用し、ロボットの行動可能領域を事前を目指した。これは、環境側にセンサを搭載することで、に定めることが出来るといった機能も用い、BIMデータ

自律移動型ロボットの再マッピングの手間を省き、更にを活用する。

LiDARセンサを用いることで、高精度な測定を目指す。また、運搬ロボットは前面にしかLiDARセンサがついてい

なお、ビルをテーマにした上記デジタルツインアプリ

ないことが多く、他方面からの追突は予期していない場

ケーションは、東京大学グリーンICTプロジェクトBIM

合があるため、環境側から認知することで、警告音を鳴

基盤WG＊2にて、研究を行った。我々は、主にデジタルツ

らすといった対処が行えるといった利点が考えられる。

インアプリケーションの作成に従事し、利用したジオメ
トリデータはエヌ・ティ・ティ・コミュニケーションズ株

2.1

提案手法

式会社＊3のスマートラボ、BIMデータの構築やバックエ

図1にロボットの行動計画を行うシステムの概要図を、ンドの作成、ロボットの調達などは本ワーキンググルー

図2に本研究のデジタルツインの構成図を記載した。本プに参加している各企業が行った。また、後の2.2.1項に

研究では、提案手法として、対象のエリアに複数のセンて作成したAPIサーバは研究グループの一人と協力して

サを設置し、それぞれのセンサのマッピング情報を集積作成した。

してエリア全体のマッピングを行い、統括管理を行う方法を提唱する。これにより、ロボット単体でのマッピン

2.2

グと比べ、不明瞭な空間を排斥し、正しい最短経路を導本アプリケーションは東大グリーンICTプロジェクトのきやすくなると考えられる。また、その際、LiDARセン

BIM基盤WGの一つの実証実験としてNTTコミュニケー

サはある程度上方に設置することで障害物による対象物

ションズ田町ラボでの実験をベースとした開発を行って設計と実装の遮蔽の影響を緩和する。
図1に お い て、本 手 法 を 説 明 す る。ま ず 左 のLiDAR
Simulatorにて、複数のLiDARセンサをシミュレートし、複数の点群データの集合体を得る。次にその点群データ
中間処理層にてクラスタリングする。ここで得られたクラスタの中からロボットと思われる物を判別し、その位
置情報を中間処理層の一つの入力として扱う。右側のTwin Simulatorでは、現実世界のロボットのツインとなるオブジェクトを配置する。今回、実証実験にて使用したロボット（FRUTERA A-ROBOT-102）＊1はある程度のノ

80＊1

http://androbo.jp/business/r/frutera/＊2

https://www.gutp.jp/activity/?id=204＊3

https://www.ntt.com/index.html

図2

デジタルツインアプリケーションのスクリーンショット

いる。そのため、デジタルツインアプリケーションとし

2.2.2

中間処理層

てロボットの制御以外にも照明、空調の制御、ビーコン

シミュレータはLiDARの挙動をシミュレートし、取得しの情報取得など様々な機構が作成されているが、本実験た点群データはROSトピック/velodyne_pointsにPublishと関係性が薄い部分の説明は省略、又は省いている。シ

さ れ る。本 項 で は、LiDARセ ン サ か ら 受 け 取 っ た 点 群

ミュレーターを用いた本実験は、この様々なセンサの可データを処理するためのROSパッケージを作成するため視化及び制御機構を有したデジタルツインアプリケーに用いた手法を説明する。中間処理層では、ROS（Robot

ション上で行う。

＊5
Operating System）と点群データを処理するために用いたライブラリとしてオープンソースにて開発されている
2.2.1 アプリケーション実装＊6
PCL（Point Cloud Library）
を用いた。

今回、NTTコミュニケーションズ内での実証実験を行う
際に、ロボット制御を行うAPIへのアクセスは、特定IP

ここでは、図4のようにセンサを環境に設置し、そこにからのアクセスしか受容しないホワイトリスト制であっロボットを配置した際に、中間処理層にて行う各処理をた。そのため、この実証実験に向け、我々はゲームエン実行した結果を記載していく。なお、センサの位置は固ジンが行う全ての対外通信を総括するAPIサーバをAzure

定し、点群の組み合わせを実行する際に、正しく組み合を用いて新しく作成した。具体的なアプリケーション構

わせを行えるように全てのセンサの位置情報は事前に分成を図3に示した。このサーバはゲームエンジンからはかっているものとする。

REST APIとして振る舞い、内部ではロボット制御のAPIに対してMQTTを用いて通信を行い、空調、照明状態の確■点群の組み合わせ処理認を行うAPIに対してはRESTを用いて通信を行う。また、

各LiDARセ ン サ はROSト ピ ッ ク/velodyne_pointsに 点 群

本アプリケーションはゲームエンジンであるUnity3Dを用いて作成した。

＊4

データをアップロードするが、LiDARセンサごとに情報を分離するために、ヘッダー情報に含まれるframe_idを
velodyne_x（xはナンバリング）
ように変更する。

図3＊4

https://unity.com/＊5https://www.ros.org/＊6

https://pointclouds.org/

アプリケーション構成

81

次に各センサの座標を元に、それぞれの点群に対し、座ルサイズを5[cm]に設定し、実行したところ、約228,000

標変換を行う。最後に一つの点群データとして組み合わ

点数の点群が約18,000点数まで削減された。

せを行う。図5は、以上の操作を行った際の点群データの可視化である。

■床面の点群の削除与えられた点群の中から一定以上の大きさの平面を検出■点群の軽量化す る 手 法 と し て、Plane Model Segmentation[140]と い点群の組み合わせ処理を行った点群データは一つのセンう手法が存在する。この手法では、入力モデル（ここではサが取得する点数とセンサの数の掛け合わせを行った点平面）と距離の閾値を指定し、RANSAC[141]を用いて、数であるため、点群数の削減を行うことで処理の高速化

入力点群の中から入力モデルと近しい平面を抽出する。

を図る。
しかし、今回はロボットは段差など高低が発生する物体
ここでは、Voxel Grid Downsamplingを行う。これは、入を登らず、移動する位置座標の高さは常に一定であるた

力した点群データに対し、空間上に三次元の立方体（ボクめ、床を含む一定以下の高さの点群を削除するといったセル）を配置し、各ボクセルに含まれる点群をそれらの処理を行っている。図6は点群の軽量化を行った入力点群

重心で近似するといった処理である。これにより、入力

に対し、この処理を行った結果を可視化したものである。

点群の特徴を抑えたままダウンサンプリングを行っている。組み合わせ処理を行った点群データに対し、ボクセ■点群のクラスタリング
ここでは、点群の特徴を踏まえ、クラスタリングを行い、点群を各物体に分離する。ここではEuclid Clustering
Extraction[142]を 用 い る。Euclid Clustering Extractionとは、オクツリーデータ構造を用い、各三次元ボックス
内のデータをkd-tree構造を用いて最近傍探索を行い、各クラスタを抽出する。
図7は、床 面 の 点 群 の 削 除 し た 後 の 点 群 にEuclid
Clusteringを実行し、各クラスタごとに色を割り当てた際の様子である。図の真ん中には、対象のロボットが茶色

82

図4

シミュレータ上のロボット、センサの配置

図5

VLP-16シミュレータによって得られた点群

図6

床面の点群の削除を実行後に得られた点群

のバウンディングボックスと共に黒く塗りつぶされていうことができる。本研究では、VLP-16（及びそのシミュ

る（赤色の四角で囲まれている物体）。

レータ）から取得し、中間処理を施した点群情報をそのままジオメトリ上に反映させ、障害物としてNavigation■ロボットの座標の推定

Systemに認識させている。

ここでは、抽出した各クラスタからどのクラスタがロボットであるかを特定する。ここでは、前提条件として、

2.2.4

運搬ロボットについて

ロボットの位置情報が利用できるため、経路探索を行う

本実証実験で用いた運搬ロボットはアンドロボティクス

際のロボットの初期座標を用いる。初期座標近辺に存在株式会社のFRUTERA A-ROBOT-102である。
以降、
後の2.3

し、ロボットの特徴（今回は大きさを使用した）と合致す節にて行うシミュレーションでは本ロボットの特徴を踏るクラスタを抽出し、そのクラスタがロボットであるとまえ、独自に条件を設定した仮想ロボットを用いる。

想定する。
2.3

実験

以上の操作から推定したロボットの位置はROSトピッ

今回使用する仮想ロボットのベースとなるA-ROBOT-102

ク/processed_poseと し て、PoseStamped型 でPublishしはロボットは自身の先端下部に装着しているLiDARセンている。また、障害物情報は推定したロボットの点群を

サを用いて、事前にマッピングを行う（SLAMを行ってい削除したうえで、ROSトピック/processed_pc2として、ると思われる）。

PointCloud2型でPublishしている。
そしてそのマッピングしたエリアの中からいくつかのな お、こ こ ま で の 処 理 に か か る 実 行 時 間 は、平 均 約

目的地とホームポジションを指定する。移動の際にはそ

192.43[ms]となった。

れらの目的地を指定し、ロボットがそこまでの最短経路を内部で求め、移動を開始する。その際に、障害物（人な

2.2.3

経路探索

ど）に接近した場合、正面のLiDARセンサが物体を捉え

経路探索には、Unity3Dの機能の一つであるNavigation

ることで、障害物に接近したと判断し、一時動作を停止

System＊7を用いる。この機能では、仮想空間上のジオメ

する。また、本ロボットはオドメトリを利用した自己位

トリデータを元に、移動可能領域をNavMeshとして算出

置推定を行っていると思われ、車輪が空転した場合などし、その領域内でA*アルゴリズムを用い、経路探索を行を除き、少量のノイズを含みつつ現在地をユーザに伝達可能である。
以上をまとめ、仮想ロボットの条件として、以下の項目を設定した。
● 一定のノイズを含む自己位置（平面位置、角度）をアプ
リケーションに伝達可能● 障害物に対して距離0.5[m]以内には接近不可
2● 最大速度を1.2[m/s]、加速度を0.3[m/s ]と仮定
● 座標を指定し、その場所に直線的に移動することが出
来ると仮定

図7
＊7

Euclid Clustering Extraction実行後

上記の条件の内、最大速度については、実証実験で用いhttps://docs.unity3d.com/2022.1/Documentation/Manual/Navigation.html

83

ている運搬ロボットの仕様として記載されていたものをタートしてからゴールするまで行い、毎フレーム（今回の使用した。実証実験で用いている運搬ロボットの移動機

実験では60fps）情報を取得するものとする。ここで、図8

能は、事前に設定した座標に向かい移動するものであり、に表示されている仮想空間上にて、左方向がX軸正、下方

上記条件に設定したような自在に座標を指定する柔軟性

向がZ軸正である。

はない。しかし現在、数多くのロボットは方向と移動量
や移動時間を指定し、移動するといった操作が可能であ

なお、ここで各軸毎の平均誤差zはロボットの座標の真のる。そのため、本実験では、仮想ロボットは自由に移動で値をxk（ここで、kはシミュレーション開始時から終了時きるという仮定の下シミュレーションを実施する。ただまでに取得したデータ（n個）を順番に並べた際の添え字）

し、実証実験で用いている運搬ロボットと同様に座標指とし、予測されたロボットの座標をyとすると定を行い、そこに対し直線的に移動するものとする。
シミュレータからロボットや障害物を正しく認知し、ロボットの行動計画を行えるかをテストするため、以下の実験を行った。図8には本実験にて仮想ロボットが移動を開始する移動開始地点と目的地を示している。移動開始
地点は図8上にて、緑色の立方体で表されており、目的地
は赤色の立方体で表されている。
複数のLiDARは中間処理層にLiDARが取得した全ての点群を送信し、中間処理層にてロボットや周辺の障害物などを分離、認知する。それをデジタルツインアプリケー
ションに送信し、デジタルツインアプリケーションがロ

図8

シミュレータ上でのスタート（緑）とゴール（赤）と障害物の配置

ボットの行動計画を行い、経路をロボットに伝送する。
その時の様子を図9に示した。この図ではロボットのツインが与えられた情報を元に赤い経路を生成している様子が示されている。この図でロボットのモデルは推定された位置情報に位置するように配置されている。また、この図にて黒い点の集合体が障害物として認知された点群であり、床に生成された青いエリアはロボットが移動可能（障害物から0.5m]離れている場所）なエリアである。
図10には、デジタルツインアプリケーションによって生成された行動計画を遂行したシミュレータ上でのロボッ

図9生成された行動計画

図10

生成された行動計画

トが映っている。図の右上には本ロボットがデジタルツ
インアプリケーションから送信された移動命令（座標情報）が表示されている。
2.4

評価

シミュレータ上の実際の仮想ロボットの位置と中間処理を終え、提案手法により予測された仮想ロボットの位置の誤差平均を計測する。ここで計測は仮想ロボットがス

84

の実行時間を測定し、その時間だけ予測値の遷移をずらし、それらと真値の差分を計測した。表3に、新たに取得したデータを示した。
としてあらわされ、標準偏差は上記平均誤差zの標準偏差を取得するものとする。

これを参照すると表2と比較し、かなり誤差が減っている
ことがわかる。全体誤差を参照すると約85[mm]のずれが最後にX軸、Z軸双方を考慮した誤差はX軸とZ軸の差分

存在し、全体の標準偏差を参照すると93[mm]ほどの値がのユークリッド距離を利用する。

確認できるが、これは流動体などの接近時にある程度のマージンを保持し、接近時には停止する設定を持つ運搬

表1に本実験を実施した実行環境を、表2に計測されたロボットにおいて、500[mm]ほどのマージンを担保する

データを示した。表2を見ると、全体的に200[mm]ほどことが多いため、それと比較すると少ないものではないのずれが生じており、誤差が大きいと考えられる。ロかと思われる。

ボットの横幅は約460[mm]であるため、ロボットの半分ほどのずれが生じている。また、X軸方向の標準偏差はこの結果から、本手法では高精度のLiDARを活用し、運搬

527[mm]、全体の標準偏差は273.43[mm]とかなり大きロボットの動的な行動計画に対応することができる可能い。これは、今回の走行経路において、障害物がセンサ性を示した。しかし、上記結果の通り、この手法を現実的からロボットを遮蔽している場所を考慮すると、ロボッな物とするには、特に大きい影響を誇る実行時間の削減

トを追跡できるセンサが限られているからであると思わを目指さなければいけないということがわかった。

れる。
この結果を踏まえると、今回の手法を用いたプログラムの実行速度が遅く、その影響がこの結果に表されている

第３章

生産管理のためのデジタルツインアプリケー
ションと考えられる。
デジタルツインのユースケースの一つとして、工場でのそのため、新たにシミュレーション中に各フレームごと

表1

表2

平均誤差

使用が考えられる。工場では工作機械や人の流れ、作業

検証システムの構成

表3

平均誤差（時間調整後）85

効率など様々な要素が可視化され、管理されることが望れたセンサによって取得された温度情報や騒音情報などまれるが、現在、様々な企業がスマートファクトリを推進の環境状態の投影を行うことでリアルタイムに工場の状しているように、実際にデジタルツインを構築し、活用し況を直感的に認識できるようにしている。ここで、静的ている工場はまだ多くなく、普及段階である。ここで、スなジオメトリデータは、ジオメトリデータ上の工作機械

マートファクトリーのためのデジタルツインを考えた際、の位置などのメタ情報を付加することで、BIMのサブセッ

工場の効率化のために何を重点的に可視化、フィードバッ

トとして利用する。また本研究では工場の効率化のためクするかによって効率であるか否かが変わってくる。

に、電力状況について着目した。工場内の工作機械の電力消費量、稼働状況、パトランプに関する情報などを集

我々は、上記の課題に対して、電力消費量の管理や物理

積し、可視化するシステムを提案する。工作機械から蓄空間の工場の稼働状況の可視化という観点から、生産管積したデータは、電力消費量を棒グラフを、稼働状況を理のためのデジタルツインアプリケーション（図12）、及ガントチャートを作成することで、過去のデータから工び工場に設置された工作機械やIoTデバイスなどの情報

作機械の利用状況を可視化する。過去のデータについてを集積しアプリケーションに提供するためのAPIを作成

は、年、月、日といった時間に関する基準やエリアやグした[143]。

ループなどと言った工作機械の所属するドメインによってまとめられており、データはこれらの項目によってカ

本章では、本デジタルツインアプリケーションの概要、評スタマイズされたものを表示する。そして、利用者の作価として実施した利用評価アンケートについて、報告する。

業効率への影響という観点から、工場に設置した工作機
械やIoTデバイスの情報を反映する速度を速めることで、

3.1

工場内の情報共有や緊急性の高い事象を逃さないように提案手法

本システムでは、3Dビューワを搭載し、静的なジオメト

リアルタイム性を高めることを目指した。

リデータ上に工作機械の電力消費量から推定した稼働状
況やパトランプによる異常状態、IoTデバイスに搭載さ

図11

86

今回実装したアプリケーションの構成を図11にアプリ

アプリケーション構成

ケーションのスクリーンショットを図12に示した。本実● 工作機械のパトランプ

装では、バックエンドとフロントエンドに分けている。

● 推定された工作機械の状態

バックエンドは、ジオメトリデータを格納し、IoTゲート● 工作機械の消費電力

ウェイから取得した工作機械やIoTデバイスからの情報● 顧客情報をリアルタイムに取得、集積、カスタマイズを行うクラウドサーバである。フロントエンドでは、ゲームエンジ

また、IoTデバイスや工作機械ではNTPとの時刻同期機

ンであるUnity3Dを用いて、ジオメトリデータを用いた能を利用しており、データを取得するタイミングにて正サイバー空間内でのシミュレーションや3Dでの可視化、確なタイムスタンプを保存しており、アプリケーション

各種グラフの表示を行う。

側にてデータを利用する際にはこれらも利用可能である。なお、基本的にデータ改変を行うことでCPUリソー

なお、工場をテーマにした上記デジタルツインアプリ

スを使わないために、集積されたデータのカスタマイズ＊8については後述するクラウドサーバ上で行っている。図との共同研究という形で研究を行った。具体的には、ジ12では、3Dビューワにて工作機械の稼働状況、電力消

オメトリデータを作成する工場の選定、バックエンドの費量などを閲覧している。工作機械の稼働状況は、対応

作成、アプリケーションデザインや一部機能の実装補助

した色を割り当てており、利用者が一目で工場全体の工などを株式会社シムックスイニシアティブが行った。

作機械の稼働状況を把握できるようにしている。また、ケーションでは、株式会社シムックスイニシアティブ

パトランプに関する情報も取得しており、図12の画面上設計と実装部にあるタブを稼働から警告に変更することで、工場内

3.2.1 アプリケーション

全ての工作機械のパトランプの情報を取得し、画面に反本アプリケーションの構築にはゲームエンジンである映する。また、図12に表示されているように、工作機械

Unity3Dを利用した。利用するデータは全て、後述するクにマウスカーソルを合わせることで、工作機械に関する

ラウドサーバから取得し、ここでは、3Dビューワ内での詳細情報（工作機械の名称、機械種別、稼働状況、消費電

可視化、グラフ作成のためのデータとして利用している。

力、パトランプの状態）をポップアップにて表示する。工

なお、取得しているデータは以下のとおりである。

場内はいくつかのエリアに分けることが可能で、広い工3.2場の中で目的のエリアだけを中止したい場合は、図13に● ジオメトリデータ

示されているようにエリア別に3Dビューワーを利用する● IoTデバイスからのセンシングデータ（温度、湿度、照ことができる。また、エリアでのグループ分け以外にも度、騒音）● LiDARセンサからの点群データ

図12＊8

アプリケーションのスクリーンショット

機械種別ごとにグループ分けを行うことも出来る。これらのグループ分けは利用者が事前に決めることになる。

図13

エリア別の強調表示機能

https://www.cimx-initiative.com/

87

工場の3Dジオメトリには、テキスチャが付与されている

Q6 3Dによる可視化は直感的でしたか？

場合、そのテキスチャも表示されるが、その場合、工作Q7 グラフ機能による、稼働状況の可視化はわかりやすい

機械を示すオブジェクトが見にくい場合がある。そのため、図14に示しているように、3Dジオメトリに割り当てですか？
Q8 グラフ機能は工場業務に役に立ちそうですか？

られているテキスチャを単色かつ透過したものに変更する機能がある。これにより、視覚的に工作機械が捉えや各設問の意図として、まず設問Q1、Q2では、映像の再現すくなっている。そして、図14では、IoTデバイスから取性について問いた。現実の工場のツインとして、仮想空得した環境情報をヒートマップとして3Dジオメトリの上間上に工場のジオメトリデータと共に各種工作機械、デにオーバーレイする機能も搭載しており、環境情報を数

バイスのオブジェクトを反映させているため、そこに違値だけでなく、可視化することを行っている。図15では、和感を感じたかを問いている。

工作機械の稼働状況をガントチャートを用いて時間別に表示している。図16では、工作機械の電力消費量を稼働設問Q1では、Matterportを用い作成したジオメトリデー

状況による積み上げ棒グラフにて表示している。ここでは、3Dビューワーをリアルタイムに情報を把握するための機能として、グラフは過去や現在の履歴データから工場の状態変化を示すための機能である。
3.3

評価

今回、このアプリケーションやクラウドサーバを含めた全体のシステムを評価するにあたって、主観評価としてユーザアンケートを実施した。この節では、本アンケー
トを用いた定性的な評価を行う。なお、今回のユーザア

図14

テキスチャ透過、ヒートマップ表示機能

ンケートで使用したアプリケーションはブラウザで利用するWebGL版とした。このアンケートはリッカート尺度に基づき、アプリケーションの内容について、8つの指標を用意し、それぞれ悪いから良いまでの五段階評価で回答してもらった。
3.3.1

質問項目

アンケートでは、リッカート尺度に基づき、以下8つの質問に回答してもらった。

図15

工作機械の稼働状況を示したガントチャート

Q1 3Dモデルの再現度に満足がいきましたか？
Q2 実際の工場（3Dモデル）に配置された工作機械と同じ場所にオブジェクトは存在したように感じましたか？
Q3 現在の工場の稼働状態を把握することができましたか？
Q4 過去の工場の稼働状態を把握することができましたか？
Q5 操作は簡単にできましたか？

88

図16

工作機械の電力消費量を示した棒グラフ

タに違和感を感じるか、設問Q2では、工作機械やデバイした動画ファイルへを参照するためのURLを記載したたスを示す立方体上のオブジェクトの位置がジオメトリ

め、回答者は必要に応じてこれらの事前知識を得ること

データ上の工作機械の位置からずれていないか、違和感が出来た。ここでは、回答者に実行してもらう操作としを感じないかを問いている。設問Q3、Q4では、指定したて、3D空間の閲覧操作、各工作機械の稼働状態の表示、操作を正しく行い、本アプリケーションの目的である現

過去の工作機械の状況を知れるタイムラプス機能の使在、過去の工場の稼働状況の把握を行うことが出来たか用、各種グラフの表示を指定した。

を問いている。
3.3.3

アンケート実施時の状況

設問Q5では、稼働状況把握などの目的を達成するためのアンケートでは、共同研究先である株式会社シムックス

操作において、その容易さを問いている。設問Q6では、イニシアティブの中島が登壇した寺小屋というセミナー

本アンケートの主目的である、三次元空間上に工場のツの参加者に対して実施した。ここで、参加者は約50名でインを再現し、可視化したことについて、その効果を問あった。アンケートの実施までの具体的な内容としては、いている。設問Q7、Q8では、グラフ機能について問いて中島が2021年11月10日に開催されたセミナーにて、アいる。設問Q7では、グラフによる稼働状況の把握のしやンケートの説明を行い、先述した本アプリケーションがすさ、設問Q8では、その利用可能性について問いている。

ブラウザ上で操作できるURLとアンケートを回答するためのウェブフォームのURLを提供した。アンケートの回

また、アンケートでは、リッカート尺度に基づいた8つの答期限は2021年11月10日から2021年12月1日までとし質問の他に、以下の補足情報についての回答項目を用意た。回答者は期間中、自由に上記URLを参照でき、自由にした。

アプリケーションを触れるものとした。また期間中、ア
プリケーションを用意しているサーバも同時に複数人が● 回答者の性別

アクセスして良いように増強を行ってからアンケートを● 回答者の年齢実施した。

● 工場業務に関する専門性● 本アプリケーションを使用するにあたって使用したデバイスの種類（名称）● 本アプリケーションを使用するにあたって使用したデバイスのOS名● 本アプリケーションを使用するにあたって使用したブ
ラウザ名● アプリケーションを使用した際のネットワーク環境

3.3.4

アンケート結果

約50名の参加者の内、回答者は男性22名、女性1名であった。年齢構成としては、20代 2名、30代 3名、40代 8名、50代 8名、60以上 2名であった。また、工場業務の専門性に対する解答として専門家 6名、非専門家 15名、無回答 2名であった。参加者は工場関係者のみならず、ビジネス的な観点を持ち参加する人が多かったと思われる。

● 本アプリケーション内にてサンプルとして使用している工場へ行ったことがあるかどうか

アンケートの調査結果を図17に示す。グラフの横軸は1● 感想・要望から5までの5段階の回答比率を表し、合計値は100%で● 不具合報告ある。中間評価である3の回答比率の中心を横軸の原点0%に置く。横軸の正の方向には高評価である4と5を、負3.3.2 アンケートの回答方法、操作手順の指定の方向には低評価である1と2を置いている。これは、高回答者には、本アプリケーションがブラウザ上で操作で評価の回答数が低評価の回答数より多い場合、グラフがきるURLとアンケートを回答するためのウェブフォーム

正の方向に偏り、その逆の場合、負の方向に偏ることを（Google Formsを利用）のURLを提供した。なお、アンケー示す。

トの説明書きの中にアプリケーションの操作方法を説明したプレゼンテーション資料や同じく操作方法を説明

図17を参照すると、アンケート結果は殆どの設問で概ね89

高評価を得られた。また、アンケートの感想や要望の項

企業が展開している工場監視ツールやIoTデバイス管理にて受け取った意見を確認すると、稼働状況の可視化がツールは二次元上にマッピングされた監視ツールが多リアルであったといった意見や温度マップといった環境

い。ただ、本意見の続きとして、新入社員などが工場管理に関する情報を三次元空間上に投影することは分かりやを行う場合や設備数が多く、設備番号で直感的にどこのすいといった意見があった。これは、本手法にて作成し設備だと分からない場合には有効かも知れないといったた三次元空間上に工場の稼働状況を再現するといった手意見や温度マップなど環境に関することについては3D法が一定の効能を持つことを示していると言える。

マップのメリットを感じたといった意見に続けており、本アプリケーションの監視だけではない目的というもの

しかし、設問Q5については、他の設問と違い、低評価のが提示された。

方が顕著である。これは、操作性の項目であるが、これはアンケートに用意した感想・要望の項を確認すると、操本アプリケーションは、現在、温度マップの表示のみ行っ作が難しい、望んだ工作機械に対して思うようにズームており、湿度マップや騒音マップなどは作成していない。

することが出来なかったといった意見があった。これは、そのため、今後はそういった3D空間をフルに活用するこ本アプリケーションでは、工場の中心点（全体のメッシュとが出来るヒートマップ機能の拡張や3D空間を活用したデータの端を計算し、その中点を求める）を中心として回

新たな機能の開発が求められる。また、対象とした工場

転する設計になっており、上下左右回転といった自由移

内にて、立体的に監視対象のオブジェクトが配置されて動を限定しているためにあると想定される。

いる場合、例えば、スペースを有効活用するべく、立体的に荷物を置いていることが多い、倉庫や物置などについ被験者の他の意見として、生産業務において3Dであるては3Dとしての恩恵が強いのではないかと思われる。

必要性は感じなかったと言った意見があった。実際、各

図17

90

アンケート結果のリッカート尺度

要求性能評価である。この機能では、指定した期間内の1分置きのデー

3.4.1 ネットワーク性能

タを取得するため、通信時に発生するデータ通信量が非

本アプリケーションを実行するにあたって本アプリケー

常に大きい。そのデータ容量は期間を1日に設定した際ションを継続的に利用するために必要なネットワーク性に、約3.6MBである。この機能では、何日間でも指定でき能を評価する。

るため、その期間を伸ばしていくたびに約3.6MBの通信

3.4

量が1日ごとに発生する。
本アプリケーション本体のデータは約9[MB]であり、これは初回起動時にダウンロードされたのち、Unity3Dの以上から、本アプリケーションを継続的に利用する場合、機能によりその大部分がブラウザ上にキャッシングさせ

タイムラプス機能が特にボトルネックとなり、例えば1かることが出来る。また、本アプリケーションでは、ジオ月間のデータを一気にタイムラプス機能で見ようとした

メトリデータはキャッシングを利用し、初回起動時以外際には、約108[MB]ほどの通信を行うため、データダウには通信を圧迫しないため、ジオメトリデータも本アプ

ンロードに10秒ほど待ったとしても約86.4[Mbps]の高速

リケーションを継続的に利用するためには、重視されな通信を要求されてしまうという結果となった。

い。そのため、ここでは、アプリケーション内でのユーザの操作によってリアルタイムに発生するサーバとの通信

なお、過去の発表[143]では、LiDARセンサからの点群のデータを見ていく。

仮想空間上へのマッピングも行っていたが、点群データ
は容量が大きく、帯域を圧迫してしまうため、今回のア

まず、工作機械やIoTデバイスなどからのセンサ値を取得

プリケーションでは機能を削除した。

する操作を行った場合にサーバへ通信を行うが、これは一つ当たり約800[B]であり、極めて軽量である。

第４章

WebRTCを用いた宅内環境間P2Pリアルタイム
通信性能計測次に、本アプリケーションが定期的に行う通信として、
工作機械全体の状態把握（三次元空間上にて工作機械を表す立方体の色分けや警告通知に使用）がある。これは、

4.1

全ての工作機械の情報を一度のリクエストで取得する新型コロナウイルスが世界で流行し、多くの人々がリが、データ容量は約5.5[KB]であり、これもまた軽量であ

モートワークをするようになり、遠隔コラボレーション

ると言える。他にも様々な通信（ログイン情報や利用者をする機会が増えた。例えば、かつて対面で行っていた情報など）があるが、これらは全て1リクエスト当たり

会議は、ZoomなどのWeb会議アプリを使って、遠隔で行

10[KB]未満である。

う頻度が増えた。しかし、音楽の合奏などの、高品質な同WebRTC計測概要

期が必要な通信では、Zoomのようなサーバー・クライア
次にグラフ機能を使用した際に発生する、全ての工作機

ント通信を使ったWeb会議アプリでは遅延が大きく、満械の詳細データを取得した際のデータ容量を見ていく。

足のいく活動ができない。この問題に対応するため、宅グラフ機能は、日、月、年ごとに各工作機械の情報を閲

内ネットワーク同士をP2Pで結ぶことで、遅延を減らす

覧できるが、これらは事前にサーバ側で計算されたデー

アプリケーションが登場している。例えば、Yamahaのタを表示しているため、そのデータ容量は約33[KB]と小Syncroomは、宅内ネットワーク同士をP2Pでメッシュ接さい。

続することで、最大五人でリモート合奏をすることができるアプリケーションである。しかし、このアプリケー

最後に、タイムラプス機能を使用した際に発生する、全ションはネットワークの性能によってはうまく動かないての工作機械の詳細データを取得した際のデータ容量をことも多く、広く普及するに至っていない。普及に先駆見ていく。まず、タイムラプス機能では、連続した日付とけて、宅内ネットワーク間の性能計測を広く行い、実態時間を指定し、過去の状態を閲覧することが出来る機能を把握することが重要である。しかし、宅内ネットワー

91

ク間の性能計測を行っている先行研究はほとんどなく、シュ全体のP2P接続のRTTの傾向について直感的に把握計測する手法すら確立されていない。そこで、本研究でし、問題解決へとつなげやすい可視化を目指した。

はWebRTCを 用 い て 宅 内 環 境 を 結 ぶP2P性 能 を 容 易 に計測する手法を提案する。WebRTCとはWeb Real-Time

資源の制約

Communicationsの略で、ブラウザやモバイルアプリに簡旧式のノートパソコンの性能でもでも動作するような潔なAPIを通じてリアルタイム通信を提供するオープン

ツールを作れば、可用性が高まり、より多様な宅内環境

ソースの技術である。

での計測に対応できる。またRaspberry Piのようなシン
グルボードコンピュータで動作するようなツールを作れ

本研究の貢献は、専用ハードや専用ソフトを使うことなば、宅内環境のクライアントとは別に、静的に常時接続

く、WebRTCにより宅内ネットワーク間の性能を簡単にをし続けるクライアントを配置して計測に参加させるこ計測するツールを開発し、実際のインターネットで計測とが可能となる。本研究では可能な限り多様な環境で計した結果を報告することである。

測したり、Raspberry Piでも動作するような軽い計測ツー
ルを作成することを目指した。

4.2

要求事項

本研究で提案する手法の機能要件は以下の5つである。

計測の粒度
本研究では、60ms以下の遅延を計測することを目指す。

計測の容易さ

本研究では、合奏などの用途を想定したP2Pの性能評価

RIPE AtlasやXbox 360を 使 用 し た 計 測 は、専 用 ハ ー ドを行うことを目指している。[144]では、問題なく合奏をウェアに依存するため、多様な環境下での計測が困難で行うことが可能なネットワーク遅延は30ms程度とされある。専用ソフトウェアを用いた計測は専用ハードウェていることから、上記の目標を達成するには片道30ms、アを用いた計測よりも要件は緩いが、それでもインス

往復60ms程度の遅延を計測することが可能な計測手段

トール作業が必要となってくるため、依然として一定のを採用する必要がある。

困難がある。専用ハードウェアや専用ソフトウェアをインストールすることなく、多くのPCにすでにインストー

これらの機能要件を満たすことができれば、従来よりもルされているソフトウェア上で計測できれば、上述した多様な環境下で、専用のハードウェアやソフトウェアを問題を解消でき、だれでも簡単に計測に参加できる。

導入することなく、ユーザー主体でP2Pメッシュ接続環
境下でRTTを計測をできる。

P2P networkネットワークの分析
YamahaのSyncroomのようなアプリケーションは、複数

4.3の宅内環境をメッシュで接続することで多人数のコラボ

本研究では、WebRTCを用いた宅内環境間P2P接続におレーションを実現している。実際の利用環境と近い状態

けるRTTを計測する手法を提案する。WebRTCはNATをで計測するためには、多ノードをメッシュで接続した環越えたP2P通信をサポートしており、かつgetStats（）とい境での計測が必要である。また、一般的な宅内環境ではうメソッドを使用すればRTTなどの統計情報も取得する

NATを用いてインターネットに接続しているため、NATことができる。また、多くのPCにインストールされてい環境での計測に対応する必要がある。

るGoogle Chromeなどのブラウザがあれば使用可能であ提案手法る。したがって、WebRTCを使った計測を行うことで、直感的な可視化

本研究が目指すEase of Measurementと Comprehensive

多ノードフルメッシュ接続の統計情報は、生データのまanalysis of P2P networkを実現することが可能である。

までは直感的に評価できない。計測をP2P通信性能面で92の問題解決に役立てるという本来の趣旨に結び付けるた本研究のデザインを図18に示す。本研究では、
各宅内ネッ

めには、データ可視化手法が不可欠である。今回は、メッ

トワークにあるPCからGoogle Chromeを用いて計測用

Webサイトにアクセスを行い、JavaScriptの計測プログ

たRTTは、フロントエンドでリアルタイムに可視化されラムをクライアント上で実行する。計測プログラムの動るほか、データ収集サーバーにもPOSTされ、データベー

作は以下の三段階に大別される。

スで永続化される。データベースで永続化されたデータに対し、計測終了後にヒートマップによる可視化を行う。

● Signaling

こ れ に よ っ て、本 研 究 のReqquirementで あ るIntuitive● P2P Connect

Visualizationを目指す。

● Collect Data and Visualize
4.4実装

Signalingで は、ま ずNATを 超 え たP2P接 続 に 必 要 な

本研究の実装を図19に示す。本手法の計測プログラムはSession Description Protocol（SDP）を、計測サイトに接クライアントのブラウザ上で実行されるJavaScriptファ

続している他のクライアントとサーバーを通じて交換イルである。まず計測URLにアクセスすると、Signaling

す る。Signalingが 完 了 す る と、P2P Connectが 行 わ れが行われる。Signalingでは、シグナリングサーバーとる。P2P Connectでは、WebRTCによるNATを超えたP2P

WebSocketを用いた通信が確立される。WebSocket通信

接続が開始され、設定されたサイズ・間隔でデータを送が確立されると、クライアントはSDPをシグナリングサー

信 す る。P2P Connectが 行 わ れ て い る 間、Collect Data

バーを介して同じく計測サイトにアクセスしている他のand Visualizeを 行 う。Collect Data and Visualizeで は、

クライアントと交換する。Signalingが完了した後、Web

WebRTCの機能でP2P接続のRTTを取得し続ける。取得しサイトのConnnectボタンを押すと、P2P Connectが行われ、他のクライアントとのWebRTCによるNATを越えた
P2P接続が確立される。
そして、ある条件のデータサイズ・送信頻度で、他のクライアントにデータ送信が開始される。この条件は時刻によって変化する。P2P Connectが行われている間、Collect Data and Visualizeが行われる。Collect Data andVisualizeでは、1秒間隔でRTT・現在のUnixTime・データ
送信条件が取得される。この統計情報はChart.js用いてク
ライアント上でリアルタイムに可視化されるほか、JSON形式でデータ収集サーバーにPOSTされる。POSTされる
JSONに格納されるデータは● Date: ブラウザ上で取得された日付[ms]● yourIsp: ノードが接続している回線のISP● candidatePair_RTT: WebRTCによるP2P接続のRTT[ms]● currentSendBytes: 実験条件
（送信バイト数）● currentSendTime: 実験条件
（送信間隔）である。サーバーはFlaskによるAPIサーバーとSQLiteによるデータベースから成り、POSTされたJSONはAPIサー
バーを通じてデータベースに登録され、永続化される。
サーバー上のデータベースで永続化された統計情報に対

図18

設計

し、計測終了後にサーバー上で分析・可視化が行われる。

93

1つのクライアントが取得可能な統計情報は、自分と他

WebRTC計測値にどのような特徴が見られるかを確認すのクライアントとのP2P接続の情報のみだが、サーバー

る予備実験を行った。

でそれらを収集することにより、サーバー上でフルメッ
シュでデータ分析を行うことが可能になる。

実験環境は表4に示す。tcコマンドで0ms、10ms、100msの定常遅延を発生した際の結果は表5となった。tcコマ

サーバーに統計情報を送信する際に、WebRTC接続のンドで発生させた遅延のオーダーに関わらず、WebRTC

RTT以外に、計測開始時にipinfo.ioにリクエストを送信しの方が平均で1-3ms計測値が大きくなるという結果でて得られたグローバルIPアドレスやISP等の情報も送信あった。これはWebRTCの処理遅延であると考えられる。

する。これによって、IPアドレスやISPの差異とRTTに関する議論なども行うことが可能となる。

ま た、tcコ マ ン ド で30msの 定 常 遅 延、30msのjitterを発生させた場合のboxplotを図20に示す。jitterを発生さ

サーバー上での可視化にはヒートマップや有向グラフ等せた場合では、すべての四分位点においてWebRTCのの手法を用いた。これにより、メッシュの統計情報を直方が0-3ms計測値が大きくなるという結果で、これも感的に理解することをめざした。

WebRTCの処理遅延によるものであると考えられる。

4.5

表4

WebRTC計測値の信頼性評価

WebRTCの 通 信 プ ロ ト コ ル は[145]で「SCTP over DTLS
over UDP」と規定されており、これはRTTを計測する従来の手法、例えばPingとは大きく異なっている。そこで、本研究ではWebRTCのRTT計測値と、Ping計測値を比較し、

図19

94

実装

WebRTC Ping比較実験

これらの結果から、WebRTCによる計測はPingと比較アクセスしてもらい、計測を実施した。結果を取得する

し て 定 常 的 な 処 理 遅 延 は あ る も の の、[146]で 主 張 さことができた計測ノード数は10で、GeoIPによる地理情

れている合奏を行う上での限界遅延50msを計測する

報では図21に示した通り、東京に7、神奈川に1、千葉にのに十分な計測値を得ることが可能であると考えられ

1、岐阜に1ノードという分布となった。計測を行うにある。これによって、本研究のRequirementのGranularity ofたり、WebRTCのdataChannelでは毎秒100byteずつデー

measurementは、WebRTCを用いた計測によって満たさタを送信し続け、1秒おきにRTTを取得し、サーバーへのれていることが分かった。

送信・収集を行った。

4.6

メッシュ全体から取得されたRTT値群の分布は図22と実験

このツールを使用して、実際に宅内環境を結ぶ計測実験なった。これはRTT値群を10msごとの区間で分けていを行った。実験参加者には、実際に各家庭・組織のLAN環る。0ms-50msの区間では103から104個の計測値が収集境内にあるノートPCからGoogle Chromeで計測サイトにされているが、50ms-100msの区間で減少し、100ms以上の区間では102個程度の計測値しか収集されていない。

表5

WebRTC計測値とPing計測値比較

また、各P2PのPeerConnectionごとに得られたRTT値群の99％点をヒートマップで図示すると図23のような結果となった。このヒートマップの数字は各計測ノードに対応しており、図21の地理的関係とも対応している。な
お、50ms以上の計測値は全て赤で表示しているが、そのようなピア数は29個となった。
4.7

計測結果の検討

図23では、1番のノードは東京に所在しているが、同じ東京のノード5番と10番との間に50ms以上の遅延が発生している。他方で、岐阜に所在している6番のノードは東京のノードと50ms未満の遅延で接続されているケースがある。このようなことから、宅内環境間を結ぶP2Pの遅延は、地理的な位置関係よりも宅内環境の問題に依存
図20

している可能性が高いと考えられる。これは、東京-岐阜

jitter

図21

location95

間の270kmの距離が、光速で1ms程度しか要さず、光速本研究ではフルメッシュによる接続を目指していたが、による遅延が相対的に問題にならないということから考

実際には全フルメッシュのピア数90通りのうち77ピア

慮しても妥当な結果であると考えられる。

しかRTTの計測値を収集できておらず、これはWebRTC
によるP2P接続の確立を行うことができなかったものと[146]で示されている、ネットワーク上で問題なく計測を考えられる。より高い確度で安定的に計測値を取得する行うことが可能な50ms未満の遅延のピアはRTTを取得には、現在の宅内環境間を直接接続する単純な実装ではできた全77ピア中48ピアという結果に終わっており、現なく、TURNサーバーを中間に建てるような実装や、計測

在のインターネット環境では必ずしも多くの人がリモー用のダミークライアントをあらかじめ配置しておく等のト合奏のような高い同期が必要な活動を行うことができ対処が有効であると考えられる。

るとは言えない状況であると考えられる。また、50ms未満という最低限の要件は達成していても、高いQoEを実4.8

現するにはさらに厳しい条件が必要であり、実際に満足本研究では宅内環境間P2P接続のRTTを広範に、かつ簡のいく活動を行うことができる環境は更に限られてくる

単に、プラットフォームに依存せず計測できる手法としと考えられる。

て、WebRTCを用いたブラウザベースで動作する宅内環

結論

境間P2P計測ツールを提案・実装した。また、本ツールを使用して、実際に10個のノードに対してメッシュでP2P接続を行いRTTを取得し、可視化を行った。結果として、合奏のような高い同期が必要な活動を行うことが可能な
ピアは非常に限定されるということが分かった。今後の課題としては、現在のような遠隔環境間を直接P2Pで接続するだけの単純な実装ではなく、TURNやダミークラ
イアント等をネットワーク上に配置したうえで計測を行うことや、地理的に大きく離れたピア接続のRTTを取得することにより、地理的距離がRTTにもたらす影響を検討することなどが挙げられる。

第５章
図22

まとめ

Histogram

本報告書では、2014年より開始したSDMコンソーシアム
で進めて来た、視聴空間サービスのソフトウェア制御による研究で、2021年度に行なった活動について報告した。
SDMコンソーシアムでは、ソフトウェア処理による視聴空間の制御、映像音声を制御するネットワーク機器、イ
ンタラクティブ・ユーザインターフェイス、SDMプラットホームを利用したコンテンツ作成など、共同研究活動に参加するパートナーを募集しています。
ご協力をよろしくお願いいたします。
図23

96

PeerConnection RTT 99% Point[ms]