Coppell Technologies　データ仕様の現状と課題

Menu

Coppell Technologies
Fiwareで都市OSを動かしてみよう
NGSI-LDにも挑戦

データ仕様の現状と課題

スマートシティの標準規格
データモデルのユースケース

Column
Link集
用語集

Coppell

Technologies

6. データモデル共通化の限界と対応
6.1 データモデルの共通化の限界
2022年6月5日
　データ交換は既に述べたように「基本的に」文字セット、語彙、データモデルをデータ提供側と受け取り側で共通化して行います。しかし、第1章で議論したように、データモデルは目的に最適化して行うので、目的が違えばデータモデルが違ったものになってしまいます。例えば、自治体共通オープンデータセットは自治体のデータを住民や企業に公開する事が目的で作られていますから、多くのデータは二次元の表形式にまとめたり、項目名に日本語を用いるなどにより視認性が良いものになっています。一方、Smart Data Modelsでは、コンピューター間のデータ交換におけるデータの汎用性やグローバルな活用を重視しているために、データを覗いても素人にはよくわからない暗号の様なものになってしまっています。この様に、目的か違えばデータモデルが異なることが当たり前です。
　同様に、一旦標準となる仕様を策定しても仕様自体が年々進化していきますし、既存のシステムもあります。そこで、スマートシティではデータ変換の機能を実装していることが一般的です。
　以下、データ変換の実装について紹介します。

6.2 外部データ連携
2022年6月5日
　スマートシティリファレンスアーキテクチャでは、都市OSの機能の一つとして、「外部データ連携」を定義しています。外部データ連携はセンサ・デバイス・既存システム・外部サービスなど、都市OSの標準に合致していないデータや信号を変換し、都市OSの標準に合致するようにする機能です。
　スマートシティリファレンスアーキテクチャのホワイトペーパーでは、外部データ連携の機能を「データ処理」と「データ伝送」に分類すると共に、各々の要件を以下の4つずつ定めている。この様にデータやデータ構造を機械的に変換するだけでなく、必要な制御も行う必要があります。

■データ処理
個別機能 説明
データ変換 外部から取得したデータを都市OS が扱える形式に変換できること。変換対象は、語彙や、形式、項目等が存在するが、取り扱うデータにより変換対象が異なる。
データ受付
（キューイング）		 都市OS にデータを蓄積するため、データアクセス（登録・参照）を受け付けること。連携対象は、スマートシティアセットや、他システム等があげられる。
データ取得
（クローリング）		 定期的に他システムを巡回し、データを取得できること。
データ補完 リアルタイムデータ等で欠損したデータを補完し、データ品質を向上できること。データの補完方法は様々な方法があり、目的に応じた補完方法を選択できることが望ましい。

■データ伝送
個別機能 説明
プロトコル変換 地域に展開するスマートシティアセットや他システムと接続するため、一般的な通信プロトコルから都市OS が対応する通信プロトコルに変換できること。
分野間データ検索 都市OS 外に分散されたデータを、データの概要情報（カタログ）を基に検索できること。
※将来、分野間データ連携コネクタとの接続に活用される。
分野間データ交換制御 都市OS、他システムの双方の取り決めによりデータの利用権限を判断し、データのアクセス範囲を制御できること。
※将来、分野間データ連携コネクタとの接続に活用される。
分野間データ交換記録 トレーサビリティによるデータ品質向上のため、都市OS と他システムの双方で連携したデータの交換履歴を記録できること。
※将来、分野間データ連携コネクタとの接続に活用される。

6.3 データ仲介におけるデータ翻訳
2022年9月22日
　第4回デジタル田園都市国家構想実現会議(2022/2/24)で牧島デジタル大臣から提出された「データ連携基盤の整備について」に記載されているが、Fiwareのcontext brokerであるFiware/Orionにデータ翻訳機能を追加し、データモデルの相互変換を行う。この機能が無償で公開されるとの事なので、今後はある程度のデータモデルの相違は都市OS自体が吸収してくれるようになる可能性があります。尚、この機能は、現在最新のバージョンである3.7のドキュメントには記述は見つかりません。今後の活動に注目していきたいと考えています。



　出典:「データ連携基盤の整備について」第4回デジタル田園都市国家構想実現会議(2022/2/24)で牧島デジタル大臣

6.4 コネクタ方式
2022年9月22日
　前節と同じく牧島大臣の資料で紹介されていますが、多数の参加者間でデータ変換(翻訳)する方法として、コネクタ方式があります。日本では、データ社会推進協議会 (DSA)がこの考え方に従ってDATA-EXを開発しているとの事です。但し、この機能については、関係者以外は情報を得られないため、現時点ては詳細不明です。ただ、各スマートシティが色々なサービスのデータ交換の際に形式変換するというよりも、日本全体の基盤として提供される様に伝えられています。


　出典:「データ連携基盤の整備について」第4回デジタル田園都市国家構想実現会議(2022/2/24)で牧島デジタル大臣

6.5 データ変換の限界
2022年6月5日
　本章に記載したようにデータモデルの変換をサポートしてくれる機能の実装は将来的には徐々に進んでいくとは思われますが、当然ながら存在しないデータをコネクタ等が勝手に作り出す様な事は出来ません。このため、本章の機能の実装を前提にしつつも、以下の内容は共通化していくべきと考えています。
項目 課題
データ欠損 既に記載したように、存在しないデータを翻訳時に勝手に作り出すことはできません。例えば、標準データセットでは曜日ごとに開館/閉館時間が異なる事は表現できません。従って、Smart Data Modelsの開館時間の情報から推奨データセットのデータを作り出すことは出来ますが、逆はできません。また、各種標準では、データ項目の多くがデータを実際に登録するかどうかは利用者が目的に応じて判断する任意項目となっています。このため、自治体や業界で相談して、この項目は任意項目だけれど皆で設定する事にしようなどと取り決める必要があります。
精度 数値項目では、精度を取り決めておく必要があります。例えば、GIFでは緯度経度は小数点以下6桁と規定していますが、もし、どこかのシステムが緯度経度を5桁で作成してしまうと、6桁のデータへの変換は出来ません。
コードの設定範囲と分解能 政府は697個のコードがあるとの事ですが、国コードや自治体コードの様に漏れなくコード化されているものがある一方、定義にないコードや分解能が低いコードがあり得ます。筆者は専門ではないので想像になりますが、GIFでも参照しているCityGMLで定めている設備の種別コードメンバにAir Conditioningがありますが、室外機、室内機、全熱交換器など多種の機器から構成される空調設備をひとまとめにする事は、建築物の外形内形を対象とするCityGMLでは妥当でも、施設管理の観点では分ける必要があるのかもしれません。
データの表現方法 CityGMLでは設備の位置は住所や座標で表現します。しかし、施設管理の観点では、どの部屋のどの位置に設備が設置されているのかの情報が必要となる場合があります。例えば、施設において空調が故障したとの連絡があったとき、「図書室の天井」などの情報の方が正確な座標より役に立つ情報となります。
データの関係 ある部屋の温度を知りたい場合、どの温度センサがどの部屋に設置されているのかという、部屋と温度センサとの関係が予め分かっている必要があります。この関係はBIMやビル管理システムなどの外部システムから情報を入手するか、手作業でデータ登録する必要があります。
サンプリング間隔 例えば、電力消費のデータを取得したい場合、一般的には30分毎の合計値です。でも、一般家庭の電力料金の検針はひと月毎です。30分毎のデータは足し算すればひと月毎のデータに変換できますが、逆はできません。この様にデータの採取を繰り返す場合、サンプリング間隔を決めておく必要があります。
IDの不一致 データを変換する場合には複数のデータを突き合わせて新たなデータを作成する事がよくあります。この突合を単純化する手法がIDの統一ですが、もし不一致だとつき合わせが出来ず、データ変換が難しくなります。統一と言っても今のIDを廃止する必要はありません。例えば、BIMの標準ファイル形式であるIFCでは部屋やセンサなどの各オブジェクトにはguidというIDを振ってあります。従って、都市OSでも部屋やセンサの情報を登録する際には、都市OS側のデータにもIFCと同じguidをデータとして格納しておけば、突き合わせが可能となります。