, 20151212 ioe社会のビジョンとそのアーキテク...

IOE社会のビジョンとそのアーキテクチャデザイン

!ーリアルワールドOSとプロジェクトプログラミングが可能とする産業構造と社会ー

東京工業大学　総合理工学研究科　出口弘

[email protected]

SED21, 名古屋, 20151212

じた。

＊　今日M2M,IoT,IoEなどで呼ばれる、第二のインターネット革命への関心が高まりつつある。第一のインターネット革命では人のコミュニケーションを中心に社会から産業まで広範な変化が地球社会に生じた。

＊　現在生じつつある第二のインターネット革命では、「もの、こと、しくみ」に関する新たな変化が、インターネットと物理的・社会的現実の交錯するサイバーフィジカル空間(CPS)の上のワークフローの革命と言う形で、生じようとしている。

＊　情報ネットワークとそれを媒体とする社会的ネットワークの上で、ひと・もの・ソフトウェアー等、様々なタイプの自律分散的エージェントがノードとして相互に結合しワークフローが構築され、センサーデータから会計データに至るまで無数の情報が上を流れることで、ノード間のワークフローによる様々な価値形成の仕組みを構築することが可能となる。

＊　またそのアーキテクチャの具体的な形として、CPS上の自律分散的ノードを結ぶワークフロー・プログラミングを可能とするプロジェクトプログラミングというアーキテクチャ及び、CPS上のノードやワークフローを管理するCPS上のオペレーティングシステムとしてのリアルワールドOSについてこれを論じる。

＊　この第二のインターネット革命が我々の社会にもたらす「新たな現実」の可能性とその構築のためのシナリオを、ここではIoE社会のビジョンと、それを可能とする基盤としての技術・データ・社会制度までを含むアーキテクチャのデザインとして論じる。

IOE時代と新たな産業革命がもたらすもの

IOEという新たな産業革命が始まった。この産業革命が我々の社会に何をもたらすのかを読み解くことからはじ

めなければならない。

!第一次インターネット産業革命：情報コミュニケーション・チャンネル創成型の産業革命　インターネット上で、相互の通信や、情報の参照、情報の交換、情報の蓄積など広義の情報コミュニケーションプロセス（電子メールやWeBやSNS、受発注鵜、DBの利活用など）が可能となることで、情報の交換・流通・蓄積・参照等がインターネットワーク上で遂行されるようになり、それがB２B、B２C、C２Cを含む産業の在り方を大きく変化させた、産業革命。 !第二次インターネット産業革命：IoEを基軸としたワークフロー創成型の産業革命　あらゆる「ひと」「もの」（センサーや機械など）「ソフトウェア」（計算ノードや人工知能のプログラムなど）からなる「(IoE)ノード」によって実行される『仕事の単位プロセス（タスク）』が、インターネット（サーバーフィジカル空間：CPS）上で相互に結びつくことで、多彩なワークフロー（プロジェクト）がインターネットワーク上で遂行可能となり、それが既存の組織の壁を越えた「情報」「もの」「サービス」の創り手、使い手を結びつけ、「ものづくり」、「サービスづくり」、更に多彩な「付加価値形成」のための仕組みづくりを可能とする、タスクとワークフローの創成による産業革命

第一次インターネット産業革命と第二次インターネット産業革命

http://www.eclipse.org/proposals/technology.paho/

��

IOEは非常に大きな影響を市場に与える

５００億のもの

５０億の人

１０億の場所

2020年

http://www.slideshare.net/CiscoPublicSector/cisco-iot-for-hawaii-tech-day

M２Mで 7.4兆ドルの付加価値

M２Pで 4.6兆ドルの付加価値

P２Pで 7兆ドルの付加価値


IoEソリューションのエコシステムをどう構築するか？ネットワークのエッジでの分散インテリジェンスとしてのFog Computing

http://www.pinterest.com/pin/447967494157210229/

クラウド」による中央集権的データ処理ではなくデータを生成するローカルな場でのデータの自律分散処理が必要。そのためにシスコが打ち出したのが、ネットワークの端（エッジ）でのフォグコンピューティング

という概念

Cyber Physical Space上の人・もの・ソフトエージェントからなる無数のワークフローが自律分散的に構築される世界のデザインは如何に可能となるか？

IOE(Internet of Everything)時代の超多様なサービスワークフローの革命はどのようなビジネスモデルによるのか？

オンデマンドホールライフサービス

尊厳のある生活

都市

歩行支援ウェアラブルノード（Walk Mate)

S

認知機能支援ウェアラブルノード

S

ライフログ

S

家電家

様々なライフスタイルの生活支援サービス

S

C

工場SC

ビジネス企業

小さく無数に起業

SC

農業

SC

ヘルスケア支援サービス

薬健康

S 地域

家電家

省エネルギー

S

S

Cyber Physical Space上の人・もの・ソフトエージェントからなる無数のワークフローが自律分散的に構築される世界のデザインは如何に可能となるか？

工場農業

無数の起業多様なライフスタイル省エネルギー

ヘススケア支援

ホールライフサービス

IoEのクラウドビジョンとアーキテクチャ

＊　IOEのノード間のビジネスロジックをクラウドで記述するクラウドソリューションが現在構想されているIoE,IoTのほぼ全てで想定されている。＊　これは、ノード間の自律分散協調型のプログラミングのアーキテクチャが（ソケット通信しか）事実上存在しないことと結びついている。＊ノード間プログラミングのアーキテクチャの不在が、クラウド上でのビジネスロジックという「古い現実」に基づいたアーキテクチャを中心とするビジネスモデルの不在を招いているのではないか？ http://ideas.returnonintelligence.com/about/research-and-exploration/integration-strategies-for-the-internet-of-things/

IoTクラウドビジョンの例

http://saphanatutorial.com/introduction-to-internet-of-things-part-1/


http://www.eljardindigital.com/en/project/internet-of-things/


http://www.psfk.com/2014/03/internet-of-things-infographic.html


http://www.techtimes.com/articles/82632/20150908/ibm-teams-up-with-arm-to-develop-deeper-internet-of-things-integration.htm

IBM IoTクラウドビジョンの例

http://www.elertus.com/oem/

https://www.lsr.com


なぜクラウドソリューションばかりなのか？　疑問に思いませんか？？？

ネットワークのエッジでの分散インテリジェンスとしてのFog Computing

http://www.pinterest.com/pin/447967494157210229/

クラウド」による中央集権的データ処理ではなくデータを生成するローカルな場でのデータの自律分散処理が必要。そのためにシスコが打ち出したのが、ネットワークの端（エッジ）でのフォグコンピューティング

という概念

フォグコンピューティングとそれを実現する技術

＊　ネットワークのエッジでの分散インテリジェンスとしてのFog Computingの概念はCISCOなどにより提唱されているが、それは実際にCPS上で無数の自律分散的なワークフローを容易に構築することのできる技術として、どのようにして実現できるのか？

現在までに提案されている様々なアーキテクチャ


Cisco IoTクラウド&フォグビジョン

実際のアーキテクチャは見えない？IOE時代のアーキテクチャは何か？

��

シスコはInternet of Everything とそのためのフォグコンピューティングの概念を提唱し、シスコのネットワークOSである

「Cisco IOS」をLinux OSと統合した「Cisco IOx」をフォグコンピューティングのためのプラットフォームとして2014年春に発

表した。

ここにはまだIOE機器を結んでサービスのワークフロー（サービスチェイン）

を機能させる技術は無い

Swarm Lab VISION Swarm OS

モザイク OS

現在のIOTのサービスビジョンとそのためのシステム:%Thing%Worx社のToami

http://www.nsw.co.jp/topics/tpcs_20130507toami.html

ノンプログラミングプラットフォームにより開発を高速化！M2Mクラウドサービス「Toami」提供開始

～日本国内におけるM2Mソリューション提供とサポートにおいて ThingWorx社とパートナー契約締結～

2013年5月7日ITソリューションプロバイダのNSW（日本システムウエア株式会社、本社：東京都渋谷区、代表取締役執行役員社長　多田尚二）は、5月7日、ThingWorx社（米国ペンシルバニア州、CEO　 Russell Fadel）と日本国内におけるM2M（※1）ソリューション提供とサポートに関するパートナー契約を締結しました。本契約により、同社のノンプログラミングM2M開発プラットフォーム（※2）を活用したM2Mクラウドサービス「Toami（トアミ）」の提供を開始するとともに、日本国内に展開するThingWorx社の顧客企業へのサポートサービスも提供します。本サービスは、M2Mシステムの開発スピードの高速化を実現し、ビッグデータを活用したあらゆるビジネスニーズに迅速な対応が可能です。

日本は既にこの第一世代IOTサービスで完全に出遅れ、実世界のセンサーネットワークのオペレーションの支援システムを開発できていない。この輸入はIOTの仕組みビジネスに負けを宣言する愚行！！

制御こそが難しい！

MatLab !のIOTサービス版？

!

http://gereports.jp/post/102262683249/ii-bill-ruh

;YGDKW:X&;YF(MHK7387@V<LZ7��7+��#,

http://it.impressbm.co.jp/articles/-/11775-� �� 'DKW(TJ(Fce&mh&[l_7J(FR(D�-�� "� $��! ��'_jb7:QWA(CUYk�-��'�� :EHKOP>(SYDg^*

インダストリアルインターネットのためのクラウドコンピューティングの為のプラットフォーム。オープンソース化の予定。「「Predix」上で活用可能なアプリケーションソフトを90日間というサイクルで、大規模かつ迅速に開発」

IBM #Node-RED

既存のサービスをネット上で繋ぎあわせる、エンタープライズサービスバスの発想の延長上

201408 ��7d\QVHKP>(Tfa)��

-�.�JN;D9B(NZ5]i024`/1387B(N?W=YIHL6d\fa%

「M2Mデバイスとサーバー側の双方に共通プラットフォームを組み込み、その上にアプリを載せて、アプリとアプリがデバイスとサーバー間で話す」（oneM2MのTechnical

Prenary LeadershipでVice Chairを務めるKDDIの山崎マネー

ジャー）

http://itpro.nikkeibp.co.jp/atcl/column/14/112800109/120100003/?ST=iotnext&P=1

IFTTTはクラウド上でコンポーネントを組み合わせて「単純なワークフローを登録で来る」

http://www.siemens.com/innovation/apps/pof_microsite/_pof-spring-2013/_html_en/industry-40.html

ドイツの　INDUSTRY 4.0IOE時代に、

欧州ではINDUSTRY 4.0等の構想が、ものづくりでも提案されているが、まだ中身は定まっているとは言えない状況、更にERPがビジネスプロセスを標準化の名の下にスレーブ化したのと同様に、情報処理側から工場のプロセスをスレーブ化する可能性がある。

改善ない工場を造る可能性。これはERPパッケージが現場主導で新たな現実を作る力が無いのと同様！！！

クラウド独占の時代＊　第一次インターネット革命は、主にコミュニケーションに関する革命であった。そこでは自律分散的なアーキテクチャが指向され、決して切断することのできないネットワークが「決して島をつくらない」という理念の元に構築された。＊　UUCPで世界を結んだ「internet」からIPネットワークとしての「The Internet」への進化の中で、「核戦争で寸断しない」という名目の作文でDARPAからも研究費を得たBSD Unix上のTCP/IPのネットワークは、国によってつぶされることのない、自律分散協調型のシステムを構築した。＊　インターネットは結果的に従来型のマスメディアからパーソナルメディアの時代を切り拓いて、誰もが世界に情報を発信できるという理念を実現した。そこではテッドネルソンのザナドゥのようなビジョンがWWWにつながる等、ビジョンと技術のスパイラル上の変化が見られた。＊　しかし、他方で予想外の出来事も生じた。インターネット上の情報集積を新たな資本とし、プラットフォーム構造を取る新たなコミュニケーション・コンテンツ系のビジネスは、強いロックイン構造を持つウィナーテークオールの産業構造をつくりあげた。同時に流通領域でもデータベースソリューションによるローカルケーバビリティの抑制と言う、自律分散の理念とはかけ離れたビジネスモデルが普及するようになった。

* ロックイン経済と大規模な貧富の差はデジタル経済とインターネット革命の後に生じている。これはインターネットの理念とは逆方向の予期せぬ動き

AND / ORインターネットのアクセプタブルユースポリシーが変化し商用インターネットがスター

トするのは、１９９３年

格差は商用インターネットがスタートした１９９３年から拡大続けている

Micro Electronics Revolution

Internet Revolution

ピケティは格差は資本収益率が労働分配率（経済成長）より高いのが原因というが、、

高付加価値-Component

低付加価値-C

低付加価値-C

低付加価値-C

低付加価値-C

ICT 化されたコンポーネントビジネスモデル

ビジネス全体としては、高い ROE(return on equity) が実現さ

れている

低付加価値-Cの労働者は置き換え可能で、マニュアルをインストー

ルする対象低付加価値-Cではケーパビリティデベロップメントが無い（改善は下から行われない）

1% Rich

99% Poor

• ICT supported component business model, business components are divided into two categories. The one is high value added component. The other is low value added component where the workers are replaceable, low salary and no capability development.

ICT 化されたコンポーネントビジネスモデル

Business Internet

has Started on 1993

低付加価値のコンポーネントは、同時に低ケーパビリティ（低い能力開発）のコンポーネント。これが最大の問題！このコンポーネント分割はアダムスミスの分業ではない！！！工場は、現場からの改善を受入れるし、技術者・労働者の能力向上や独立・スピンアウトが可能！　コンビニやバーガーチェーンの店頭では改善はあり得ないし、従業員の独立や暖簾分けも無い！！！

��!.'(+$ �"-*.&-%�� ,)#%��

これは従来の工場での機械やロボットの導入とは異なる！工場では「自働化」は人のケーパビリティを奪う様には設計されて来なかったが、、、

負け惜しみの話：９０年代に行ったプラットフォーム型の産業構造と仕組みビジネスの分析は受入れてもらえなかった

＊出口弘,「ネットワークの利得と産業構造」『経営情報学会誌』, Vol.2, No.1,pp.41-61, 1993!＊出口弘、ネットワーク (シリーズ・経営情報システム)、日科技連出版社、1994!＊植田弘和、出口弘他著，『新しい産業技術と社会システム』,日科技連出版、1996!＊出口弘,「自律分散型の産業構造と組織」、ハーバード・ビジネス、5月号，pp.44-53,1996，ダイアモンド社!＊出口弘! 中小企業のものづくりとIT革命! 商工金融、商工総合研究所! Nov.,2000,Vol.50, No.11, pp.4-23!＊出口弘, 『複雑系としての経済学』日科技連出版社, 2000 !＊出口弘, 工業集積上でのオープンものづくり--繰返し単品受注生産システムによる産業構造の創成,組織科学第36巻第2号, 白桃書房, 2002, pp38-53!＊Deguchi, H. 2004. Economics as an Agent Based Complex System. Springer-Verlag.

デザインサーバ

製造サーバ

物流サーバ販売サーバ

商品のライフサイクルマネージメントサーバ

情報ネットワーク空間

http://www.siemens.com/innovation/apps/pof_microsite/_pof-spring-2013/_html_en/industry-40.html

ドイツの　INDUSTRY 4.0IOE時代に、

欧州ではINDUSTRY 4.0等の構想が、ものづくりでも提案されているが、まだ中身は定まっているとは言えない状況、更にERPがビジネスプロセスを標準化の名の下にスレーブ化したのと同様に、情報処理側から工場のプロセスをスレーブ化する可能性がある。

改善ない工場を造る可能性。これはERPパッケージが現場主導で新たな現実を作る力が無いのと同様！！！

クラウド独占型のIoEから自律分散協調型のIoEへのパラダイムチェンジは如何にして可能となるか？

IoE時代には収穫逓増による独占ではなく、情報プラットフォームの特性や情報集積の利得による巨大クラウド独占（ロックイン）が生じつつある。この独占がもたらす弊害は、古典的独占の価格支配にはない。情報集積による参入可能性の低下と、末端を低付加価値のオペレータとするケーパビリティの不均衡にこの独占の問題がある。

どのような政策・制度設計や技術のアーキテクチャデザインに基づけば、新たな産業革命の中で、自律分散協調型の

IoEへの転換が可能となるか？

!トップダウンの方向性とその問題点：大規模サーバソリューションとインダストリー４．０トップダウンワークフローでは現場での継続的な改善は不可能。インダストリー４．０はこのトップダウン型でのIoTのシステム構築を目指す。トップダウン型のIoTシステムは、工場のフランチャイズ化をもたらし、現場での改善無き物作りへと繋がる可能性が高い。またそこではセンターの巨大システムの構築側とそのオペレーションを行う側のケーパビリティ（能力）ギャップが生じ、様々な現場からの小さく多様なビジネス創成の流れが疎外されるリスクが高い。 !!!ボトムアップな方向性とその可能性：自律分散型システムとデータフローソリューションリアルワールドOSとネットワーク上のワークフローを記述するプロジェクトプログラミングは、IoE時代のCPS上での自律分散協調型のビジネスワークフローを可能とする。自律分散型のIoEシステムは、ボトムアップに様々なプロジェクトプログラミング対応のIoE機器が開発され、後付け的で改善可能な工場のIoE化が可能となる。

IoE革命の二つの流れ１：トップダウン型とその問題

IoE革命の二つの流れ２：自律分散型とその可能性

我々の提案するアーキテクチャ：実世界OSとプロジェクトプログラミング

リアルワールドOS人・もの・ソフトがネット上で連携してワークフローを実現し、そのワークフローを管理する自律分散協調型の実世界の自律的エージェント間関係のボトムアッ

プ型支援システム

リアルワールドOSとプロジェクトプログラミングによりCPS上のノード間での自律分散協調型のワークフローの遂

行を可能とする

RWOSを構成する３つの基幹技術＋仮想バス技術

（１）実世界プログラミングとしてのプロジェクトプログラミングとその言語OWLIE （２）データフローソリューションとデータ代数・交換代数とそのための言語FalconSeed （３）エージェントシミュレーションとその言語SOARS

!リアルワールドOS：サイバーフィジカル空間（CPS）上の自律的エージェント（ノード或はIoEノードと呼びます）を結んでワークフロー（まとまったタスクからなる仕事）を遂行するためのプログラミングやノードの管理を支援する、インターネット上の自律分散協調型のタスク管理のためのオペレーティングシステム。プロジェクトプログラミング：インターネット上のIoEノードを相互に結びつけて一つのワークフローを実現するためのプログラミング手法。ステージモデル：プロジェクトプログラミングではステージと呼ばれるプロセスの実行制御のタイミングで、CPS上のIoEノードにタスクの遂行を指示する。 Pub・Sub・Calc・Control＆Managementモデル：CPS上でMQTTの様なブローカを用いて、IoEノードにステージ情報を送り並列ノードの実行順序の管理をし、IoEノード間で相互にデータを転送し、収集したデータから様々な計算を行い、それらの結果をユーザ間でシェアしたり、シーケンサー等の制御機器にコマンドを送ることができる。

リアルワールドOSとプロジェクトプログラミングによりCPS上のノード間での自律分散協調型のワークフローの遂行を可能とする

Calc Stage

Stage

Stage

Initial Stage

init end

Data Pub Stage

Data Sub Stage

Main Stage

Repeat Stage

Stage

Stage

Terminal Stage

Terminal end

Control & Result

Pub Stage

ActionStage

Control &Result

Sub Stage

ステージ制御によるPSCC(Pub-Sub-Calc&Controlの遂行（社会シミュレーションから実世界並列制御OSへの進化）

社会シミュレーションによるサービスシナリオ分析

センサーや人や機械などの多様で多数のサービスノードを結び並列制御を可能とする実世界OS

への発展

分散ストリーミングによる多様で大規模計算

SOAR Falcon Seed

OWLIE(プロジェクトプログラミング言語)でビジュアルにプロジェクト定義をする

データ計算ステージ

実行＆表示ステージ

データ収集ステージ

S

人がデータを入力する

データ入力

制御やマネージメントに必要なデータ計算をする

情報を共有ディスプレイに提示

Project Manage

rNode

ManagerOwlie

RWOS Developer Kit

それぞれのステージで実行可能なタスクを組み合わせて容易にプロジェクトを構築できる

3 ステージ型プロジェクト

情報を受取る情報に基づ

き機器を制御する

ツイッタに情報をつぶやくパトライト

で警告等を表示する

リアルワールドOSプロジェクトコントローラはローカル・クラウド（工場等に設置も可能）

Exec StageCalc StageData Stage

RWOS Project Manager Window :Project A

Calc Stage Exec Stage

ソーシャルメディアからデータを取得する

データをアーカイブする

RDB

センサーでデータを取得する

Sensor Sensor

WWWSensor

13

3V3

AREFA0A1A2A3A4A5

5V

RST

GND

VIN

12

11

10987654

3

2

GND

RST

RX0

TX1

MISO

SCK

ICSP

MOSIRX/LED

WWWSensor

13

3V3

AREFA0A1A2A3A4A5

5V

RST

GND

VIN

12

11

10987654

3

2

GND

RST

RX0

TX1

MISO

SCK

ICSP

MOSIRX/LED

Sensor

データ入力

自作データ処理モジュール

自作データ収集モジュール

自作データ実行モジュール

会計処理モジュール

センサーデータ処理モジュール

統計分析モジュール

データアーカイバ

ビックデータ処理モジュール

制御用計算モジュール






情報を共有ディスプレイに

提示

情報を受取るツイッタに情報

をつぶやく

ツイッタからデータ取得

健康データ取得

パトライトで警告等を表示する

情報に基づき機器を制御する





WWWSensor

13

3V3

AREFA0A1A2A3A4A5

5V

RST

GND

VIN

12

11

10987654

3

2

GND

RST

RX0

TX1

MISO

SCK

ICSP

MOSIRX/LED

Sensor

データ入力











提示


をつぶやく





仮想コマンドバスと仮想データバス

ネットワーク上のノードを結ぶ、データバスを構築するフレームはIBMのノードレッドなど、でてきつつある。しかし我々が求めるのは、ネットワーク上のノードを結びつけたワークフローの構築（OWLIEによるプロジェクトプログラミング）とそのワークフローの集合への様々な支援

（リアルワールドOS）

CPSスペース上のノード間を結ぶ仮想バスのアーキテクチャ

＊　サイバーフィジカル空間(CPS)の上のワークフローを「プログラム」するアーキテクチャを構築するには、まずCPS上のノードを結ぶ仮想バスのアーキテクチャが必要となる。＊　これに用いられるのが、Pub/SubアーキテクチャとそのMQTTブローカによる実装

インターネット上に仮想のコマンドバスとデータバスをPub/Subプロトコルで構築し、人やソフトやセンサー、アクチュエータ等の自律的で機能的なノード間を結びつけ、そこでのコマンドの流れとデータの流れを制御するプログラム（プロジェクトプログラミング）によりネット上の自律分散的なワークフローを可能とする

CPS上のデータバスをMQTTが媒介

CPS上の仮想バス

Pub/SubProtocolで

MQTTブローカがネット上のコマンドやデータを媒介する

IoEノード(人)

IoEノード(ソフト)

IoEノード(機械)

IoEノード(センサー)

IoEノード(人)

IoEノード(機械)

IoEノード(ソフト)

Pulse Oximeter

light

Solar Power

Generation

Pub/Subプロトコルの実装としてのMQTT

- IBM社とEurotech社によって考案されたプロトコル- M2MやIoTに最適なシンプルで軽量なプロトコル- TCP/IP上で動作する- パブリッシュ/サブスクライブ型モデル- トピックで通信データを管理- QoS:３種類の到達保証

Publish/Subscribe プロトコルPublish/Subscribe (Pub/Sub) プロトコルはシンプルでN対Nのメッセージ交換を相手のアドレスを直接指定することなく可能とする高効率のプロトコルである。

MQTT(Message Queuing Telemetry Transport)はこの“Pub/Sub プロトコルを実装したメッセージ交換システムである”.

http://mqtt.org/ !

この MQTTシステムを我々の研究開発で導入する. MQTT はEMISの様なhttpを用いたサーバ接続のプロトコルと比べると軽量でハイパフォーマンスのシステムとなっている。

アンドロイド上でのMQTTクライアントの受発信効率：　MQTT>>HTTP

http://public.dhe.ibm.com/software/dw/jp/websphere/connectivity/ms_mqtt_ws/MQTT_MessageSight_seminar_2.pdf

Source: http://stephendnicholas.com/archives/1217

MQTTの信頼性：メッセージロスト

MQTTの受信効率（時間あたりの受信メッセー

ジ数）

MQTT の発信効率（時間あたりの発信メッセー

ジ数）

message lost rate

Low Speed

High Speed

MQTTのエネルギー効率

MQTTのサーバ側の効率http://public.dhe.ibm.com/software/dw/jp/websphere/connectivity/

ms_mqtt_ws/MQTT_MessageSight_seminar_2.pdf

Number of Connections

MQTTのサーバ側効率

Messages/ Sec CPU %

（１）プロジェクトプログラミング人・もの・ソフトエージェントがネットワークで結びついた環境でのワークフローを遂行するための実世界でのステージ内、ステージ間、プロジェクト間の３重の並列実行制御と付随するデータフロー型の情報処理。

OWLIE Project

OWLIE stands for Onsite Workflow Language for Internet of Everything &

Own Way Life on Internet of Everything

従来のErlangのようなマルチコア環境での並列プログラミングとは異なりネット上にある人・もの・ソフトからなる自律的エージェントを結びつけたワークフロー（マルチワークフロー）の駆動とそのビジネスを支援する

SS

light

コンピュータ上のソフトウェアが遂行するタスクとそれらの連携を開発支援＆実行管理をする環境と

してのOS

実世界の自律的エージェントノードが遂行するタスクとそれらの連携（ワークフローで記述されるプロジェクト）を開発支援・実行管理をする環境として

のリアルワールドOS

大型機のOS

ダウンサイジング

パソコンのOS

高速・高密度ネットワーク上のタスク管理用のネットワークOS

ダウンサイジング

スケーラブルなネットワーク上のタスク管理用のOSとしてのリアルワールド

OS

Node-Red, Swarm OS, IOx等

コンピュータ上のOSからネットワーク上の実世界OSへ

IOE革命に求められるアーキテクチャの革新１ CPS上のIOEノード間のワークフローを管理し遂行するリ

アルワールドOSとプロジェクトプログラミング　現在IoT用に用いられているアーキテクチャではセンサー等のノード情報をサーバにアップする、アップリンク型のストリーム処理が中心となっている（例えばGEのインダストリーインターネットなど）。　そこではビジネスワークフローはサーバ上で組まれる。しかしこれでは、膨大なノード情報をフィードバックした制御システムを組むことは難しい。また多様なワークフローを現場知（ローカルケーパビリティ）に基づく構築することも困難である。　　求められるのはCPS上で様々なワークフローを自律分散協調的に構築することのできるノード間のワークフローのプログラミング技術と、CPS上のノードマネージメントのためのアーキテクチャ。 !　これをリアルワールドOSとプロジェクトプログラミングとして開拓しており、現在竹中工務店でのビルOSへの提供を始め幾つかの場でα版のテストを行っている。（本発表ではこれについては扱わない）

プロジェクトモデル設計とノード実装の分離設計

（１）プロジェクト（モデル）設計人・もの・ソフトエージェントからなるネットワーク上のワークフローを表現するプロジェクトモデル設計では、プロジェクトのステージ定義とノードの役割定義（プロジェクトモデル設計）と、それぞれのノードでどのようなデータ構造とデータ間の変換が行われるかを、（２）ノード実装（ノードリアライゼーション）プロジェクトのステージで遂行する役割の個々のノードでの実装、システムのデバックとデプロイメントなど設計概念を分離して設計する。

プロジェクトプログラミングの開発環境

OWLIE Project

OWLIE stands for Onsite Workflow Language for Internet of Everything &

Own Way Life on Internet of Everything

OWLIEという言語をプロジェクトプログラミング用の言語として設計・実装中（αテスト版一部リリース、β版2015年11月リリース予定、2016年工場ハッカソンにて公開予定）

①

プロジェクトプログラミングはサイバーフィジカル空間(CPS)上のノードのタスク遂行を管理するプログラミングでRWOS上の

OWLIEという言語で記述され自律分散協調系として実行される

OWLIE(プロジェクトプログラミング言語)

会計計算

データ収集

WWWMQTTPub/Sub

抽出処理

WWWMQTTPub/Sub

データ収集

共有データ

管理・制御ステージ

データブローカ

Project Manage

rNode

ManagerOwlie

RWOS Developer Kit個々のノードのタスク遂行のためのステージ情報のMQTT上での配布

①②

③

ステージブローカ

①


② データ計算ステージ

ステージ実行情報

③

ノード間のデータの受け渡しをMQTTで媒介

制御のコマンド


マネージメントステージ


S

RWOSとプロジェクトプログラミングによりデータをシェアするだけでなく、人を含むIoE環境での、様々なワークフローをCPS上で遂行ことができる

データ入力

Sensor

Sensor

lightWWWMQTTPub/Sub

制御コマンドブローカ

①

データ処理と制御計画策定 on PC

制御コマンド発行

パブサブ対応のPLCを通じて様々な機器を制御するコマンドなどアクチュエータ制御コマンドをMQTT

で媒介





S


データ入力



Project Manage

rNode

ManagerOwlie

RWOS Developer Kit





ツイッタに情報をつぶやくパトライト

で警告等を表示する





ソーシャルメディアからデータを取得する


RDB


Sensor Sensor

WWWSensor

13

3V3

AREFA0A1A2A3A4A5

5V

RST

GND

VIN

12

11

10987654

3

2

GND

RST

RX0

TX1

MISO

SCK

ICSP

MOSIRX/LED

WWWSensor

13

3V3

AREFA0A1A2A3A4A5

5V

RST

GND

VIN

12

11

10987654

3

2

GND

RST

RX0

TX1

MISO

SCK

ICSP

MOSIRX/LED

Sensor

データ入力
















提示


をつぶやく





典型的なスリー・ステージモデルであるPub・Sub・Calc＆Exec(PSCE)とその対応機器

＊プロジェクトプログラミングで入門的なステージモデルに、データ収集・計算・実行の３ステージからなる、Pub・Sub・Calc＆Exec(PSCE)というステージモデルがある。PSCE対応のIoE機器を諏訪で今後積極的に開発＆普及したい。PSCE対応のIoE機器は、プロジェクトプログラミングで用いることができるだけでなく、より手軽にPub・Sub対応のシステムを構築するために利用できる（１）人とのデータのやりとりのためのPSCE対応機器　タブレット型アンケートシステム：諏訪圏工業メッセで用いているアンケートシステムをPSCE対応にしている。　パブサブアンドン：工場のデータ表示を PSCE対応にするための表示機器：開発中（２）PSCE対応のシーケンサー（PLC）の試作：（By (株)ロジカル・ワークス）

ヒータや送風機等を組み合わせてセンサーにより制御することでハウス農業の制御等も容易に実現できる。

Pub/Sub・Calc＆Exec(PSCE)とそのExec対応機器: Pub/Sub対応のシーケンサー、これによりセンサーや人間の入力と連動した機器の動作の制御が可能となる。通常のPLCの複雑な制御部分は、CALCノードが行う。

パブサブ対応のシーケンサー（開発中）

ヒータや送風機等を組み合わせてセンサーにより制御することでハウス農業の制御等も容易に

実現できる。





S


データ入力



提示

Project Manage

rNode

ManagerOwlie

RWOS Developer Kit





ツイッタでデータ共有する




RDB


WWWSensor

13

3V3

AREFA0A1A2A3A4A5

5V

RST

GND

VIN

12

11

10987654

3

2

GND

RST

RX0

TX1

MISO

SCK

ICSP

MOSIRX/LED






Pub/Sub対応のシーケンサ

Pub/Sub対応のアンドン

＊　今まで見えなかった「カイゼン」の可能性がプロジェクトプログラミングにより可能となる。後はアイデア次第で様々なボトムアップなIoE, Iotシステムが構築可能となる。我々はそれをオープン化してライブラリー化していきたい！！！

（２）データフローソリューションとデータ代数・交換代数とそのための言語FalconSeed

IOE革命に求められるアーキテクチャの革新２ DBソリューションからデータフローソリューションへ

この数十年の間にデータベースソリューションのような巨大サーバ（クラウド）型のソリューションにより、フランチャイズビジネスの様に現場からケーバビリティが失われオペレータとなるモデルが普及した。しかしER図によるモデルはIoE時代の複雑さと早い変化のサイクルに耐えられない。また工場のものづくりのように現場知と後付け的な改善が早いサイクルで可能となるデータフローソリューションに基づくアーキテクチャがIoE時代には求められる。 !ここでは、このデータフローソリューションの核となるデータ構造について着目する。トランザクションデータを製造タスクや販売など様々な取引イベント（Point of Transaction Event）毎に代数的多元簿記に基づき記述することで、製造タスクを上流として原価計算から生産管理、さらにサプライチェーンや国民経済まで統合的なデータ処理ができることを示す。

企業の工場から経済・産業分析まで共通の新しい現実を構築する必要性

• 第二次インターネット革命では、IoEを基軸としCPSのエッジでの多様なワークフロー創成型の産業革命が期待される。

• そこでは、工場や経営組織の原価計算・生産工程管理から産業構造・経済システムの記述と分析までを一貫して一つの共通の状態空間で認識し記述し管理することが必要となる。

• 交換代数による代数的多元簿記（実物簿記）による状態空間記述は、理論とビジネス、個々の経済主体とサプライチェーンや産業構造、国民経済に共通の状態空間＝「新しい現実」として構築する必要がある。

交換代数によって表現された多元簿記を用い、製造ワークフローの個々の製造タスクを記述することで、それを上流として、BOM(部品表), MRP(資材所要量計画)から、マテリアルフローコスト会計 (MFCA）,エネルギー会計、生産計画、財務会計と原価計算、バッズの処理を含む環境会計、更にサプライチェーン全般から国民経済の会計処理まで全て代数的な複式イベントの回路として構築できる

製品或は仕掛品の製造

プロセス

原料或は前ステップの仕掛品

製品或は次ステップの仕掛品

ファブリケーション・サービス

副産物(屑等)

MaterialInput

MaterialOutput

ServiceProcessInput

ファブリケーション・サービス

ファブリケーションサービスそのものの生産プロセス

設備（償却費）・労賃・エネルギー

EquipmentWork &

Energy InputFab. Service

Output

次仕掛品或は製品副産物（屑等）

原料或は前仕掛品借方貸方

ファブリケーションサービス

労賃設備（償却費）

借方貸方ファブリケーション

サービス

エネルギー

交換代数を用いた実物簿記（多元簿記）により製造の単位タスクはマテリアルベースのトランザクションと、そこに投入されるファブリケーションサービスに分けて記述できる。

単位製造タスクは物的な製品・仕掛品製造タスクと、そこに用いられるファブリケーションサービスの二つで記述される。

塗装済完成品

プレス成形仕掛品

��

切削加工

鉄材銅材

��

塗装工程

プレス工程

切削加工

四つのタスク（銅切削工程、鉄切削工程、プレス工程、塗装工程）からなる製造プロセスのワークフロー

銅切削加工

銅材　0.8Kg

銅切削加工仕掛品

切削加工サービス10時間

副産物(銅屑)

MaterialInput

MaterialOutput

ServiceProcessInput

��'*)(& �&�&��& "%&�&��!�& $&�&��#��'*)(& �&�&��& �&�&��

��

所要時間と人的・生産資源制約

物的材料資源制約在庫・購買・SC

切削加工装置（減価償却費）１時間

借方貸方切削加工

サービス　１時間労働　0.2時間電力　2.5KwhCO2 12.9Kg

切削加工サービス１時間（単位時間）

切削加工サービス生産

切削加工装置（償却費）・労賃・エネル

ギー

EquipmentWork &

Energy InputFab. Service

Output

銅切削加工仕掛品１個

銅屑　0.2Kg

銅材　0.8Kg借方貸方

切削加工サービス10時間

銅切削加工タスクの例

塗装済完成品（部品）の製造ワークフロー

代数的多元簿記で製造タスクの連結としてのワークフローを記述することでそれを上流として、製品の原価計算、BOM、MRP、生産スケジューリング等がこの回路から統合的に導ける

塗装済完成品


%��

切削加工

鉄材銅材

$�� !� ��

��

��

� � �� Kg

�� Kg

�� "%$#

10 ��

=-3$�� >�>)>)4(*(0,3$?@>6;>)>)4(*(.,,:3$�>6;>)>)4(*(-,:3��AFCB>�&>)>)4(

�� !� ��

��"%$#��

��"%$#

20 �� KWh

��

20 ��

CO2 258 Kg

��"%$#

4 ��

-3%�� >�>)>)4(*(,+.3%?@>6;>)>)4(*(,+1:3%�>6;>)>)4(*(-,:3��AFCB>�&>)>)4(

.,3��AFCB>�&>)>)4(*(0,3'>69<>)>)4(*(.01358.>6;>)>)4(*(/:3��AFCB>�&>)>)4(*.,3��! ��#>�&>)>)4((

-3��AFCB>�&>)>)4(*.+03'>69<>)>)4*(-.+2358.>6;>)>)4(*(,+.:3��AFCB>�&>)>)4*-3��! ��#>�&>)>)4((

�� !� ��

��

��

� � �� 0.8 Kg

�� Kg

�� "%$#

10 ��

��

"# ��$! ��

"# ��$!

� �� 10 KWh

"# ��

� ��

CO2 10 Kg

��$!

� ��

-3DEB�AFCB>�&>)>)4(*(-,3'>69<>)>)4(*(-,358.>6;>)>)4(*(-:3��AFCB>�&>)>)4(*-3DEB�! ��#>�&>)>)4(

��

��

��

� ��"��

� ��

!��

� �

��

��! ��

��! �

� �� 2 Kg

�� 4 L

�� 0.01 Kg

��! �

� ��

-3�!�� >�>)>)4(*(-G3�!AFCB>�&>)>)4(*-G3DEB�� >�>)>)4((

-3�!AFCB>�&>)>)4(*(.:3��>6;>)>)4(*(/:3��>7>)>)4(*(,+,-3��">6;>)>)4(*(-:3��AFCB>�&>)>)4(

--3DEB�� >�>)>)4(*(-G3DEB�AFCB>�&>)>)4(*(-G3%�� >�>)>)4(*(-G3$�� >�>)>)4((

��

!��

!��

� � !��"��

� ��

��

��

塗装工程

投入資材

投入FBサービス

塗料

塗装サービス


塗装工程交換代数

プレス工程


投入資材銅板切削加工仕掛品鉄板切削加工仕掛品

プレス加工サービス

プレス工程交換代数


投入資材

切削加工サービス

銅板

�� "� �� !� ��

��#&%$��

��#&%$

1 �� KWh

��

1 ��

CO2 12.9 Kg

��#&%$

0.2 ��

切削加工


投入資材

切削加工サービス

鉄板









塗装済完成品


��

��

鉄板材２０Kg

銅板材８Kg

１個

１個

１個１個

１時間

１時間

２時間１時間

塗料2Kg

塗装済製品 <---[塗装サービス１時間]

プレス成形仕掛品 <---[プレス加工サービス１時間]

銅板切削加工仕掛品 <--[切削加工サービス１時間]

鉄板切削加工仕掛品 <--[切削加工サービス２時間]

BOMは代数的多元簿記の製造ワークフローから導出され、部品コードはそのまま多元簿記の基底を用いることができる【生産計画情報の抽出】

BOMからMRPで部品・原料調達計画を策定することになる。一般にはこの調達スケジュールは、生産スケジューリングを考慮に入れておらず、いわば無限生産能力仮定の下での計画となる。例えば、塗装済み完成品を１０００個基準日時に納品することを考える。必要なだけ加工サービス資源が提供される状況では、２０００台の切削加工機と１０００台のプレス加工機と１０００人の塗装工が用意されれば、4時間で全ての作業は終了する。しかし当然ながら資本資源の制約がある。 BOMに基づくMRP的な資材の調達計画だけでは加工機械や労働資源等の、加工サービス遂行の為の資源制約によって生じる資源割当のスケジューリングの課題に答えることはできない。それゆえ生産工程では原料や仕掛品とは別に、生産機械の割当や人員の割当等の生産資本制約の下での時間単位での資源割当のスケジューリング計画が必要となる。

【並列プロジェクトの動的スケジューリング】　一般に生産計画については様々なアルゴリズムがERPパッケージ上で提供されている。しかしそれらのアルゴリズムは別途資源制約に関するDBを構築する等複雑な管理が必要となる。我々は交換代数で記述されたタスクの記述から、タスクの遂行に必要なリソースとその占有時間を求めることができる。これを用いて、複数の製品の生産に対するリソースの割当のスケジューリングを行うためには、そのためのアルゴリズムが必要となる。タスクの半順序構造により表現されるプロジェクトが複数あり、それに対してリソースを動的にスケジューリングするという並列プロジェクトに対する動的資源配置問題に対して、効果的なアルゴリズムを既に提案している（特願2011-104944：特許査定：平成27年4月8日）。代数的多元簿記によるタスク記述から得られるリソース情報に基づき、このアルゴリズムを適用することで、資源割当の動的計画とガントチャート等の情報を容易に計算することができる。

【マテリアルフローコスト会計情報の抽出】　マテリアルフローコスト会計(MFCA）は生産プロセスに於ける材料の無駄などを管理するための特殊な管理会計として近年注目を集めている。　しかし一般にはMFCでは財務会計の原価計算とは異なる基準で製品の価値を評価する。通常の原価計算では屑を含めた全ての生産への投入を製品の原価として積算する為、MFCAでの生産投入原価はあくまで無駄を明らかにするための戦略会計的な指標となる。　MFCAでは、生産の際に原料の製品と屑への利用率を重量比率で求め、それを用いて生産に用いる諸サービス投入を、真に生産に用いられた分と、屑を生産するのに用いられた分に按分する。　代数的多元簿記を用いた製造タスクの記述では、鉄板の仕掛品と銅板の仕掛品の生産プロセスでの屑の実物データ（Kg単位）を用いて容易にMFCAの計算を行うことができる。

製造プロセスの代数的多元簿記

データ

価格データ

AMBS:Algebraic Multi-dimensional Bookkeeping

System by Exchange Algebra

按分比率

マテリアルフローコスト会計データ

部品展開表(BOM)＆資材調達計画(MRP)

労働者やマシン等のサービス資源制約情報

スケジューリング　ガントチャート等

価格評価での財務会計データ

環境会計

バッズ評価

GoodsB

消費

GoodsB

投資

OR


仕掛品 AFab.

Service A原料等 A

製品BFab.

Service B

Input仕掛品

A

Fab. Service A

原料等 A

Fab. Service A

付加価値 A

装置償却費


Fab. Service

付加価値 B

装置償却費

生産管理情報

サテライト会計情報

サプライチェーン会計情報

四つのタスク（銅切削工程、鉄切削工程、プレス工程、塗装工程）からなる製造プロセスのワークフロー

部品ファブリケーションサービス

Agent

製品ファブリケーションサービス

労働：機械：部品製造資本サービス

流通サービス

労働：機械：流通資本サービス

部品製品

小売在庫製品＝家計内サービス生産の資本

流通在庫

小売サービス

労働：機械：小売り資本サービス

家計内サービス生産

サプライチェーン

サービス Chain

製品企業の組織境界

部品企業の組織境界

家計の境界

Value Added

Value Added

Value Added

Value Added

InvisibleValue Added

Value Consumed

原料

部品製造ワークフロー

労働：機械：製品製造資本サービス

製品製造ワークフロー

流通企業の組織境界

小売企業の組織境界

原料→部品→製品→流通在庫→小売在庫→購入製品生産上流から家計内サービス生産までのサプライチェーンとそこでのサービスのチェインを取引回路として把握する

インボイス形式のサプライチェーンBOMとエネルギー・環境負荷インボイスの構築サプライチェーン等の取引の連鎖に対応して、トレーサブルな部品の調達を記録する必要がいわれ、それがクラウド方式で実現できるという言説があるが、これらは代数的多元簿記に基づくインボイス形式の情報を使うことで容易にボトムアップに実現できる。１）ネットワークBOM：製品を構成する部品のサプライチェーン上のBOMで、各部品の構成のBOMの中身は省略して、企業間の調達関係だけを記したもの。２）エネルギーインボイス：部品や製品に投入されたサービスからエネルギーを計算したもので、製品に投入されたエネルギーは、そのエネルギーの構成も記録できる。３）環境インボイス：環境への排出等の環境情報も同様にインボイスとして記録でき受け渡しできるので、製品や部品の環境負荷をトレーサブルに計算できる。

代数的多元簿記に基づく生産管理を元に、インボイス方式によるサプライチェーンBOMを構成することができ、廃棄物、エネルギー情報も、巨大なサーバなしで自律分散協調的にトレーサブルになるサプライチェーン

BOMにより部品のトレーサビリティが特定のクラウドサービスに依らずに可能となる

製品の製造に使われたエネルギーの内訳やクリーンエネルギー比率等の表示もボトムアップなインボイス方式で可能

環境負荷もトレーサブルにできる

塗料鉄板材銅板材

TXORXIRSTGNDD2D3D4D5D6D7D8D9

RAWGNDRSTVCCA3A2A1A013121110

BLK

GND

VCC

RXI

TXO

A6A7

A4A5

店頭工場

部品工場１部品工場２

素材店１素材店２塗装屋

製品製造エネルギー＋流通エネルギー

流通を加味した製品環境負荷総量

製品製造環境負荷総量

製品製造エネルギー総量

部品１製造エネルギー総量

部品１環境負荷

素材１製造環境負荷

部品２製造エネルギー総量

部品２製造環境負荷総量

素材２製造環境負荷

塗料製造環境負荷

素材１製造エネルギー総量素材２製造エ

ネルギー総量塗料製造エネルギー総量

自律分散協調型の生産統合システムとINDUSTRY 4.0

ドイツのIndustry4.0はプロジェクトのクラスターであり、それ自体には規格化の提案を含め、アーキテクチャの革新はいまのところない。それどころか、ERPパッケージの延長上にサプライチェーン全般に渡るトレーサブルでトップダウンのクラウドサービスの方向にアーキテクチャは向いている様に見える。これは工場が、流通のフランチャイズ店と同様に、現場での改善が困難で、現場はケーパビリティデベロップメントのないオペレーションの場とされる工場のフランチャイズ化というリスクをもたらす。現在生じつつあるIoE革命は、物作りやサービス生産に関して新たなビジネスモデルの創出することが予想される。そこでは巨大化して現場の知を抑制したアーキテクチャの方向が現在のDBソリューションの延長で模索されつつも、他方でボトムアップでダウンサイジングされ、容易に改善や改変が可能な超多様で柔軟な自律分散協調的な産業構造への変革が模索され始めている。日本の製造業が生き残るには、多様でボトムアップな産業構造を可能とするアーキテクチャの構築が必須となる。

代数的多元簿記による会計測定の拡張

代数的多元簿記を用いて統合的にマルチアスペクトの会計記述が可能と

なる

多視点から詳細にコストや利益を展開したダブルエントリー記述

製造原価会計

シェアド・サービス会計

サービスチェイン会計

インフレ会計

環境会計（バッズ会計）

勘定科目＝状態の粒度を決める差異（分類）の体系

トランザクションの粒度：認識関心に応じてダブルエントリーのトランザクション記述の

粒度が異なる

組織の状態の可観測可制御

帰属価値会計

MFCAマテリアルフローコスト会計

物の流れを按分して、屑を製造プロセスの中で管理

生産の際に財の原価を投入から按分で管理

価格変動による価値の変化を管理

プロジェクト等サービス毎の原価を人的投入等の按分で管理

エネルギー・サービス会計

資本サービス会計

エネルギーが生成するサービスを見える化することでの利用管理

家計内やNPOなどの非市場的価値形成の帰属価値計算による見える化

産業廃棄物のようにマイナスの価値を持つ負債としての財を計上しての廃棄物管理

設備資本等の製品やサービスへの原価算入を製品やサービスに按分し管理

サービスコンポーネントの原価とそのチェインの原価の管理

ライフサイクルコスト会計

資本財などのライフサイクル価値を管理

【代数的多元簿記によるエネルギー会計情報の抽出】　エネルギーは一般的にコストとして間接計上される。これを切削加工サービスへの投入項目として扱うことで直接原価計算を行うだけでなく、更にに電力を用いた照明やエアコンなどのサービスに関しても、エアコンサービスや照明サービスを生成し、それを更に何かのサービスの生成に投入する、或は消費するとして扱うことで、エネルギー利用のプロファイリングを明確にすることができる。

情報処理に於ける二つの知On Site Knowledgeと

IT Base Knowledgeの関係＊IOE時代には、ユーザサイド、On Siteで人が理解しているビジネスプロセス、ワークプロセスと同型でかつ、絶えざるワークフローの組み替え（改善・プロセスイノベーション）にロバストに対応できる情報処理の実現が求められる。＊On Site 知によるシステム＝現実の絶えざるの組み替えの反対側に、IT側の知によるビジネスプロセス、ワークプロセ

スの標準化によるスレーブ化がある。

* データフローソリューションv.s.データベースソリューション

RDB

ERD

Entity-relationship Diagram, ERD

Business Logic on RDB by SQL

or on specific Computer

OR mapping

Web BasedService Oriented

Architecture

Domain Experts

ICT Experts

User Input & Data Use

Operator with or without Domain

Experts

ICTKnowledge

On SiteDomain

Knowledge

Slaving

データベースソリューションは現場の情報処理をERPパッケージの様に規範化する傾向が強く、現場の『改善』を認めないが結果としてエクセル等による現場コンピューティングが氾濫する。そもそも会計という相互主観的現実の上にERPは構築されたのが、現実の再構築機能がない方向に進化した恐竜型規格主義！出よほ乳類！！

Customer

Order

Product

Customer Number

Customer Name

Customer Adress

ProductCode

ProductName

ProductUnit Cost

OrderNumber

OrderDay

OrderQuantity

Customer Number

ProductCode

6F3<F12B?F/AE$��%��'��:081D04+'��@F.)E3;*)1'��&��"$�!�� #-=?7,F/AE��,F9:B5(:081>6C#��"�&G

Data Structure=Data Calculation Streaming

k7789K7900

screw 3mmcondenser 10F

Product Code Product Name

k8800 Switchx1 x2

Unit Price200 yen400 Yen800 Yenx3

Product Set A

CustomerSet B

C001C002

Suzukake TaroOoka Jiro

Customer Number Customer Name

C003 Tamachi Saburoy1 y2

AdressNagatsuda 4259Ookayama 2-12-1Shibaura 3-3-6y3

Order Set C

OR001OR002

2014122420150111

Order Number Order Day

OR003 20150214z1 z2

Quantity3510z3

C001C002

k7789k7900

Customer Number Product Code

C003 k8800z4 z5

6002000

Accounts receivableAccounts receivable

Quantity Accounts

8000 Accounts receivablew1 Accounts receivable

Quantity60020008000w1


Accounts

Switchz2

Credit Side Debit Side

OR001OR002


Order Number Product Name

OR003 Switchv1 v2

Quantity3510v3


Customer Name

Tamachi Saburov4

AdressNagatsuda 4259Ookayama 2-12-1Shibaura 3-3-6v5

Parcel Slip Set E

Transaction Set D

a1=k7789<product code, literal> + screw 3mm<product, literal> + 200<unit price, num>a2=k7900<product code, literal> + condenser 10F<product, literal> + 400<unit price, num>a3=k8800<product code, literal> + Switch<product, literal> + 800<unit price, num>a4=x1<product code, literal> + x2<product, literal> + x3<unit price, num>

Product_Set ⊂ {<x1,x2,x3> | x1∈Product Code Set、x2∈Product Name Set、x3∈Unit Price Set}= Product Code Set × Product Name Set × Unit Price Set

Product_Set={a1, a2, a3, a4,...}Customer_Set ⊂

{<y1,y2,y3> | y1∈Customer Number Set、y2∈Customer Name Set、y3∈ Address Set}= Customer Number Set × Customer Name Set × Address Set

Customer_Set ={b1, b2, b3, b4,...}

b1=C001<Customer Number, literal> + Suzukake Taro<Customer name, literal> + Nagatsuda 4259<address, literal>b2=C002<Customer Number, literal> + Ooka Jiro<product, literal> + Ookayama 2-12-1<address, literal>b3=C003<Customer Number, literal> + Tamachi Saburo<product, literal> + Shibaura 3-3-6<address, literal>b4=y1<Customer Number, literal> + y2<product, literal> + y3<address, literal>

Order_Set ={c1, c2, c3, c4,...}

c1=OR001<Order Number, literal> + 20141224<Order Day, literal> + 3<Quantity, num> + C001<Customer Number, literal> + k7789<product code, literal>c2=OR002<Order Number, literal> + 20150111 <Order Day, literal> + 5<Quantity, num> + C002<Customer Number, literal> + k7900<product code, literal>c3=OR003<Order Number, literal> + 20150214<Order Day, literal> + 10<Quantity, num> + C003<Customer Number, literal> + k8800<product code, literal>c4=z1<Order Number, literal> + z2<Order Day, literal> + z3<Quantity, literal> + z4<Customer Number, num> + z5<product code, literal>

Order_Set ⊂ {<z1,z2,z3, z4, z5> | z1∈Order Number Set、z2∈Order Day Set、z3∈ Quantity Set, z4∈ Customer Number Set, z5∈ Product Code Set}

= Order Number Set × Order Day Set × Quantity Set × Customer Number Set × Product Code Set

d1= 600<Accounts receivable, Yen> + 600^<screw 3mm, Yen>d2= 2000<Accounts receivable, Yen> + 2000^<condenser 10F, Yen>d3= 8000<Accounts receivable, Yen> + 8000^<Switch, Yen>d4= w1<Accounts receivable, Yen> + w1^<x2, Yen>where w1=x3×z3

Transaction_Set ={d1, d2, d3, d4,...}

Transaction_Set ={ x | x=a<Accounts receivable, Yen> + a^<b, Yen>, a=Pro[Unit Price](y)×Pro[Quantity](w)

b=Pro[Product Name](y), Pro[Product Code](y)=Pro[Product Code](w),

y∈Product_Set, w∈Order_Set }

e1=OR001<Order Number, literal> + screw 3mm<Product Name, literal> + 3<Quantity, num> + Suzukake Taro<Customer Name, literal> + Nagatsuda 4259<Adress, literal>e2=OR002<Order Number, literal> + condenser 10F <Product Name, literal> + 5<Quantity, num> + Ooka Jiro<Customer Name, literal> + Ookayama 2-12-1<Adress, literal>e3=OR003<Order Number, literal> + Switch <Product Name, literal> + 10<Quantity, num> + Tamachi Saburo<Customer Name, literal> + Shibaura 3-3-6<Adress, literal>e4=v1<Order Number, literal> + v2<Product Name, literal> + v3<Quantity, num> + v4<Customer Name, literal>> + v5<Adress, literal>

Parcel Slip_Set={ x | x=a1<Order Number, literal> + a2<Product Name, literal> + a3<Quantity, num> + a4<Customer Name, literal> + a5<Adress, literal>,

a1=Pro[Order Number](y), a2=Pro[Product Name](y), a3=Pro[Quantity](w), a4=Pro[Customer Name](z), a5=Pro[Adress](z)

Pro[Product Code](y)=Pro[Product Code](w), Pro[Customer Number](z)=Pro[Customer Number](w),

y∈Product_Set, z∈Customer_Set, w∈Order_Set }

Parcel Slip_Set={e1, e2, e3,...}

データフローソリューションは現場知からの情報処理を可能とする

!Product_Set ⊂ !

{<x1,x2,x3> | x1∈Product Code Set、x2∈Product Name Set、x3∈Unit Price Set}

= Product Code Set × Product Name Set × Unit Price Set

!a1=k7789<product code, literal> + screw 3mm<product, literal> + 200<unit price, num>!a2=k7900<product code, literal> + condenser 10F<product, literal> + 400<unit price, num>!a3=k8800<product code, literal> + Switch<product, literal> + 800<unit price, num>!a4=x1<product code, literal> + x2<product, literal> + x3<unit price, num>!

k7789K7900



k8800 Switchx1 x2


Product Set A

Product_Set={a1, a2, a3, a4,...} Customer_Set ={b1, b2, b3, b4,...}

C001C002





Customer_Set ⊂ !{<y1,y2,y3> | y1∈Customer Number Set、y2∈Customer Name

Set、y3∈ Address Set} = Customer Number Set × Customer Name Set × Address Set

!b1=C001<Customer Number, literal> + Suzukake Taro<Customer name, literal> + Nagatsuda 4259<address, literal>!b2=C002<Customer Number, literal> + Ooka Jiro<product, literal> + Ookayama 2-12-1<address, literal>!b3=C003<Customer Number, literal> + Tamachi Saburo<product, literal> + Shibaura 3-3-6<address, literal>!b4=y1<Customer Number, literal> + y2<product, literal> + y3<address, literal>!

CustomerSet B

Order_Set ={c1, c2, c3, c4,...}

OR001OR002

2014122420150111


OR003 20150214z1 z2

Quantity3510z3

!c1=OR001<Order Number, literal> + 20141224<Order Day, literal> + 3<Quantity, num> + C001<Customer Number, literal> + k7789<product code, literal>!c2=OR002<Order Number, literal> + 20150111 <Order Day, literal> + 5<Quantity, num> + C002<Customer Number, literal> + k7900<product code, literal>!c3=OR003<Order Number, literal> + 20150214<Order Day, literal> + 10<Quantity, num> + C003<Customer Number, literal> + k8800<product code, literal>!c4=z1<Order Number, literal> + z2<Order Day, literal> + z3<Quantity, literal> + z4<Customer Number, num> + z5<product code, literal>!

!Order_Set ⊂ !

{<z1,z2,z3, z4, z5> | z1∈Order Number Set、z2∈Order Day Set、z3∈ Quantity Set, z4∈ Customer Number Set, z5∈ Product Code Set}


Order Set C

k7789K7900



k8800 Switchx1 x2


Product Set A

CustomerSet B

C001C002





Order Set C

OR001OR002

2014122420150111


OR003 20150214z1 z2

Quantity3510z3

C001C002

k7789k7900


C003 k8800z4 z5

6002000

Accounts receivableAccounts receivable

Quantity Accounts

8000 Accounts receivablew1 Accounts receivable

Quantity60020008000w1


Accounts

Switchx2

Credit Side Debit Side

OR001OR002


Order Number Product Name

OR003 Switchv1 v2

Quantity3510v3


Customer Name

Tamachi Saburov4

AdressNagatsuda 4259Ookayama 2-12-1Shibaura 3-3-6v5

Parcel Slip Set E

Transaction Set D

a1=k7789<product code, literal> + screw 3mm<product, literal> + 200<unit price, num>a2=k7900<product code, literal> + condenser 10F<product, literal> + 400<unit price, num>a3=k8800<product code, literal> + Switch<product, literal> + 800<unit price, num>a4=x1<product code, literal> + x2<product, literal> + x3<unit price, num>

Product_Set ⊂ {<x1,x2,x3> | x1∈Product Code Set、x2∈Product Name Set、x3∈Unit Price Set}= Product Code Set × Product Name Set × Unit Price Set

Product_Set={a1, a2, a3, a4,...}Customer_Set ⊂

{<y1,y2,y3> | y1∈Customer Number Set、y2∈Customer Name Set、y3∈ Address Set}= Customer Number Set × Customer Name Set × Address Set

Customer_Set ={b1, b2, b3, b4,...}

b1=C001<Customer Number, literal> + Suzukake Taro<Customer name, literal> + Nagatsuda 4259<address, literal>b2=C002<Customer Number, literal> + Ooka Jiro<product, literal> + Ookayama 2-12-1<address, literal>b3=C003<Customer Number, literal> + Tamachi Saburo<product, literal> + Shibaura 3-3-6<address, literal>b4=y1<Customer Number, literal> + y2<product, literal> + y3<address, literal>

Order_Set ={c1, c2, c3, c4,...}


Order_Set ⊂ {<z1,z2,z3, z4, z5> | z1∈Order Number Set、z2∈Order Day Set、z3∈ Quantity Set, z4∈ Customer Number Set, z5∈ Product Code Set}


d1= 600<Accounts receivable, Yen> + 600^<screw 3mm, Yen>d2= 2000<Accounts receivable, Yen> + 2000^<condenser 10F, Yen>d3= 8000<Accounts receivable, Yen> + 8000^<Switch, Yen>d4= w1<Accounts receivable, Yen> + w1^<x2, Yen>where w1=x3×z3

Transaction_Set ={d1, d2, d3, d4,...}

Transaction_Set ={ x | x=a<Accounts receivable, Yen> + a^<b, Yen>, a=Pro[Unit Price](y)×Pro[Quantity](w)

b=Pro[Product Name](y), Pro[Product Code](y)=Pro[Product Code](w),

y∈Product_Set, w∈Order_Set }

e1=OR001<Order Number, literal> + screw 3mm<Product Name, literal> + 3<Quantity, num> + Suzukake Taro<Customer Name, literal> + Nagatsuda 4259<Adress, literal>e2=OR002<Order Number, literal> + condenser 10F <Product Name, literal> + 5<Quantity, num> + Ooka Jiro<Customer Name, literal> + Ookayama 2-12-1<Adress, literal>e3=OR003<Order Number, literal> + Switch <Product Name, literal> + 10<Quantity, num> + Tamachi Saburo<Customer Name, literal> + Shibaura 3-3-6<Adress, literal>e4=v1<Order Number, literal> + v2<Product Name, literal> + v3<Quantity, num> + v4<Customer Name, literal>> + v5<Adress, literal>

Parcel Slip_Set={ x | x=a1<Order Number, literal> + a2<Product Name, literal> + a3<Quantity, num> + a4<Customer Name, literal> + a5<Adress, literal>,

a1=Pro[Order Number](y), a2=Pro[Product Name](y), a3=Pro[Quantity](w), a4=Pro[Customer Name](z), a5=Pro[Adress](z)

Pro[Product Code](y)=Pro[Product Code](w), Pro[Customer Number](z)=Pro[Customer Number](w),

y∈Product_Set, z∈Customer_Set, w∈Order_Set }

Parcel Slip_Set={e1, e2, e3,...}




S

注文を入力する

データ入力




出庫係は情報を受取る


RDB


OR001OR002

2014122420150111


OR003 20150214z1 z2

Quantity3510z3

C001C002

k7789k7900


C003 k8800z4 z5

OR001OR002

2014122420150111


OR003 20150214z1 z2

Quantity3510z3

C001C002

k7789k7900


C003 k8800z4 z5

Order Set C

Order_Set ={c1, c2, c3, c4,...}


出荷伝票処理モジュール

発送ラベルの印刷

Subscribe

Subscribe Subscribe

Subscribe

Subscribe

Publish

k7789

K7900



k8800 Switch

x1 x2

Unit Price

200 yen

400 Yen

800 Yen

x3

Product Set A 製品コード表

Publish

C001

C002

Suzukake Taro

Ooka Jiro


C003 Tamachi Saburo

y1 y2

Adress

Nagatsuda 4259Ookayama 2-12-1Shibaura 3-3-6

y3

CustomerSet B 顧客コード表

データフローソリューションのプロジェクトプログラミングによる実装

標準化からデータの組み替可能なデータフローへ

データフローソリューションはワークフローに従うデータフローの形で情報処理を行う、現場にとって理解しやすく改変に関してロバストなソリューション

SourceData 1

Filter 1

Filter 2

Filter 3SourceData 2

SourceData 3

DerivedData 2 Derived

Data 3DerivedData 1

Filter 4

SourceData 4

SourceData 1

Filter 1

Filter 2

Filter 3SourceData 2

SourceData 3

DerivedData 2 Derived

Data 3DerivedData 1

DerivedData 4

＊下流にフィルター４やデータソース４を付け加えて未既存の計算に影響しない＊新たな計算方式の導入時も並列して従来の計算を走らせ比較できる。

様々なデータ計算とその結果

ADDLオブジェクト

AADLオブジェクト

Endode

decode

DCLパケット諸データEndode

decode

Pub Sub Scheme のパケットトピック DCLパケット

Pub Sub形式のパケット

バーチャルファクトリーに向けて

（１）工業集積の加工サービスノードと顧客と創造的企業を自律分散的に結びつけた、バーチャルファクトリーを、「ものづくりのファンドリーサービス」として仕組み化する。（２）ものづくりのプロジェクトをスケーラブルに可能とし、（３）創造的で小さな集団のサービス試作、リピート生産を可能とすることで起業を支援し、（４）それが同時にものづくりの中小企業を支えるインフラとなる仕組みを創成する。

ファブリケーションサービスのワークフローとタスク管理

タスクへのリソースマッピン

グとプロセスの管理

!これらはネットワークコーディネータが企業の壁を越えて行っていた。そのシステム化が必須

Start

Painting Task

NC MachineTask

Assembling Task

Metal Stamping Task

Laser Cutting Task

End

NC Machine

Assembling

Metal Stamping

Laser Cutting

Painting

Resource Allocation& Resource Management

Virtual Service Path Pattern

（３）エージェントシミュレーションとその言語SOARS

エージェントベースシミュレーションによるデバックとパーシャルデプロイメント型実装（１）実世界エージェント（ノード）のワークフローをシミュ

レーションすることで可能となる動的でバッキング（２）ワークフローを実装する際にシミュレーションノードと混在しながらテストするパーシャルデプロイメントという

新技術（３）最終的にシミュレータが設計ドキュメントとして残る

ことで可能となる長期的メンテナンス

ネットワーク上の仮想データバス

Agent

S

ACalc

Broker

Controller

Agent Base Modeling Agent Based Simulation

& Simulated Design

ACalc

Broker

Controller

S

Agent

Agent Base Modeling Partial Real World

Deployment by　Hybrid Simulation

Agent

S

ACalc

Broker

Controller

Agent Base Modeling Full Real World Deployment & Operation

Service System

実世界OSは、実世界のIOEエージェントの分散協調システム（サービスチェイン）をバーチャルなエージェントでシミュレートしデザインするだけでなく、シミュレーションしデザインした内容を、実世界にデプロイし、実世界のIOEエージェントからなるサービスチェインを管理するシステムで、エージェントベースの社会シミュレーション言語

SOARSの技術を実世界にまで拡張したもの

複雑なエージェントの自律分散協調型相互作用のシミュレーショ

実世界エージェントを交えたエミュレーションによるデプロイメント

超多様で小さなビジネスがサステイナブルな社会

実世界のエージェントの分散協調型相互作用を支援する実世界OSによるIOE時代の複雑なシステムのマネージ

リアルワールドOS関連の応用技術

エネルギー会計や、社会シミュレーション、災害時データ共有等でリアルワールドOS関

連技術は発展して応用されている

IOE製品市場化の先行事例• ロジカルワークスによるパブサブシステムとしての工場のデータ収集システム!

• ロジカル・ワークス株式会社!• http://www.logicalworks.co.jp

• ロジカルワークスによるパブサブシステムとしての工場のデータ収集システム!• http://www.logicalworks.co.jp

ボトムアップな工場のデータの共有は、シーケンサーから取得したデータをPub-Subの仕組みで共有することで簡単にできる

パブサブ対応のシーケンサー（開発中）

ヒータや送風機等を組み合わせてセンサーにより制御することでハウス農業の制御等も容易に

実現できる。

リアルワールドOSとプロジェクトプログラミングによって、オープンビジネスワークフローがボトムアップに構築される時代がやってくる！！

クラウド型の巨大仕組みビジネスに負けない超多様性世界を実現させるアーキテクチャ＊　アップルがI-Tuneストアをプラットフォームとして構築したことで、ビデオの販売店や、ソフトの販売店は激減した。 !＊　日本はこの四半世紀、要素ビジネスから仕組みビジネスに向かう流れに乗り遅れた。OSも言語も構築できなかった！！ !＊　IBMは要素としてのハードウェアもソフトウェアも切り離し、コンサルつまり仕組みビジネスの会社となっている。グーグルやアマゾンも同様。そこでは巨大クラウドでのロックインビジネスとコンポーネント型のビジネスモデルによる低付加価値低ケーパビリティコンポーネントが増殖している。 !＊　ものづくりの仕組みビジネスが、IOE時代には構築される。それは３Dプリンタや工場のセンサー化を超えて、工業集積のネットワークコーディネータが行っていた仕組みを、システム化するということ！！　これを海外に巨大なクラウドビジネスとしてやられたときが日本の製造業、製造クラスターの最後！　日本からボトムアップで改善と暖簾分けと能力開発を現場に許す仕組みビジネスデザインを世界に向けて提案するとき！

多様性のある内装工事のサービスワークフロー（複数）をイージオーダで設計・資源割当・施工管理を行う実

世界OSを利用したサービスオンデマンド　　電気工

　　配管工

　　床工

塗装工

　　壁貼り工

Start

Painting Task

Electric Task

Floor Construction

Task

Pipe Fitter Task

Wallpaper Worker Task

End

簡単なプロジェクトプログラミングの事例

東京オリンピックを控え多くの高次現場で海外労働者を含む高度で生産性の高い高次の施工管理が要求されている

個人の多様なリクエストに応える、様々な内装施工の組合せのイージーオーダーシステム

機能１：職人という資源をタスクへ割当てる。

機能２：実行できるタスクを管理し、タスクの遂行を支援する。

機能３：個々のタスクの原価等からワークフローのサービス原価を

求める。

Start

Leaving hospital Support

Task

HospitalizationProcedures

SupportTask

Pet Supportduring

hospitaliation Task

Home Maintenance

during hospitalization

Task

Life Supportduring

hospitalization Task

End

HospitalizationProcedures Support Business

Home Maintenance

Business

Pet Support Business

Life Support Business

Leaving hospital Support Business

タスクへの資源割り付けプロジェクトワークフロー

B2C型のサービスオンデマンド：高齢者の入院支援の様な個別的で多様なサービスをイージオーダで設計し、資源割当をし、遂行し、原価を計算する、実世界OSを利用したプロジェクト

プログラミングによるサービス設計。これが複数走るビジネスプログラムも支援する

機能１：個々のサービススペシャリストという資源をタスクへ割当る。

機能２：実行可能なタスクを管理し、タスクの遂行を支援する。

機能３：個々のタスクの原価等からワークフローのサービス原価を求

める。

従来コスト的に難しかった企業の壁を越えたサービスシステムの

IOE化

貢献度でサービス原価計算必要

サービスワークフローにタスクを遂行するエージェントを動的に割当てる

Start

Painting Task

NC MachineTask

Assembling Task

Metal Stamping Task

Laser Cutting Task

End

NC Machine

Assembling

Metal Stamping

Laser Cutting

Painting

Resource Allocation& Resource Management

Virtual Service Path Pattern

B2B(ワーク型)IOEサービスワークフロー*by*リアルワールドOS

!

外注タスク

!

外注タスク

複数の企業の加工サービスを繋ぎ合わせ組織の壁を越えたものづくりの、小ロット超多様なワークフローを設計し、タスクへの加工資源を割当てとその加工の遂行の管理運用を実世界OSが支

援する

ネットワークコーディネータが企業の壁を越えて行っていたシステムのIOE化

機能１：資源をタスクへ割当て機能２：実行できるタスクを管理し、

タスクの遂行を支援する。

機能３：個々のタスクの原価等からワークフローのサービ

ス原価を求める。

多様性のある内装工事のサービスワークフロー（複数）をイージオーダで設計・資源割当・施工管理を行う実世界OSを利用したサービスオンデマンド

　　電気工　　配管工

　　床工

塗装工

　　壁貼り工

Start

Painting Task

Electric Task

Floor Construction

Task

Pipe Fitter Task

Wallpaper Worker Task

End

B2B(ワーク型)IOEサービスワークフロー*by*リアルワールドOS

東京オリンピックを控え多くの高次現場で海外労働者を含む高度で生産性の高い高次の施工管理が要求されている

個人の多様なリクエストに応える、様々な内装施工の組合せのイージーオーダーシステム

機能１：職人という資源をタスクへ割当てる。

機能２：実行できるタスクを管理し、タスクの遂行を支援する。

機能３：個々のタスクの原価等からワークフローのサービス原価を求める。

Virtual Service Chain Library

EntrepreneurCreater

Co-CreationEntrepreneur

Entrepreneur

Customer

Entrepreneur

VirtualService ChainType A

VirtualService ChainType B

VirtualService Chain Type C

VirtualService Chain

Type D

VirtualService ChainType E

Service Node

Type 1Service Node

Type 2

NeedsDesign

Service Node

Type 3 Service Node

Type 4

Service Node

Type 5

Service Node

Type 1

Service Resource

Service Node

Type 3

Service Node

Type 6

Resource AllocationOrganizati

onal Boundary

Organizational

Boundary

創造的企業・デザイナー顧客協創

ニーズデザインバーチャルサービスでのサービスチェインのパターンライブラリー

サービス資源となるビジネスユニットの割当

1) バーチャルサービスは一種のファウンドリーサービス

!2) サービスの仕組みが、サービスのパスとしてライブラリー

化 !

3) サービス資源としての様々なビジネスユニットが組織の壁を越えて利用可能

!4) その割当とサービスパスの遂行をリアルワールドOSが支援

する

仕組みの試作を容易に行え、分散したノードの協力で小さくビジネスサービスを実現する

1) バーチャル工場は一種のファウンドリーサービス

!2) 設計製造プロセスが、製造サービスのパスとしてライブラリー化

!3) サービス資源としての様々な加工等の製造サービスが組織の壁を越えて利用可能

!4) その割当と製造サービスパスの遂行をリアルワールドOSが支援す

る

Virtual Factory Pattern Library

EntrepreneurCreater


Entrepreneur

Customer

Entrepreneur

Virtual Factory PatternType A

VirtualFactory PatternType B

VirtualFactory PatternType C

VirtualFactory PatternType D

VirtualFactory PatternType E

Assenbly Service Node

Type 3

MachineryService Node

Type 2

NeedsDesign

Machinery Service Node

Type 3


Type 2

Heating Service Node

Type 2


Type 1

Service Resource


Type 1

AssenblyService Node

Type 1

Resource Allocation

Organizational

Boundary

Organizational

Boundary

Organizational

Boundary

バーチャルファクトリーのものづくりのパターンライブラリー

ものづくりの資源の割当

顧客創造的企業・デザイナー

協創ニーズデザイン

1) バーチャル工場は一種のファウンドリーサービス

!2) 設計製造プロセスが、製造サービスのパスとしてライブラリー化

!3) サービス資源としての様々な加工等の製造サービスが組織の壁を越えて利用可能

!4) その割当と製造サービスパスの遂行をリアルワールドOSが支援す

る

Virtual Factory Pattern Library

EntrepreneurCreater


Entrepreneur

Customer

Entrepreneur

Virtual Factory PatternType A

VirtualFactory PatternType B

VirtualFactory PatternType C

VirtualFactory PatternType D

VirtualFactory PatternType E


Type 3


Type 2

NeedsDesign

Machinery Service Node

Type 3


Type 2


Type 2


Type 1

Service Resource


Type 1

AssenblyService Node

Type 1

Resource Allocation

Organizational

Boundary

Organizational

Boundary

Organizational

Boundary

バーチャルファクトリーのものづくりのパターンライブラリー

ものづくりの資源の割当

顧客創造的企業・デザイナー

協創ニーズデザイン

２０１６年インテル等の協力でリアルワールドOSコンソーシアムを設立し、サイバーフィジカル空間上で人・もの・ソフトを結ぶ自律分散協調型のワークフローの構築アーキテクチャを広く普及させていく予定！ぜひ参加を！２０１６年、工場ハッカソン＆アイデアソンをスタートさせます。あなたの工場で、ハッカソン＆アイデアソンを！！ Photo By Deguchi in the Yonaguni Island (Japan)

Step by Step, We walk, Hand to Hand, We transfer,!We have a dream to look the landscape beyond the hill,

someday

Thank You for Your Attention

I have reached here

You can reach beyond the hill

, 20151212 ioe社会のビジョンとその アーキテク...

Documents

, 20151212 ioe社会のビジョンとそのアーキテク...