狠狠撸

狠狠撸Share a Scribd company logo
メタデータを?いた
EnOceanプロトコルの汎?的変換
NTTソフトウェアイノベーションセンタ
前?道 浩之
IoTの課題(多様性/Interoperability)とそれに対す
るアプローチ
変換プログラム
Device
Cloud IoT
Service等
課題
? デバイスの多様性
– デバイスプロトコルは多数ある。
– ?つのデバイスプロトコルの中にも、様々なデバ
イス種類がある。
? サーバ/Cloudのプラットフォームも多様である。(360
種類以上のIoT PFがあると?われる。*1)
? プロトコル/データ変換プログラムの作成が?変。
アプローチ
多様なプロトコルやデータモデルに関する知識をメタデー
タとして定義しておき、それを変換プログラムが解釈する
ことで、プロトコル/データの変換を?うことで、多様な
デバイス、多様なサーバへ対応する。
このようなメタデータが充実し、お互いに繋がることで、
実際のデバイスやデータも繋がってゆく。
IoT GW
Device Device
Cloud IoT
Service等
複数のIoT Service
多種多様な
デバイスプロトコル/
デバイス種別
2
デバイス
プロトコ
ルの知識
サーバプ
ロトコル
の知識
*1 https://iot-analytics.com/current-state-of-iot-platforms-2016/
EnOceanとは
? EnOcean Allianceが標準化する無線ベースのデバイスプロトコ
ル
? 省エネルギーが特徴。
– エナジーハーベスティングに対応した機器もある。
スイッチを押した?を使って発電し、通信を?う。
IoTの課題の?つである電源問題を画期的な?法で解決している。
IoTにおいて魅?的なプロトコル/デバイス
-> 本提案ではEnOceanに注?する
EnOcean Alliance https://www.enocean-alliance.org/ja/
3
EnOceanのデータモデル
? プロトコルの情報がXMLとして形式的に記述されている。
– デバイスタイプ 270種類, 5万6千?、約3MB
– 様々な情報が形式的に記載されている
-> 変換を?動で汎?的に?えそう。
– 省電?のためか、電?を節約する傾向がある。例:
? 測定値とエラーコードを同じbyteで表現
? 特定のbit列の値により、 その他のbitの解釈を切り替える仕組み(Case)
? PDFに出?された??等を確認する必要もある。
– ?由記述依存する部分(形式的に書ける場合でも..)
– 表記揺れ?間違いと思われる記載、
– 出?の解釈に、EnOceanのドメインの知識を必要とするもの。
– 記載の省略
かなりの情報が形式的に書かれているが、汎?的な変換プログラムを作
るには情報が不?する。
そこで、?間が読み取った情報をRDFで記述し、上記XMLを補完して?
いることで、?動的な変換を狙う。
4
Use Case 1: 汎?的データ変換
? 複数のデータモデルに効率的に対応したい。
? 将来データモデルが追加されても、補?情報を
適切に記載することで、変換プログラム1を変更
することなく対応したい。
? 将来的には、多様なクラウドにも対応したい。
? ?旦、技術?依存形式
を経由することで、多対多
のマッピングを、多対1の
マッピングとして扱う。
EnOcean
Data model
(XML)
補?情報
(RDF)
変換プログラム1
EnOcean
Device
Cloud IoT
Service等
変換プログラム2
Device
Protocol
依存形式
Cloud IoT
Service依存
形式
技術?依
存形式
IoT GW
サーバ側知識
5
デバイス側知識
本提案で取り組む領域
Use Case 2: Data Model 補正
データモデルの誤り、曖昧性、?由記述への依存を取り除く
EnOcean
Data model
(XML)
補?情報
(RDF)
補正済み
EnOcean
Data model
(XML)
修正プログラム
曖昧性↓
品質↑
機械可読性/?動化割合↑
6
EnOceanのうち、対象とするスコープ
Profileに応じた
データ通信
RPC
Teach in
EnOcean Equipment Profile(EEP) Generic Profile
ココ
?番多様性がある部分に注?
従来からあるプロ
ファイル。
270種類のデータ
モデルが規定
?較的新しく作られたプ
ロファイル。汎化された
?法でDecode可能
7
デバイスプロファイル
の種類
データ通信の分類
データモデルの例 温度計(A5-02-16)
<datafield>
<data>Temperature</data>
<shortcut>TMP</shortcut>
<description>Temperature (linear)</description>
<info>DB_1 Temperature (8 bit) -40...0 °C, linear n=255...0</info>
<bitoffs>16</bitoffs>
<bitsize>8</bitsize>
<range>
<min>255</min>
<max>0</max>
</range>
<scale>
<min>-40</min>
<max>0</max>
</scale>
<unit> °C</unit>
</datafield>
8
エンコードされたデータの値の範囲
物理量に変換した値の範囲
データの格納されている位置
データフィールドのラベル
http://tools.enocean-alliance.org/EEPViewer/profiles/A5/02/16/A5-02-16.pdf
線形変換
EnOceanデータモデルの主要な概念とRDFでの表現
EnOcean上
の概念
説明 RDF表現での
class
instanceの命名規約 備考
Type デバイスタイプ en:devicetype en:rr-ff-tt rr, ff, ttは16進数
Case デバイスタイプ毎に1個ま
たは複数存在する。条件に
より、データの解釈を切り
替えるために?いられる。
en:case en:rr-ff-tt-cc ccはcaseの連番
(16進)
Condition Caseを選択する条件 en:condition 空?ノード
Datafield 送受信されるbit列に含まれ
る、意味のある単位
例?測定値など
en:datafield en:rr-ff-tt-cc-nn nnはdatafieldの
連番(16進)
shortcut データフィールドの名前 ?字列Literal ?字列Literal
Scale ビットで表現される値を、
物理的な量としてどの範囲
にあたるかを、min,maxで
記載したもの。
数値Literal 数値Literal Bitで表現される
値から線形変換
で写像される値
域
9
?動処理を阻害する問題点?覧
ラベル 説明 原因など 件数(DF数など)
DF Combination 2つのDFを結合して意味の
あるデータになるもの
名前による暗?/ドメ
イン知識への依存
9
No Condition Caseを選択する条件が記載
されていない
?由記述への依存 13 (デバイスタ
イプ)
Selection あるDFの値によりDFを選択 ドメイン知識への依
存
3
Availability あるDFの値で別のDF有効/
無効を?す
ドメイン知識への依
存
8
Duplicated Shortcut 名前の重複 品質/不注意 22, 6(名前)
Special Meaning エラー等意味のある値を?
由記述で表現
?由記述への依存 10
Conditional Scale 他のDFの値にScaleが依存す
るもの
品質/省略 1
Type Reference 他タイプを?由記述で参照 ?由記述への依存 1
Enum Reference Enumを?由記述で参照 ?由記述への依存 1
Reserved DF ?由記述で不使?を表現 ?由記述への依存 1
Family Table 表による条件の指定 データモデル記述の
省略
42, 1(表)
10
問題点1/11 DF Combination (2つのDFの組合せ)
定義上は2つのDatafieldとなっているが、意味のある値にするには、結合してから評
価すべきもの。(離れたbit列を利?しているため2つのDatafieldになっている)
それぞれを別々の値として送られても困る。(解釈にドメイン知識が必要)
例:
A5-13-06/LAT(MSB) 0-3bit : 1111
A5-13-06/LAT(LSB) 8-15bit : 00000000
結合した 111100000000 が意味のある値になる。
MSB(Most Significant byte), LSB(Least Significant Byte)
という名前で暗?しているとも?える。
MC-LSB
空?
ノード
MC-MSB
rdf:_1
rdfs:label
Combination
Field
rdf:seq
subclassof
rdf:type
“MC”
rdf:_2
11
記述?法
DF, Caseクラス その他
凡例
問題点2/11 No condition (条件の記載ないもの)
caseが複数ある場合は、通常、case内にconditionタグがあり、そのcaseが選択され
るときの、条件(参照する場所と値)が記載されている。しかし、このconditionが記載
されていないものが10件程度ある。ただし、?由記述蘭やPDF仕様により判断可能。
Case1
空?ノー
ド
en:isSelectedBy
en:hasBitSize
en:hasBitoffset
Condition
rdf:type
Case
rdf:type
2
28
3
2つのデバイスタイプでは、Conditionが複数のDatafieldを参照している。この場合
caseに複数のconditionを紐づけてAND条件と解釈することとする。 (デバイスタイプ
例:D2-31-00)
*1 FieldTypeのsubclassのdatafieldtype, statusfield, directionのどれかを指す。
*2 valueか、hasMin,hasMaxのペアを持つかどちらか。(?致判定か、範囲判定か)
rdf:value
en:referingType
FieldType
*1
1
3
en:hasMin
en:hasMax
*2
12
記述?法
DF, Caseクラス その他
凡例
問題点3/11 Selection (DFの選択)
あるデータフィールドの値により、どちらのデータフィールドが有効かを?
す。(例: A5-06-01)
? データフィールド ILL1: 照度センサの値1 (600 – 60,000 lx)
? データフィールド ILL2: 照度センサの値2 (300 – 30,000 lx)
? データフィールド RS: ILL1/ILL2どちらが有効かを?す
ILL1: 32,000
ILL2: 30,000
RS: 0
ILL: 32,000改良
課題2:有効な?だ
け送る?が扱いや
すい
課題3:有効な?だ
け送れば不要
課題1:解釈するのにEnOceanの知識が必要 解釈にEnOceanの知識が不要
名称を固定
課題4:場合により
名称が、ILL1/ILL2
と変わる
13
問題点3/11 Selectionに関する記述?法
RS BNode
en:hasRole
ILL1
ILL2
rdf:_1
rdf:_2
rdfs:label
DataField
Selector
rdf:seq
rdfs:subClassOf
rdf:type
Data
field
rdf:type
“ILL”
14
DF, Caseクラス その他
凡例
問題点4/11 Availability(DFの有効性の提?)
あるデータフィールドの値により、別のデータフィールドの有効性を?す物がある。
(例: A5-04-01)
? データフィールド TMP: 温度センサの値
? 湿度センサの値 HUM: 湿度センサの値
? データフィールド TSN: 温度センサの有無(有効性)を?す
TMP: 20
HUM: 70
TSN: 0
HUM: 70
TMP: 20
HUM: 70
ないとき
あるとき
改良
課題2:ある時だけ
送ってくれた?が
わかりやすい
課題3:ある時だけ
送れば不要
課題1: 解釈にEnOceanの知識が必要 解釈にEnOceanの知識が不要
記述?法: A5-04-01/TSN en:indicatesAvailabilityOf A5-04-01/TMP
15
問題点5/11 Duplicated Shortcut(名前の重複)
ほとんどのデバイスタイプでは重複しないようにされているが、重なるものがいくつかある。
?間にわかりやすいラベルとして提供されていると考えられるが、重複していてはIDとしては
利?できない。
記述?法
DF1(VSPの2個?) skos:prefLabel “VSP2”
同名のshortcutのデータフィールドに対し、連番のついた(VSP1, VSP2)をprefLabel で?す。
DatafieldのURIとしては、caseの連番、Datafieldの連番を付与して表現することとした。
en:rr-ff-tt-cc-nn
TYPE名 + CASE名+ prefLabel(ない場合はlabel) shortcut名? を識別?として?いることも
できる。また、TYPE名 + prefLabelを準識別?として使える可能性もある。
本資料では、分かりやすさの点からこの名称を?いている部分もある。
A5-20-02/VSP 2回
A5-20-12/FANOR 2回
A5-3F-00/RSLV 4回
A5-3F-7F/undef 2回
D2-14-30/SMA 6回
D2-14-31/COA 6回
16
問題点6/11 Special Meaning(特別な意味の値 )
値の?部にエラーなどの特別な意味があり、測定値として扱ってはいけないもの。こ
の情報が?由記述として記載されている。
(例: A5-06-03/ILL)
<description>Illumination (linear)
<br/>DB2 = 8 MSB, DB1 = 2 LSB
<br/>1001: over range, 1002...1024: reserved
</description>
RS 空?Node
en:hasMeaning
rdf:value
rdfs:label
meaning
Indicator
rdf:type
Data
field
rdf:type
1001
“over range”
17
記述?法
DF, Caseクラス その他
凡例
問題点7/11 Conditional Scale
(他のDatafieldに依存するscale)
http://tools.enocean-alliance.org/EEPViewer/profiles/A5/20/04/A5-20-04.pdf
<scale>
<min>20 .. 80</min>
<max>10 .. 30</max>
</scale>
全体を読むと次の意図であることがわかる。
TSの値が0のとき、scale min=20, scale max=80
TSの値が1のとき、scale min=10, scale max=30
?由記述に依存する。しかも?由記述すべきでない場所に記載されている。
scalerangeshortcutoffset size
記述?法
FTS en:referScaleOf TS
TS en:hasConditionalScale [
a ConditionalScale;
value 0;
en:hasScaleMin 20;
en:hasScaleMax 80 ] .
TS en:hasConditionalScale [
a ConditionalScale;
value 1;
en:hasScaleMin 10;
en:hasScaleMax 30 ] .
A5-20-04
18
問題点8/11 Type reference(typeの参照)
いくつかのデバイスタイプは他のデバイスを参照する形で定義されている。
ほとんどのものは、<ref>タグにより明確に参照されているが、?由記述で記載されるもの
がある。
きちんと形式的に書いているもの
<type>
<ref>
<rorg>D2</rorg>
<func>01</func>
<type>00</type>
</ref>
</type>
?由記述に依存するもの (A5-10-1E)
<type>
…
<title>see A5-10-1B</title>
</type>
記述?法:
TYPE1(A5-10-1E) rdfs:isDefinedBy TYPE2(A-10-1B)
19
問題点9/11 Enum Reference (Enumの参照)
?由記述として、参照を記載
例?A5-3F-00/RSLV
<datafield>
…
<enum>
<item>
<value/>
<description>See prev</description>
</item>
</enum>
<datafield>
..
<enum>
<item>
<value>0x00</value>
<description>not supported</description>
</item>
<item>
<value>0x01</value>
<description>≥ -31</description>
<unit>dBm</unit>
</item>
..
</enum>
PDFに出?する?的であれば同じ表を
何度も掲載したくない事も理解でき
る。
論理的にはitemのdescriptionではなく、
enumのdescriptionとなるべき
記述?法:
DF2 en:referEnumOf DF1
このデザインの選択理由?<enum>はRDFのリソースとしては表現していないので、DF間の関係で?す。
20
問題点10/11 Reserved Datafield(予約されたDF)
データ転送に使われないbit範囲は、通常 <reserved/>タグを持つ
datafieldで表現される。
しかし、?由記述でその意図を?すものがある。
解決法
DF1 rdf:type en:reservedDatafield
en:reservedDatafield rdfs:subClassOf en:datafieldclass
<datafield>
<data>undefined</data>
<shortcut>undef</shortcut>
<description>undefined</description>
…
</datafield>
21
問題点10/11 Family Table(系列の表による詳細説明)
http://tools.enocean-alliance.org/EEPViewer/profiles/D2/04/01/D2-04-01.pdf
Or と?われても困る。
記述?法:
D2-04-00/CO2 en:hasScaleMax 2000
D2-04-08/CO2 en:hasScaleMax 5000
D2-04-02/CO2 rdfs:type en:reservedDatafield
22
本来、個別にデバイスタイプの定義を書くべきところを、?つの定義でまとめて記載し、
表により詳細説明している。Scaleの上限値や測定情報の有無が指定されている。
HTMLタグで記載されているものの、解釈の難しさは?由記述に近い。
RDFと変換プログラムの試作
? XML?書の中の参照すべき概念をリソースとして定義
(base.ttl:18932 トリプル)
– EnOceanのXML?書を構造的に参照して作成できるもの。後述の補完情
報を記述するための基本構造として作成。
– デバイスタイプ、Case, Datafieldをリソースとして定義
– 包含関係やクラスを明?
– 名前(shortcut)を持つDatafieldにはラベルを付与
? XML?書を補完する情報(amend.ttl:589トリプル)
内訳(次ページ)
? 変換プログラムを試作し、上記の情報を?いることで、概ね汎?
的変換(Usecase1の下半分)が動作することを確認(テストコード
を含み 約1KL)
-> 本提案の実現性を概ね確認した。
23
?成したトリプル数の内訳
ラベル 説明 主な原因/課題 件数(無ラベル
はDF)
トリプル数
DF Combination 2つのDFを結合して意味の
あるデータになるもの
名前による暗?/ドメ
イン知識への依存
9 36
No Condition Caseを選択する条件が記載
されていない
?由記述への依存 13 (デバイスタ
イプ)
409
Selection あるDFの値によりDFを選択 ドメイン知識への依
存
3 15
Availability あるDFの値で別のDF有効/
無効を?す
ドメイン知識への依
存
8 8
Duplicated Shortcut 名前の重複 品質/不注意 22, 6(名前) 22
Special Meaning エラー等意味のある値を?
由記述で表現
?由記述への依存 10 40
Conditional Scale 他のDFの値にScaleが依存す
るもの
品質 1 12
Type Reference 他タイプを?由記述で参照 ?由記述への依存 1 1
Enum Reference Enumを?由記述で参照 ?由記述への依存 1 2
Reserved DF ?由記述で不使?を表現 ?由記述への依存 1 4
Family Table 表による条件の指定 データモデル記述の
省略
42, 1(表) 42
24
まとめ
? IoTの課題である多様性、相互接続性の課題に対し、プロトコル/ データ
モデルの知識を外部から与えることで変換プログラムの効率的な開発?
保守の実現を検討
? デバイスプロトコルの?種であるEnOceanに注?
(特に多様なEnOcean Equipment ProfileのProfileベース通信に注?)
? デバイスモデルがXMLで形式的に記述されているものの、
– ?由記述への依存
– 定義の省略
– ドメイン知識への依存
などの問題があり、汎?的なデータ変換を?うには情報が不?すること
を確認
? 問題を類別(11種類)し、それを補完するためRDF記述?法を決定
? RDF(18932+589トリプル)と、汎?的変換を?うプログラム(約1KL)を試作
し検証することで、本提案の実現可能性を確認した。
25
(Potential) Future Work
? 網羅的なテストや実デバイスをつなげた検証
(現在は検証?データで動作確認)
? Cloud側向けの変換 (Usecase 1の上半分)
? RDFを使った、XML?書の機械的補正(Usecase 2)
? Datafield名の同?性に関する分析/付け替え
同じ意味のDatafieldだけに同じ名前を付与することで、URIを
直感的に記述でき、意味の解釈でもメリットあり。
? XMLとRDFの使い分け/Best Mix
26

More Related Content

メタデータを用いた贰苍翱肠别补苍プロトコルの汎用変换

  • 2. IoTの課題(多様性/Interoperability)とそれに対す るアプローチ 変換プログラム Device Cloud IoT Service等 課題 ? デバイスの多様性 – デバイスプロトコルは多数ある。 – ?つのデバイスプロトコルの中にも、様々なデバ イス種類がある。 ? サーバ/Cloudのプラットフォームも多様である。(360 種類以上のIoT PFがあると?われる。*1) ? プロトコル/データ変換プログラムの作成が?変。 アプローチ 多様なプロトコルやデータモデルに関する知識をメタデー タとして定義しておき、それを変換プログラムが解釈する ことで、プロトコル/データの変換を?うことで、多様な デバイス、多様なサーバへ対応する。 このようなメタデータが充実し、お互いに繋がることで、 実際のデバイスやデータも繋がってゆく。 IoT GW Device Device Cloud IoT Service等 複数のIoT Service 多種多様な デバイスプロトコル/ デバイス種別 2 デバイス プロトコ ルの知識 サーバプ ロトコル の知識 *1 https://iot-analytics.com/current-state-of-iot-platforms-2016/
  • 3. EnOceanとは ? EnOcean Allianceが標準化する無線ベースのデバイスプロトコ ル ? 省エネルギーが特徴。 – エナジーハーベスティングに対応した機器もある。 スイッチを押した?を使って発電し、通信を?う。 IoTの課題の?つである電源問題を画期的な?法で解決している。 IoTにおいて魅?的なプロトコル/デバイス -> 本提案ではEnOceanに注?する EnOcean Alliance https://www.enocean-alliance.org/ja/ 3
  • 4. EnOceanのデータモデル ? プロトコルの情報がXMLとして形式的に記述されている。 – デバイスタイプ 270種類, 5万6千?、約3MB – 様々な情報が形式的に記載されている -> 変換を?動で汎?的に?えそう。 – 省電?のためか、電?を節約する傾向がある。例: ? 測定値とエラーコードを同じbyteで表現 ? 特定のbit列の値により、 その他のbitの解釈を切り替える仕組み(Case) ? PDFに出?された??等を確認する必要もある。 – ?由記述依存する部分(形式的に書ける場合でも..) – 表記揺れ?間違いと思われる記載、 – 出?の解釈に、EnOceanのドメインの知識を必要とするもの。 – 記載の省略 かなりの情報が形式的に書かれているが、汎?的な変換プログラムを作 るには情報が不?する。 そこで、?間が読み取った情報をRDFで記述し、上記XMLを補完して? いることで、?動的な変換を狙う。 4
  • 5. Use Case 1: 汎?的データ変換 ? 複数のデータモデルに効率的に対応したい。 ? 将来データモデルが追加されても、補?情報を 適切に記載することで、変換プログラム1を変更 することなく対応したい。 ? 将来的には、多様なクラウドにも対応したい。 ? ?旦、技術?依存形式 を経由することで、多対多 のマッピングを、多対1の マッピングとして扱う。 EnOcean Data model (XML) 補?情報 (RDF) 変換プログラム1 EnOcean Device Cloud IoT Service等 変換プログラム2 Device Protocol 依存形式 Cloud IoT Service依存 形式 技術?依 存形式 IoT GW サーバ側知識 5 デバイス側知識 本提案で取り組む領域
  • 6. Use Case 2: Data Model 補正 データモデルの誤り、曖昧性、?由記述への依存を取り除く EnOcean Data model (XML) 補?情報 (RDF) 補正済み EnOcean Data model (XML) 修正プログラム 曖昧性↓ 品質↑ 機械可読性/?動化割合↑ 6
  • 7. EnOceanのうち、対象とするスコープ Profileに応じた データ通信 RPC Teach in EnOcean Equipment Profile(EEP) Generic Profile ココ ?番多様性がある部分に注? 従来からあるプロ ファイル。 270種類のデータ モデルが規定 ?較的新しく作られたプ ロファイル。汎化された ?法でDecode可能 7 デバイスプロファイル の種類 データ通信の分類
  • 8. データモデルの例 温度計(A5-02-16) <datafield> <data>Temperature</data> <shortcut>TMP</shortcut> <description>Temperature (linear)</description> <info>DB_1 Temperature (8 bit) -40...0 °C, linear n=255...0</info> <bitoffs>16</bitoffs> <bitsize>8</bitsize> <range> <min>255</min> <max>0</max> </range> <scale> <min>-40</min> <max>0</max> </scale> <unit> °C</unit> </datafield> 8 エンコードされたデータの値の範囲 物理量に変換した値の範囲 データの格納されている位置 データフィールドのラベル http://tools.enocean-alliance.org/EEPViewer/profiles/A5/02/16/A5-02-16.pdf 線形変換
  • 9. EnOceanデータモデルの主要な概念とRDFでの表現 EnOcean上 の概念 説明 RDF表現での class instanceの命名規約 備考 Type デバイスタイプ en:devicetype en:rr-ff-tt rr, ff, ttは16進数 Case デバイスタイプ毎に1個ま たは複数存在する。条件に より、データの解釈を切り 替えるために?いられる。 en:case en:rr-ff-tt-cc ccはcaseの連番 (16進) Condition Caseを選択する条件 en:condition 空?ノード Datafield 送受信されるbit列に含まれ る、意味のある単位 例?測定値など en:datafield en:rr-ff-tt-cc-nn nnはdatafieldの 連番(16進) shortcut データフィールドの名前 ?字列Literal ?字列Literal Scale ビットで表現される値を、 物理的な量としてどの範囲 にあたるかを、min,maxで 記載したもの。 数値Literal 数値Literal Bitで表現される 値から線形変換 で写像される値 域 9
  • 10. ?動処理を阻害する問題点?覧 ラベル 説明 原因など 件数(DF数など) DF Combination 2つのDFを結合して意味の あるデータになるもの 名前による暗?/ドメ イン知識への依存 9 No Condition Caseを選択する条件が記載 されていない ?由記述への依存 13 (デバイスタ イプ) Selection あるDFの値によりDFを選択 ドメイン知識への依 存 3 Availability あるDFの値で別のDF有効/ 無効を?す ドメイン知識への依 存 8 Duplicated Shortcut 名前の重複 品質/不注意 22, 6(名前) Special Meaning エラー等意味のある値を? 由記述で表現 ?由記述への依存 10 Conditional Scale 他のDFの値にScaleが依存す るもの 品質/省略 1 Type Reference 他タイプを?由記述で参照 ?由記述への依存 1 Enum Reference Enumを?由記述で参照 ?由記述への依存 1 Reserved DF ?由記述で不使?を表現 ?由記述への依存 1 Family Table 表による条件の指定 データモデル記述の 省略 42, 1(表) 10
  • 11. 問題点1/11 DF Combination (2つのDFの組合せ) 定義上は2つのDatafieldとなっているが、意味のある値にするには、結合してから評 価すべきもの。(離れたbit列を利?しているため2つのDatafieldになっている) それぞれを別々の値として送られても困る。(解釈にドメイン知識が必要) 例: A5-13-06/LAT(MSB) 0-3bit : 1111 A5-13-06/LAT(LSB) 8-15bit : 00000000 結合した 111100000000 が意味のある値になる。 MSB(Most Significant byte), LSB(Least Significant Byte) という名前で暗?しているとも?える。 MC-LSB 空? ノード MC-MSB rdf:_1 rdfs:label Combination Field rdf:seq subclassof rdf:type “MC” rdf:_2 11 記述?法 DF, Caseクラス その他 凡例
  • 12. 問題点2/11 No condition (条件の記載ないもの) caseが複数ある場合は、通常、case内にconditionタグがあり、そのcaseが選択され るときの、条件(参照する場所と値)が記載されている。しかし、このconditionが記載 されていないものが10件程度ある。ただし、?由記述蘭やPDF仕様により判断可能。 Case1 空?ノー ド en:isSelectedBy en:hasBitSize en:hasBitoffset Condition rdf:type Case rdf:type 2 28 3 2つのデバイスタイプでは、Conditionが複数のDatafieldを参照している。この場合 caseに複数のconditionを紐づけてAND条件と解釈することとする。 (デバイスタイプ 例:D2-31-00) *1 FieldTypeのsubclassのdatafieldtype, statusfield, directionのどれかを指す。 *2 valueか、hasMin,hasMaxのペアを持つかどちらか。(?致判定か、範囲判定か) rdf:value en:referingType FieldType *1 1 3 en:hasMin en:hasMax *2 12 記述?法 DF, Caseクラス その他 凡例
  • 13. 問題点3/11 Selection (DFの選択) あるデータフィールドの値により、どちらのデータフィールドが有効かを? す。(例: A5-06-01) ? データフィールド ILL1: 照度センサの値1 (600 – 60,000 lx) ? データフィールド ILL2: 照度センサの値2 (300 – 30,000 lx) ? データフィールド RS: ILL1/ILL2どちらが有効かを?す ILL1: 32,000 ILL2: 30,000 RS: 0 ILL: 32,000改良 課題2:有効な?だ け送る?が扱いや すい 課題3:有効な?だ け送れば不要 課題1:解釈するのにEnOceanの知識が必要 解釈にEnOceanの知識が不要 名称を固定 課題4:場合により 名称が、ILL1/ILL2 と変わる 13
  • 15. 問題点4/11 Availability(DFの有効性の提?) あるデータフィールドの値により、別のデータフィールドの有効性を?す物がある。 (例: A5-04-01) ? データフィールド TMP: 温度センサの値 ? 湿度センサの値 HUM: 湿度センサの値 ? データフィールド TSN: 温度センサの有無(有効性)を?す TMP: 20 HUM: 70 TSN: 0 HUM: 70 TMP: 20 HUM: 70 ないとき あるとき 改良 課題2:ある時だけ 送ってくれた?が わかりやすい 課題3:ある時だけ 送れば不要 課題1: 解釈にEnOceanの知識が必要 解釈にEnOceanの知識が不要 記述?法: A5-04-01/TSN en:indicatesAvailabilityOf A5-04-01/TMP 15
  • 16. 問題点5/11 Duplicated Shortcut(名前の重複) ほとんどのデバイスタイプでは重複しないようにされているが、重なるものがいくつかある。 ?間にわかりやすいラベルとして提供されていると考えられるが、重複していてはIDとしては 利?できない。 記述?法 DF1(VSPの2個?) skos:prefLabel “VSP2” 同名のshortcutのデータフィールドに対し、連番のついた(VSP1, VSP2)をprefLabel で?す。 DatafieldのURIとしては、caseの連番、Datafieldの連番を付与して表現することとした。 en:rr-ff-tt-cc-nn TYPE名 + CASE名+ prefLabel(ない場合はlabel) shortcut名? を識別?として?いることも できる。また、TYPE名 + prefLabelを準識別?として使える可能性もある。 本資料では、分かりやすさの点からこの名称を?いている部分もある。 A5-20-02/VSP 2回 A5-20-12/FANOR 2回 A5-3F-00/RSLV 4回 A5-3F-7F/undef 2回 D2-14-30/SMA 6回 D2-14-31/COA 6回 16
  • 17. 問題点6/11 Special Meaning(特別な意味の値 ) 値の?部にエラーなどの特別な意味があり、測定値として扱ってはいけないもの。こ の情報が?由記述として記載されている。 (例: A5-06-03/ILL) <description>Illumination (linear) <br/>DB2 = 8 MSB, DB1 = 2 LSB <br/>1001: over range, 1002...1024: reserved </description> RS 空?Node en:hasMeaning rdf:value rdfs:label meaning Indicator rdf:type Data field rdf:type 1001 “over range” 17 記述?法 DF, Caseクラス その他 凡例
  • 18. 問題点7/11 Conditional Scale (他のDatafieldに依存するscale) http://tools.enocean-alliance.org/EEPViewer/profiles/A5/20/04/A5-20-04.pdf <scale> <min>20 .. 80</min> <max>10 .. 30</max> </scale> 全体を読むと次の意図であることがわかる。 TSの値が0のとき、scale min=20, scale max=80 TSの値が1のとき、scale min=10, scale max=30 ?由記述に依存する。しかも?由記述すべきでない場所に記載されている。 scalerangeshortcutoffset size 記述?法 FTS en:referScaleOf TS TS en:hasConditionalScale [ a ConditionalScale; value 0; en:hasScaleMin 20; en:hasScaleMax 80 ] . TS en:hasConditionalScale [ a ConditionalScale; value 1; en:hasScaleMin 10; en:hasScaleMax 30 ] . A5-20-04 18
  • 20. 問題点9/11 Enum Reference (Enumの参照) ?由記述として、参照を記載 例?A5-3F-00/RSLV <datafield> … <enum> <item> <value/> <description>See prev</description> </item> </enum> <datafield> .. <enum> <item> <value>0x00</value> <description>not supported</description> </item> <item> <value>0x01</value> <description>≥ -31</description> <unit>dBm</unit> </item> .. </enum> PDFに出?する?的であれば同じ表を 何度も掲載したくない事も理解でき る。 論理的にはitemのdescriptionではなく、 enumのdescriptionとなるべき 記述?法: DF2 en:referEnumOf DF1 このデザインの選択理由?<enum>はRDFのリソースとしては表現していないので、DF間の関係で?す。 20
  • 21. 問題点10/11 Reserved Datafield(予約されたDF) データ転送に使われないbit範囲は、通常 <reserved/>タグを持つ datafieldで表現される。 しかし、?由記述でその意図を?すものがある。 解決法 DF1 rdf:type en:reservedDatafield en:reservedDatafield rdfs:subClassOf en:datafieldclass <datafield> <data>undefined</data> <shortcut>undef</shortcut> <description>undefined</description> … </datafield> 21
  • 22. 問題点10/11 Family Table(系列の表による詳細説明) http://tools.enocean-alliance.org/EEPViewer/profiles/D2/04/01/D2-04-01.pdf Or と?われても困る。 記述?法: D2-04-00/CO2 en:hasScaleMax 2000 D2-04-08/CO2 en:hasScaleMax 5000 D2-04-02/CO2 rdfs:type en:reservedDatafield 22 本来、個別にデバイスタイプの定義を書くべきところを、?つの定義でまとめて記載し、 表により詳細説明している。Scaleの上限値や測定情報の有無が指定されている。 HTMLタグで記載されているものの、解釈の難しさは?由記述に近い。
  • 23. RDFと変換プログラムの試作 ? XML?書の中の参照すべき概念をリソースとして定義 (base.ttl:18932 トリプル) – EnOceanのXML?書を構造的に参照して作成できるもの。後述の補完情 報を記述するための基本構造として作成。 – デバイスタイプ、Case, Datafieldをリソースとして定義 – 包含関係やクラスを明? – 名前(shortcut)を持つDatafieldにはラベルを付与 ? XML?書を補完する情報(amend.ttl:589トリプル) 内訳(次ページ) ? 変換プログラムを試作し、上記の情報を?いることで、概ね汎? 的変換(Usecase1の下半分)が動作することを確認(テストコード を含み 約1KL) -> 本提案の実現性を概ね確認した。 23
  • 24. ?成したトリプル数の内訳 ラベル 説明 主な原因/課題 件数(無ラベル はDF) トリプル数 DF Combination 2つのDFを結合して意味の あるデータになるもの 名前による暗?/ドメ イン知識への依存 9 36 No Condition Caseを選択する条件が記載 されていない ?由記述への依存 13 (デバイスタ イプ) 409 Selection あるDFの値によりDFを選択 ドメイン知識への依 存 3 15 Availability あるDFの値で別のDF有効/ 無効を?す ドメイン知識への依 存 8 8 Duplicated Shortcut 名前の重複 品質/不注意 22, 6(名前) 22 Special Meaning エラー等意味のある値を? 由記述で表現 ?由記述への依存 10 40 Conditional Scale 他のDFの値にScaleが依存す るもの 品質 1 12 Type Reference 他タイプを?由記述で参照 ?由記述への依存 1 1 Enum Reference Enumを?由記述で参照 ?由記述への依存 1 2 Reserved DF ?由記述で不使?を表現 ?由記述への依存 1 4 Family Table 表による条件の指定 データモデル記述の 省略 42, 1(表) 42 24
  • 25. まとめ ? IoTの課題である多様性、相互接続性の課題に対し、プロトコル/ データ モデルの知識を外部から与えることで変換プログラムの効率的な開発? 保守の実現を検討 ? デバイスプロトコルの?種であるEnOceanに注? (特に多様なEnOcean Equipment ProfileのProfileベース通信に注?) ? デバイスモデルがXMLで形式的に記述されているものの、 – ?由記述への依存 – 定義の省略 – ドメイン知識への依存 などの問題があり、汎?的なデータ変換を?うには情報が不?すること を確認 ? 問題を類別(11種類)し、それを補完するためRDF記述?法を決定 ? RDF(18932+589トリプル)と、汎?的変換を?うプログラム(約1KL)を試作 し検証することで、本提案の実現可能性を確認した。 25
  • 26. (Potential) Future Work ? 網羅的なテストや実デバイスをつなげた検証 (現在は検証?データで動作確認) ? Cloud側向けの変換 (Usecase 1の上半分) ? RDFを使った、XML?書の機械的補正(Usecase 2) ? Datafield名の同?性に関する分析/付け替え 同じ意味のDatafieldだけに同じ名前を付与することで、URIを 直感的に記述でき、意味の解釈でもメリットあり。 ? XMLとRDFの使い分け/Best Mix 26