ソフトウエアジャパン2017　IT Forum AITC(6)

Copyright © 2015 Advanced IT Consortium to Evaluate, Apply and Drive All Rights Reserved.

空間 OSの設計コンセプトと先端 IT

2017年2月3日

先端IT活用推進コンソーシアムビジネスAR研究部会

日本総合システム株式会社　中川雅三


変容する日本

• 「日本人の生産性」は先進国で 20年以上連続最下位

• 若者の孤独死：　 238人（ 2015年東京都）

• 2025年：高齢者人口 30%超、うち20%が認知症

2


ITでよりよくしたい

• 身の回りのコンピュータ・ロボットで人生を豊かにする–短時間で価値の高い仕事–老化や障害をカバー–楽しい人生のツール…

3

AITC ビジネス AR部会

の関心事


実現したいこと

たとえば• 多様な生活をよりよく安心に

– 若い頃や健常なときから使っているシステムが、シームレスにみまもりや介護を実行。

– 時代に合わせてシステムも変わるが、共通部分は捨てずに使い続ける。

• ビジネスや趣味を豊かに– 企業や行政のサービスを組み合わせて、ソフトウエアのファブラボを、オフィスや自宅で実現。

– 情報処理で済むところはシステムに任せて、制作やパフォーマンスに集中。

4

誰でも思いつくことが実現していない？


実現の障害

• ビジネスが縦割である– あらゆるサービスを組み合わせたい

• APIやデータの標準がバラバラかつ歯抜け– サービスをLEGOブロックのように組み合わせたい– 誰でもLEGOブロックを作れるようにしたい

• クラウドだけでは実現できないことがある– 今はクラウドが中心

• ローカルは単なる端末やセンサー

• 長期視点が欠如している– 「数十年にわたって使う」をあたりまえにしたい

5


ビジネスの縦割

• 連携させたいができない– 機器・サービスの連携

• ヘルスケアとホームオートメーション• ロボット掃除機と介護…

– ビジネスの連携• 企業システム同士例：　複数の勤務先のスケジュールと個人のスケジュールを同期

• 任意のサービス同士– 旅行社、ホテル、レンタカー、レストラン…– 宅配会社、自治体、塾、学校、ベビーシッター、介護サービス、医療機関、金融機関 …

6


APIやデータの標準

• これまではバラバラ・歯抜けである–業者や業界が標準を決めていた

• 業際や新規の事業では標準を作る人がいない。

–標準の記述方法が標準化されていなかった• 表現方法がばらばらで、機械可読でない。

–規格の寿命が短かった• 規格の寿命　≒　製品・サービスの寿命

7


クラウドにできないこと

• リアルタイム処理– 光速の壁– ばらつくパフォーマンス

• プライバシーの制御– 極度に機微なデータ– 多様なデータ・制御

• 特有のリスク– 広域災害– ネットワーク障害– テロ・戦争

8

浴室の映像をクラウドへ送れる？

車やロボットの制御はローカル側が主体

生命維持装置の制御をクラウドに任せられる？

日米が戦争状態になったら、米社のクラウドサービスに頼

れる？


長期的視点の欠如

• 家・オフィス・街を支える IT機器何十年も人生は続く　事業や企業の寿命より長く

必要なのは：– 故障したら入れ替えられる– 不足したら足せる– 新しい機能を追加できる– 古いデータを使える– サービス業者が撤退してもデータは使える– 引っ越しても設定をひきつげる…

9


解決方法

• 入れ替え可能なパーツを連携させる– 新陳代謝しながら永続するシステム

• クラウドだけに頼れないデータ・サービスはローカルに置く– ネットワークが切れても命を護る– 機微なプライバシーは自分で管理する

• サービス同士を連携できるようにする– 現場で必要なサービスを作り出す

10

Copyright © 2015 Advanced IT Consortium to Evaluate, Apply and Drive All Rights Reserved. 11

空間 OS


LOD Linked Open Data

LOD = RDFストア＋ SPARQL＋ HTTP　　　　　＋オントロジー

• 国際標準である• データとメタデータを両方記述できる• 任意のデータ構造を表現できる• 誰でも自分の名前空間が作れる• HTTP+JSONでアクセスできる

12

グラフDB 問い合わせ言語プロトコル

メタデータ


仕事・学校

外部サービス

地域

関係者空調

LODを使えば

• 誰でも勝手にデータ構造を作って、 LODでデータ構造とメタデータを記述して、公開できる。

13

家

家族

家電・ロボット

照明

健康・医療食品・調理

ファッション

建物


LODに足りないところ

• 「サービス」をつくれない– LODはデータストレージの標準だから

• 大量データを扱いにくい–複雑なデータ構造はオンメモリでないと遅い–単純なデータ構造を記録すると効率が悪い

• アクセス権限を制御できない–データセット全体でしか制御できない

14


CPLOD Cyber Physical LOD

• LODの足りないところを拡張する– 物理ノード

• 外界の値と連動するRDFノード• WebSocketによる変化通知

– 外界の変化を物理ノードへ通知：センサー値取得– 物理ノードの変化を外界へ発信：エフェクター制御

– 他のストレージとの連携　：　苦手は得意なヤツに任せる• 物理ノードの履歴記録• ファイル・データベース連携の標準化

– ノード毎のアクセス権限管理• RDFでロールごとの認可を記述

15


CPLODの実装

16

RDFストア(Apache Jena)

拡張 SPARQL・クエリ・アクセス制御

現在値ブローカー・即時配信・ RDFストア反映・時系列記録・他種ストレージ

拡張ストレージ

空間 OS アプリケーション

HTT

Pサーバ

MOYO

GET/POST

WebSocket

空間 OSサーバ

Moyo : https://github.com/m-nakagawa/jena/releases/tag/v0.1　 Apache Fuseki を改造。個人でオープンソース実装

https://github.com/m-nakagawa/jena/releases/tag/v0.1

https://github.com/m-nakagawa/jena/releases/tag/v0.1


基本パターン 1

• センサーが事実を記録する– 時刻と測定値の記録（スカラー、ベクター、集合。エラー、測定器の属性）– 最後の値が「現在値」– 過去の記録も残す– 監視しているリスナーへ記録イベントを通知する

17

CPLOD センサーリスナー



• 操作を実行する– 指令をエフェクターへ送る（「電源オン」「温度設定25度」など）– 時刻と操作の記録– 監視しているリスナーへ記録イベントを通知する

18

CPLOD エフェクターコマンダー

リスナー


単純な例

• センサー情報を使ってエフェクターを制御– センサーはWebSocketで物理ノードへデータを注入– エージェントはSPARQLクエリやWebSocketで状況やその変化を取得、エフェクターの物理ノードへ指示を書き込み

– エフェクターはWebSocketから指示を取得して実行

19

CPLOD

人感センサー

照明制御プログラム

照度センサー

調光器

人がいて部屋が暗かったら照明を点灯する点灯す

る


デバイス操作

• 物理世界のデバイスを操作する• Lピカ：　https://youtu.be/CWXya-e80OU

→　メモリマップド I/Oに似ている

20

PREFIX lcl: <http://bizar.aitc.jp/ns/fos/0.1/local#>PREFIX : <http://bizar.aitc.jp/ns/fos/0.1/>APPLY { CONSTRUCT{ _:1 :設定 "ON" . _:1 :対象 ?idfr . } WHERE { ?s1 :パス識別子 lcl:1F . ?s1 ?p2 ?s2 . ?s2 :パス識別子 lcl:居間 . ?s3 :値主 ?s2 . ?s3 :パス識別子 lcl:照明 . ?s3 :値識別子 ?idfr . }}

https://youtu.be/CWXya-e80OU

https://youtu.be/CWXya-e80OU


簡単なデモ

21

CPLOD

AWSで実行プログラムなし

ブラウザブラウザブラウザ

心電センサのふり


簡単なデモ

22



• 様々な情報を解釈・総合してCPLODへ書き戻す– クレンジング ―　ノイズ除去、較正、要約、エラー処理…– 抽象化　―　画像から文字へ変換とか– 解釈　―　センサー情報を総合して人の行動や感情を把握とか…

23

解釈・判定リスナー CPLOD


連鎖する解釈

• 情報の抽象化・詳細化・学習– 様々なセンサーの値を総合する– センサー値の履歴を分析する– 学習する– 意味を処理する　（人とも連携する）…

24

解釈事実物理世界解釈 …

人感センサー：人か動物がいる

Aさんがいる Aさんが何か探している


事実事実

連鎖する情報とアクション• 永遠の繰り返し

– 事実を処理して解釈が生まれる– 事実や解釈を判定してアクションが生まれる– 解釈や判定の記録が残る– アクションの結果として新たな事実が生まれる

25

事実

アクション

解釈

事実物理世界

センサー・人

エフェクター・人

解釈・判定

解釈・判定解釈・判定


空間OS

• CPLODを中心としたアーキテクチャ–空間に CPLODを結びつけ、デバイスを連携させる

• 物理的な空間：家、街…• 仮想的な空間：家族、会社…

–汎用モジュールをビルトインして発展させる–空間 OS同士を連携させる

26

ハードウエア抽象化などの機能から「 OS」と呼んで

いる普通の OSとは異なる


空間へ結びつける

• 空間内の情報を管理、デバイスを連携させる–人のまわり–部屋・家・オフィス・自動–車・飛行機–集合住宅・ビル・団地・駅・飛行場–街・地域–国・仮想世界–世界　＝　 LOD

27


仕事・学校

外部サービス

地域

関係者空調

例：家

• 家の中のあらゆる情報を扱う

28

家

家族

家電・ロボット

照明

健康・医療食品・調理

ファッション

建物


発展シナリオ -1

空間OSの発展：CPLOD単体からはじめ、汎用的なモジュールを空間OSへ組み込んでゆく

• ミドルウエア– ルールエンジン

• if thenルール、時刻・時間イベントの発生– AIエンジン

• 学習結果のローカル適用• 学習のローカル実行

– 原因究明エンジン• 障害発生時の因果連鎖の調査

– 人間API　：　人との連携• そこにいる人とのインタラクション　NUI的• 外部の人やサービスとのインタラクション

29


発展シナリオ -2

• アダプター– 各種 IoTプロトコルアダプタ各種プロトコルには存在理由があり、統一できないし統一する必要もない。

• 発見・接続• プロトコル変換• 運用（故障・寿命・較正・メンテナンス…）

– 各種 APIアダプタ既存実装と連携するのに必要

30


空間OSの構成

31

空間内のデバイス群

ドライバ

デバイス

GUIなどのサブシステム

カーネル

アプリケーション

ドライバ

デバイス

ドライバ

デバイス

ドライバ

デバイス

HTTP

ルールエンジン・人間 APIなどのミドルウエア

CPLOD(Cyber Physical Linked Open Data)

空間 OS型アプリケーション

アダプター

HTTP アダプター

デバイスドライバ的アプリケーション

1台のコンピュータ

一般アプリケーション

• 一般の OSとの対比

空間 OS一般のOS

センサー・エフェクター … .スケジュール・掃除…

空気を読む家・オフィス・街…


空間 OS同士を連携させる

• すべての空間OSは互換・対等：　相互運用できる– 他の場所の空間OSとセキュアに連携する

• 場所や組織の包含関係による Tree状接続• 用があれば直接接続

32

政府・自治体

住宅オフィス店舗

世界

企業・サークル

…


ローカルとクラウド

• 空間OSはローカルとクラウドに置いた 2個のCPLODで構成してもよい。

– クラウドの利点• コスト最適化• 多重化によるバックアップ• ビッグデータの解釈

– ローカルの利点• リアルタイム応答• クラウドダウン時のサービス続行• 「自治」の実現（プライバシー、セキュリティ）

33


例：睡眠データ収集

• 機微なデータを隠せる

– 家の空間OSにセンサーを接続• 物理ノードへ送信• 自動的に履歴を記録

– 家の空間OSへ睡眠分析プログラムを派遣しておく• 分析プログラムが中間結果を生成

– この時点である程度機微な情報をとりのぞけるかも• 履歴の記録があるので分析アルゴリズムが変わってもやりなおしができる。

– クラウド上の空間OSへ中間結果を送信• クラウド上でビッグデータとして処理• 送信をわざと遅らせれば、在宅状況などをリアルタイムに漏らさなくて済む。

34


空間OSで解決策を実現

• ビジネスが縦割である– あらゆるサービスを組み合わせるハブにする。– リッチなコンテキストを共有する

• APIやデータの標準がバラバラかつ歯抜け– RDFで表現して、サービスをLEGOブロックのように組み合わせる。

• クラウドだけでは実現できないこと– ローカルで実現する。

• 長期視点が欠如している– 構成要素の差し替えで、「数十年にわたって使う」をあたりまえにする。

35


空間OSでこうなる

• 新陳代謝するシステム– 構成要素が入れ替わりつつ動き続ける– 機能・性能が進化する– 障害が発生したら原因をしらべて改良する

• 連鎖するデータとアクション– 解釈の連鎖– アクション因果の連鎖

• ローカルでの連携とクラウドとの連携– クラウド：　コストの最適化と「ビッグデータ」の利用– ローカル：　自立とリアルタイム応答

36

今は手動将来は自動も

異種分散アーキテクチャ

世の中の全体最適


実現したいこと

たとえば• 普通の生活をよりよく安心に

– 若い頃や健常なときから使っているシステムが、シームレスにみまもりや介護を実行。

– 時代に合わせてシステムも変わるが、共通部分は捨てずに使い続ける。

• ビジネスや趣味を豊かに– 企業や行政のサービスを組み合わせて、ソフトウエアのファブラボを、オフィスや自宅で実現。

– 情報処理で済むところはシステムに任せて、制作やパフォーマンスに集中。

37

復習


• 認証・認可• 物理ノードの拡張

– 複雑な構造• 拡張ストレージとの連携• プロトコル変換・API変換• ログ（原因究明エンジン用）

– 責任の所在を明らかにする• 空間OS間接続

– 物理ノード同士を接続• RDF設計ツール

– LODと少し違うところがある• 汎用エージェント開発

– ルールエンジンなど• 開発手法

– 「意図」の表現方法– 矛盾の解決…

今後の実装課題

38

既存技術のリニューアル…WebServiceORBエージェントユビキタス

すべての語彙を RDFで表現するところが違う


http://aitc.jp

https://www.facebook.com/aitc.jp

最新情報はこちらをご参照ください

ハルミンAITC非公式イメージキャラクター

http://aitc.jp/

http://aitc.jp/

http://aitc.jp/

https://www.facebook.com/aitc.jp

ソフトウエアジャパン2017　IT Forum AITC(6)

Technology

Transcript of ソフトウエアジャパン2017　IT Forum AITC(6)

ソフトウエアジャパン2017 IT Forum AITC(6)

Technology

Transcript of ソフトウエアジャパン2017 IT Forum AITC(6)

ソフトウエアジャパン2017　IT Forum AITC(6)

Transcript of ソフトウエアジャパン2017　IT Forum AITC(6)