TS2014u2

(1)

TRONSHOW2O14

u2

uIDアーキテクチャ2.0

坂村健

東京大学情報学環ユビキタス情報社会基盤研究センター長、教授

YRPユビキタス・ネットワーキング研究所長

T-Engineフォーラム／uIDセンター代表

(2)

TRONSHOW2O14

①

IoTのモデル

(3)

Big Data

Input

Webサービスのモデル

Output

スマートフォン/情報家電

表示、音声、アドバイス、サービス

(4)

TRONSHOW2O14

Big Data

Input

Webサービス+IoTのトータルモデル

Real World

Output

測定データ、ID読み取り、運転データ

制御データ、メンテナンスデータ

組込みシステム

スマートフォン/情報家電

(5)

ビッグデータ

を

集める

世界からのインプット

組込みセンサーノードなどからのデータ

組込み機器からの動作データ

スマートフォンからの操作、撮影、音声、コメント、メッセージ



(6)

TRONSHOW2O14

ビッグデータ

を

使う

世界へのアウトプット

ビッグデータ解析から機器の効率的制御を

ビッグデータ解析から機器の故障予測を

それらによりメンテナンスや運転効率化へ

人間に対し表示や音声でアドバイスやサービスを

(7)

①

(8)

TRONSHOW2O14

「ユビキタスコンピューティング」

の

本質

コンピュータ／ネットワークが

…

人間の生活空間の「状況」を認識すること

• モノや人の位置と空間情報

• モノや人の属性情報

• 各種センサーのリードアウト

“Context Awareness”「状況認識」



(9)

状況認識とは

● コンピュータが自動的に現実の世界を「認識」す

ること



これは何か？



この部屋にはだれがいる？



この人は目が不自由か？



この機器はどこにある？



よく連絡をとる相手は？

● 認識の基本は識別＝



(10)

TRONSHOW2O14

識別すべきすべてのモノに

個体識別番号

を

振る

さらに現実を構成するのは

物品、場所といった物理的実体だけではない

それらの概念的存在にも識別番号を振る

• たとえば会社組織、たとえばロットという集合…



(11)

それ

が

ucode

128bitのucode

• オープンでユニバーサルなネットワーク中で特定できる

• 世界で唯一のユニーク識別番号

(12)

TRONSHOW2O14

意味

は

ネットワーク外部化

注）ここでは経済の分野の「ネットワーク外部性」とは別

の意味で使っている

(13)

ネットワーク外部化することのメリット

● 応用が必要とするだけの解像度を得られる



単なるビルの住所でなく、必要なら中のオフィスの特定の棚まで

識別できる

● 応用する人が必要に応じ発行できる自由度



現場で発行も可能

● さらに誰が発行しても、発行後にオープンにし、皆

で使うようにもできる開放性



(14)

TRONSHOW2O14

ユビキタス

IDアーキテクチャのコンセプト

(15)

②

(16)

TRONSHOW2O14

なぜ「名前」でなく「番号」なのか？

● コンピュータにとっては「番号」の方が自然



人間は大きな桁数の「番号」を扱うのが不得意なので「名前」使

う

● 「番号」なら世界で唯一無二の特定ができる



同じ「名前」で、別のモノはたくさんある



「名前」では大量に同類があるモノの一つを特定できない



固有名詞を他の言語に翻訳すると曖昧さが増える

(17)

なぜ「名前」でなく「番号」なのか？

● 「番号」なら唯一無二性さえ保障すれば、特定の

権威を必要とせずに付けられる



「名前」で特定するには、誰が「名前」を付けるかという「権威」が

必要



ある「名前」がふさわしいモノが複数あったとき誰が決めるか



それに対して全世界で合意できるか

● 単に唯一無二なだけの番号なら管理構造が不

要



URLや住所など、階層的に名前を連ねて特定する方式は管理

(18)

TRONSHOW2O14

ucodeの社会的

な

意義

オープンデータ時代の「無形の公共財」

意味を持たない一意性の保証だけであることが重要

(19)

グーローバルな一意性が重要

● 世界は「オープン」システムを指向している



オープンデータからオープンデータまで

…



IoTも巨大なオープンシステムとみなすことができる

● オープンシステムでは一般性のあるルールが、

データ、サービス間の相互運用性のために重要



例えばスマートハウスを考えても、家の中で一社の家電のみ使う

ことは考えられない



それらを指定するためのグローバルな一意識別子が必要

● システム間でオブジェクトや概念を指定するため



(20)

TRONSHOW2O14

将来的には

…

メタデータのレリジエンス

の

基礎として

社会がメタデータのネットワークで表現された時の識別子

の永続性の保証が必要

• メーカーの型式番号など特定の組織（ドメイン）に依存する識別子

は、その元の組織が消滅した時はより公共的なデータベースに引

き継がれるべき

• 異なるデータベースのマージ問題を考えるとき、ドメインでの意味

を引きずる識別子は好ましくない

(21)

ITU（国際電気通信連合）の国際標準化

● _{ITU-T F.771 (2008)}

応用及び要件定義

● _{ITU-T H.621 (2008)}

システム・アーキテクチャ

● _{ITU-T H.642.1 (2012)}

ID体系

● _{ITU-T H.642.2 (2012)}

ID登録・管理の手順

●

(22)

TRONSHOW2O14

IETFにおける国際標準化

● _{RFC 6588}

“A URN Namespace for ucode”



urn:ucode:_0123456789ABCDEF012345

6789ABCDEF

という標記形式が国際標準化された

● _{URIを用いる場面全般で}

ucodeが利用可能



NFC (Near Field Communication) カードの

NDEF形式



RDF (Resource Description Format)にお

けるID形式

(23)

ucodeの応用

● 組織を超えた唯一性を活かした

多様な応用実績



超長期優良住宅の住宅登録サービス

((財)ベターリビング)



競走馬の血統・飼育・移動管理

((財)日本軽種馬登録協会)



医薬品トレーサビリティシステム (ベネシス)



インテリジェント基準点 (国土地理院)

(24)

TRONSHOW2O14

(25)

ucode関連研究

● 国内・海外を含め、基盤・応用の両面か

ら幅広い研究が進められてきた



東京ユビキタス計画・ココシル

• ucodeによる場所情報基盤プラットフォームの構築



情報流通連携基盤 (UNL/UCT)

• ucodeに基づくオープンデータプラットフォームの構築



IoT-A Project (EU FP7)

• Led by VTT, EIT ICTLab, etc.

(26)

TRONSHOW2O14

③

(27)

ucode関係モデル（概要）

● 実世界にある個々の事物から関係をたどって情報を

取得する情報サービスを提供するために

● _{識別したいものに個別の識別子（ucode）を割付}



ucodeはITU国際標準

● _{実世界(および仮想世界)をモデル化する}



ucodeモデルは、言わば現実世界をデジタル化して切り取るための

フレームワーク

● それを利用して、人間の意識的入力を最小限にとど

めて最適制御するのが「ユビキタス・コンピューティン



(28)

TRONSHOW2O14

ucode関係モデル（定義）

● 定義



実世界の識別したいモノ・場所・概念に関する情報を

_…



モノ・場所・概念に振られたucode同士またはucodeと文字列等

のデータ（atomという）の間の関係表現（３項表現＝Triple）として

モデル化することで

_…



実世界のコンテキストを表現するモデル

● _{ucR = ucode Relation}



ucRモデルそのもの，またはucRモデルに基づく表現を単にucR

ということがある (informal)

(29)

ucRの例(物品)

ucode

₁

ucode

₂

ucode

3 contains

ucode

₁

ucode

4 “Bufferin”

is named as

ucode

₂

12 pieces of

Bufferin Carton

(30)

TRONSHOW2O14

ucRの例(場所)

ucode

₁

ucode

2 ucode

3 ucode

₁

ucode

₂

ucode

₂

ucode

₃

ucode

₄

is close to

ucode

₅

is near

(31)

ucRの例: ユニットと部品

u

_A

入っている

A型エンジン

u

_B

u

_B

名前

u

_C

生産地

日付

2007/07/19出荷

○○発動機

△△農機

〇〇発動機

u

_B

u

_D

ユニットの出荷

u

_B

u

₁

u

₁

u

₂

u

₂

u

₃

u

₄

u

₃

u

₄

△△農機

(32)

TRONSHOW2O14

ポイント

● _{ucodeを使うことでメーカーの枠を超え、対象の種別}

の枠を超え同一の体系で同定できる

● _{ucodeは再利用しないので、常に「一物一値」}

● _{ucodeはメーカー工場でなく現場でも、また関係する}

業者のだれでもが必要に応じ発行できる

● _{個々のucodeから、誰が、どのような情報を引き出せ}

るかは提供者側でアクセスコントロールが可能



メーカーのメンテナンス要員なら設計図まで呼び出せるが、多の人で

は何の部品かもわからないが、とにかく「そのプラントに組み込まれて

いる」とことだけ、単に「どこかで使われている」ことだけを返すようにも

できる

(33)

ポイント

● タグ非依存で識別対象のコストや重要度に応じ

て様々なタグを利用出来る



小型の低価格部品にはQRコードのシール



小型の高価格部品にはQRコードのレーザー刻印



それらをまとめたユニットには低価格の金属対応RFIDタグ

• 数がまとまれば100円程度で提供可能なものもある



ユニットにより構成されたプラントには電波マーカー

_…など

(34)

TRONSHOW2O14

ucodeの哲学的

な

意義

「例示による定義」が基本コンセプト

• ucRは現実の存在自体を基礎にする

現実に存在する物品や場所に付与されたucodeが基盤

関係などの抽象概念を現実から遡及的に定義

• 事前に決められた語彙辞書を必要としない

(35)

RDFの限界とucR

抽象概念

ucR：現実から抽象を定義

RDF：抽象で現実を説明

http://www.example,org/stationid/85740

http:// www.example,org/stationid/85739

Shinagawa

Osaki

http://www.example.org/terms/name

http://www.example.org/terms/nextst

(36)

TRONSHOW2O14

ucR

と

RDF

ucRはウェブ内のリソースを示すURIの代わりに

ucodeを使えるように拡張したRDF

現実のモデル化において

語彙辞書を必要とする

RDFをucRで補完

(37)

uIDアーキテクチャとSmart-M3(VTT)

● _{uIDとSmart-M3を組み合わせる}



グローバル一意識別子＋意味操作

SIB: Semantic Information Broker

KP: Knowledge Processor

(38)

TRONSHOW2O14

④

(39)

TRONプロジェクト

の

「

2.0化」

IoTの実現が見えてきた状況へ対応するため

1. 技術の進歩

2. 環境の変化

3. 要求の進歩



(40)

TRONSHOW2O14

1. 技術の進歩

大規模データ分散処理技術

• Mapreduce, Hadoop等の、大規模データ分散処理技術が

オープンになり使えるようになった

オープンデータ系プロトコルの事実上の標準化

• REST, CoAP, JSON等の利用が標準的に

(41)

2. 環境の変化

クラウド、マッシュアップ、オープン

によるサービス構築の一般化

• 多様な他者のサービスを利用して新しいサービスを作る時

代

スタートアップ環境が整ってきた

(42)

TRONSHOW2O14

3. 要求の追加

オープンデータ連携からの要求

• インターネット上のオープンな巨大データ集積が増え

それらを自動連携させる枠組みがこれからの課題になる

ビッグデータ利用からの要求

• 交通実証やビッグデータ連携などにより

刻々変わるストリーム型の状況情報への対応が必要に

(43)

ストリーム型の状況情報の例

● 駅の位置

{駅uc

₅

, 関係uc

₆

, 地理座標}

● 路線と駅の関係

{区間F064, 関係uc

₇

,駅102}

{区間F064, 関係uc

₇

,駅103}

{駅102, 関係uc

₆

, 35.627163, 139.722698}

動的状況を重ねることで…

静的状況と…

(44)

TRONSHOW2O14

「

u1」

の

総括の上で

モデル研究プロジェクトとしての

u1

• u1でIoTのための統一されたデータ表現の情報モデルを確立

グローバルにオブジェクト／概念を識別するためのucode

データの共通表現のためのucR （ucode Reration）

u1の考えに基づいた実用的な実装を

• 現在の技術に基づいて

(45)

IoT実現への課題

● _{IoT実現のための多くの課題}

1. ユビキタスIDサービスの安定性

• 高負荷時の性能維持、24時間/週7日の信頼性

2. 計算の複雑性とパフォーマンス

• 部分グラフマッチングのNP困難性、...

3. 管理の複雑さ

• 数十億のucodeを管理する方法

4. 敵対行動に対する保護

• 悪意のある第三者からのDDoS攻撃

● これらの実用にあたっての課題を解決することを



(46)

TRONSHOW2O14

④-1

(47)

uIDサービスの安定性

● 使った実装



IaaS (Infrastructure as a Service) 、

OpenStack、ロードバランサの導入、...

• Amazon EC2やGoogle Compute Engineの利用...

● _{u2サービスは、IaaSのサービス上で実現}



現在u2WGメンバーにリリース

(48)

TRONSHOW2O14

④-2

(49)

計算複雑性とパフォーマンス

● 大規模グラフデータベースは、本質的に計算困

難である



「計算複雑性理論」から知られている

• 部分グラフ同型問題のNP完全性のため、グラフ・クエリはNP困難

Intractable

(cannot be solved efficiently for large data)

Tractable

(can be solved efficiently)

計算量クラス階層

EXPSPACE

EXPTIME

PSPACE

NP

P

NL

(50)

TRONSHOW2O14

クエリに対する制限

● _{実用のために設計されたのがu2}



u1のモデルに基づいているが、u2の目的は実用的なIoT情報フレー

ムワークを実現すること



この計算複雑性とパフォーマンス問題を解決する必要がある

● _{u2は、この問題に対する新たなソリューションを提供}



u2では、ucRグラフとクエリはいくつかの条件を満たすように制限され

ている

• ucRグラフは語彙定義の制限がある（例えば「含んでいる」という述語は、ツ

リー構造でなければならない）

• クエリでは任意の語彙集合にマッチするワイルドカードを述語として持てない



これらの現実的制限によりucRモデルに基づいた実践的かつ十分に

柔軟なIoT情報フレームワークを実現することが可能となる

(51)

u2

の

基本コンセプト

多様な

DBのAPIに対するクロスクエリを

組織や

DB構成を超えて行える情報連携基盤

• その中でucRネイティブのDBはリクエストが確定できない複

雑な関係処理の考えられるデータ群を扱うものとする

(52)

TRONSHOW2O14

既存の

DBMSの利用

● 定型的で制約ある関係でまとまったデータ群は、そ

のスキーマに適した既存のDBMSに接続する



定型的で制約ある関係の語彙のグループをDBのドメインに相当させ

る



既存のDBMSを簡単なラッピングで仮想的なucR DBとしてシステム

に統合できるようにする



KVSによるDBやGISなど、本来のucRと性質の違うスキーマの確定さ

れたDBも、この仮想的なucR DB化により統合する

● これによりデータの種類や問題に適したアルゴリズ

ム・データ構造を効率よく扱えるようにする



「現在位置から1km以内にあるコンビニを検索」

→ GIS: R木 (R-tree)を利用



「大量のセンサデータを扱う」

→ KVS: 分散ハッシュテーブル(DHT)を利用



(53)

u2

RDB

クエリ分解・レスポンス統合による

クロスクエリ

KVS

RDF

ucR

RDB

KVS

Query

Decomposition

GIS

Response

Reconstruction

Mobile Application

ucR Response

ucR Query

(54)

TRONSHOW2O14

ucode

RP

2.0 ucode解決プロトコル2.0

IoTの実現に必要な情報を集約・統合するための

プロトコル

• ucR (ucode relation)モデルに基づくオープンモデルによる

組織を超えたデータ連携を意図した設計

既存のRDBやKVS等のデータベースを統合し、クロスクエリを可能にする仕組み

(55)

ucode解決プロトコル2.0

● _{ucode Resolution Protocol ver.2はREST/CoAP,}

REST/HTTP, JSONを前提にする

● _{DBのドメインに相当する語彙グループに属するucR}

クエリをサブクエリとして分解し処理する



解決サーバがucRクエリを受信すると、それを解釈し、必要な語彙グ

ループ単位に分割して、対応するラッパー「uCRアダプタ」に向けて分

割したサブクエリを発行する

● 分散データベース構成を実現する



ucR解決サーバフロントエンドは分散データベース構成で、対応する

DBのドメインが不明な語彙は、より上位の解決サーバに送り解決結

果を待つというカスケード動作を行う



データ秘匿等の要請もあり、ローカルなucode解決フロントエンドサー

(56)

TRONSHOW2O14

ucodeRP2.0の動作

uID Center

ロードバランサ

ucR解決サーバ

フロントエンド群

利用者

(1) ucodeRP2.0

によるクエリ

会社Aのサーバ

RDBMS

ucR Adaptor

組織Bのサーバ

ucR Database

(Triple-Based)

(2) 分解した

サブクエリX

(2) 分解した

サブクエリA

(2) 分解した

サブクエリB

(3) サブクエリ

の結果

(4) サブクエリ

の結果をjoinし、

オリジナルの

クエリの結果を返答

アプリケーション

……

(57)

④-3

(58)

TRONSHOW2O14

大量の

ucodeの扱い

● _{数十億、数兆のucodeどのように管理するか}



ucodeは再利用されないのが原則

• このため管理は、多くの場合容易

• 失効したucodeのデータは、データの他の部分に影響を与えることなく、

データベースから除去することができる

● _{u2ではucode管理のための基本的なソリューショ}

ンを提供



登録時に基本情報を定義するための「本籍ucRデータサービス」

は、u2のサービスフレームワークに含まれる

• 例えば、所有者情報、コンテキストアウェアしたアクセス制御情報等



新しいucodeを発行を容易にするためのREST APIの提供



(59)

④-4

(60)

TRONSHOW2O14

敵対行動に対する保護

● _{オープンなIoT上で実用サービスを実現するため}

には、避けては通れないのが認証とアクセス制御



例1: 家電の制御は、家に住む人とその場にいる人だけに許可し

たい



例2: 健康や障碍に関する情報は、特定のサービス(ココシル・バリ

アフリーナビ)のみにアクセスを許可したい

● _{OpenIDの三者間認証モデルに、}

Context-Based RBACを組み合わせたプラット

フォームを実現



軽量性の要求されるIoTノード・6LBRのための認証・アクセス制

御プラットフォームと合わせて、全体的な実現を進めている



(61)

DareSil（ダレシル）

u2ベースのIoTノードやIoTサービスのための

認証・アクセス制御のためのプラットフォーム

(62)

TRONSHOW2O14

アーキテクチャのレイヤ

● _{アプリケーション層（SaaS相当）}



エンドユーザに提供される個々の具体的にまとまったサービス



コンテンツや語彙のセット、個々のサービスに特化したアプリケー

ションよりなる

● _{プラットホーム層（PaaS相当）}



場所、物品、コンテンツ等の対象分野に特化した機能・語彙群を

提供し、uIDセンターを介して多様なデータ群に対する効率的な

クロスクエリを行うAPIを提供する



ucodeのオリジナルの登録定義である「本籍データ」を対象分野

に応じて属性規定し管理する

● _{インフラ層（IaaS相当）}



ucodeRP2.0解決の実現を行い、適切なデータを返す

(63)

(64)

TRONSHOW2O14

5つの基本プラットホーム

● ココシル



場所、場所同士の関係を管理するプラットホーム



GIS等既存の場所情報システムや地図サービス等との連携も受け持つ



場所情報、センサーネットワークアプリケーションなどのプラットホームとなる

● モノシル



物品、物品同士の関係を管理するプラットホーム



ISBN等既存の物品認識サービス等との連携も受け持つ



複数の企業にまたがるトレーサビリティ、物流管理、製造管理アプリケーションなどのプラットホームとなる

● コトシル



コンテンツを管理するプラットホーム



Wikipedia、Twitter等既存のコンテンツサイト等との連携も受け持つ



ucR利用コンテンツ・アプリとして、ココシルと連動するガイドブックやモノシルと連動するカタログなども考えられる



逆にココシル側から場所のコンテンツを呼び出すなどの連携もあり、他の分野のアプリケーションから利用される

● ダレシル



ユーザ、ユーザ同士、組織等とそれらの関係を管理するプラットホーム



既存のSNS等とのOauth認証連携も受け持つ



ユーザ管理、アクセス管理のために他の分野のアプリケーションから利用される

● カチシル



有償サービスのためのアカウント管理を行う他の分野のアプリケーションから利用される



既存のクレジット等の口座との連携も受け持つ

(65)

⑤-1

u2によるIoTの実現へ

(66)

TRONSHOW2O14

データガバナンス

の

ための

u2

オープンデータの情報連携基盤に

多様な

DB群に対するクロスクエリを

組織や

DB構成を超えて行える情報連携基盤

• アプリからの標準的なucRクエリを受けサブクエリに分解し

リンク先のDBMSへ送り、戻ってくるそのレスポンスを統合し

て

標準的なucRレスポンスとしてアプリに戻す

(67)

u2

RDB

オープンデータの

情報連携基盤として

KVS

RDF

ucR

RDB

KVS

Query

Decomposition

GIS

Response

Reconstruction

Mobile Application

ucR Response

ucR Query

(68)

TRONSHOW2O14

オープンデータと

u2の可能性

● 今後多くのオープンデータが提供されるように

● それらの連携が問題に



例えばある地域にあるセンサーすべての値の平均を知りたい時



オープンなGISにより当該地域の建物のリストを得て…



その建物ごとにセンサーAPIを叩きデータを得て蓄積し、すべての答

えが帰るまで多重に待ち受け、すべての回答が来た時点でそれを統

計処理



などの動作は、資源の限られたモバイル・アプリからの実行は困難

● _{u2により標準的なクエリだけで、複数のクロスクエリ}

からそのレスポンス統合まで実現できるなら

…

● より多くの多様なアプリが可能に

(69)

⑤-2

u2によるIoTの実現へ

(70)

TRONSHOW2O14

₇₀

ネットワーク

の

高速化、

低コスト化、常時接続化

家電機器はクラウドと接続するのが常態化

• 例えば家庭内の電力利用統計は全電化製品がクラウドにつ

ながることにより、容易に算出できるようになってきた

IoTのモデルの「クラウドと実世界を繋ぐモノ」としての

組込みに

(71)

組込み機器の

オープン

API化による

機能

の

アンバンドル化

データ処理はクラウドに

UIはスマートフォンに

組込みは専門機能に特化

(72)

TRONSHOW2O14

制御ガバナンス

の

ための

u2

アクセスコントロールの上部構造に

情報の集約・状況認識

機器や情報のアクセス制御

(73)

システムのオープン

API

に

対するアクセスパターン

Web経由型

• システムの提供するAPIにアクセス

• メーカー各社の提供するコントロール用Webサイト経由で機器にア

クセス

ローカル直接型

(74)

TRONSHOW2O14

アクセスコントロールを

u2で一本化することで

● _Web経由型



WebサイトへOpenID型の認証代行とAPIのラッピング



一般性のある語彙でアクセスすることで、個々の機器の独自API

に変換するため、複数のメーカーの異なるAPIを連携させての統

合性ぎをが可能に

● ローカル直接型



アクセスキーの取得・保持とAPIのラッピングをu2で実現



アクセスキーはユーザのアプリ側には露出しないので、組込み側

はアクセスキーのみで複雑なアクセスコントロールを行う必要はな

い



(75)

u2

A社製

オープン

APIのアクセスコントロール

基盤として

D社製

監視カメラ

ucR

A社製

ビデオ

D社製

自動ロック

Command

Decomposition

B社製

テレビ

C社Web

Response

Reconstruction

Mobile Application

ucR Response

ucR Command

E社Web

サイト

(76)

TRONSHOW2O14

オープン・アクセス

の

基盤としての

u2へ

情報の集約・状況認識



ucode解決プロトコル(ucodeRP) 2.0

機器や情報のアクセス制御



ダレシル

(Daresil)プラットフォーム

(77)

さらに将来的には

…

自己組織的

な

世界記述のために

ビッグデータから述語の自動生成へ

• 統計的にAとBに関係があるとわかる時代には処理効率化のためにそ

の関係専用の述語－－データベースドメインを自動生成することが望

まれるだろう

現場で自動生成される「何か」にも気軽に識別子が発行できる

TS2014u2

TRONSHOW2O14

u2

uIDアーキテクチャ2.0

坂村 健

東京大学情報学環ユビキタス情報社会基盤研究センター長、教授

YRPユビキタス・ネットワーキング研究所長

T-Engineフォーラム／uIDセンター代表

TRONSHOW2O14

①

IoTのモデル

Big Data

Input

Webサービスのモデル

Output

スマートフォン/情報家電

表示、音声、アドバイス、サービス

TRONSHOW2O14

Big Data

Input

Webサービス+IoTのトータルモデル

Real World

Output

測定データ、ID読み取り、運転データ

制御データ、メンテナンスデータ

組込みシステム

スマートフォン/情報家電

ビッグデータ

を

集める

世界からのインプット

組込みセンサーノードなどからのデータ

組込み機器からの動作データ

スマートフォンからの操作、撮影、音声、コメント、メッセージ



TRONSHOW2O14

ビッグデータ

を

使う

世界へのアウトプット

ビッグデータ解析から機器の効率的制御を

ビッグデータ解析から機器の故障予測を

それらによりメンテナンスや運転効率化へ

人間に対し表示や音声でアドバイスやサービスを

①

TRONSHOW2O14

「ユビキタスコンピューティング」

の

本質

コンピュータ／ネットワークが

…

人間の生活空間の「状況」を認識すること

• モノや人の位置と空間情報

• モノや人の属性情報

• 各種センサーのリードアウト

“Context Awareness”「状況認識」



状況認識とは

●

コンピュータが自動的に現実の世界を「認識」す

ること



これは何か？



この部屋にはだれがいる？



この人は目が不自由か？



この機器はどこにある？



よく連絡をとる相手は？

●

認識の基本は識別＝



TRONSHOW2O14

識別すべきすべてのモノに

個体識別番号

を

振る

さらに現実を構成するのは

坂村健