ソフトウエアジャパン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
アプリケーション HTTPサーバ
MOYO
GET/POST
WebSocket
空間OSサーバ
Moyo : https://github.com/m-nakagawa/jena/releases/tag/v0.1
Apache Fuseki を改造。個人でオープンソース実装

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

基本パターン2
• 操作を実行する
– 指令をエフェクターへ送る（「電源オン」「温度設定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 .
}
}

簡単なデモ
21
CPLOD
AWSで実行
プログラムなし
ブラウザブラウザブラウザ
心電センサ
のふり

簡単なデモ
22

基本パターン3
• 様々な情報を解釈・総合して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
既存技術のリニューアル…
WebService
ORB
エージェント
ユビキタス
すべての語彙をRDFで表現するところが違う

http://aitc.jp
https://www.facebook.com/aitc.jp
最新情報は
こちらをご参照ください
ハルミン
AITC非公式イメージキャラクター

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

More Related Content

What's hot

Viewers also liked

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

More from aitc_jp