IOE時代のマイクロサービスとそのオーケストレーションのため …€¦ ·...

IOE時代のマイクロサービスとそのオーケストレーションのためのアーキテクチャデザイン

東京工業大学　情報理工学院出口弘

[email protected]

May 19, 2016経済産業省分散戦略WG資料資料3

本日の発表の構成（１）クラウド領域でのビジネスワークフロー構築のためのアーキテクチャとのその限界 !

（２）フォグ領域でのビジネスワークフロー構築に必要とされること !

（３）マイクロサービスとそのオーケストレーションのためのアーキテクチャ !

（４）マイクロサービスオーケストレーションに於けるデータフローアーキテクチャと規格化 !

（５）マイクロサービスとそのオーケストレーションがもたらす新たな産業構造

クラウド領域でのビジネスワークフロー構築のためのアーキテクチャとのその限界

1

後付け的にカイゼンできるようなシステム構築にはデータベースソリューションは向かない

http://www.eljardindigita

l.com/en/project/internet-of-things/

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

クラウドベースのIoTが現状主流に見える

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

http://www.elertus.

com/oem/

http://aws.amazon.com/jp/iot/how-it-works/

IBM Amazon AWS IoT

https://www.lsr.com

GE Predix Cloud

https://www.predix.io

様々なマイクロなサービスとその結合を頻繁に書き換える継続的カイゼンを頑健に実施できるアーキテクチャが必要？

IoT Cloud Service

Solar Plant

Wind power　Plant

Oxygen

Weight

BloodPressure

blood-sugar

Ultrasonic Inspection

Thermometer

Blad Test

CT&MRI

How to describe Business Logic ??

Battery

Point of Energy Event

Point of Sales Event

Point of Life Log Event

Point of Health Care Event

Factory

Point of Sensing Event

無数の人・もの・ソフトウェアによるマイクロなサービスをネット上で結びつけたオーケストレーションが多様なビジネスワークフローを可能とする

現状、ネットワーク上でマイクロサービスをオーケストレーションするアーキテクチャへの関心が希薄です。

E-R図からRDB構築して、ORマッピングを経てビジネスロジックを組み立て、それをWEBベースの

SOA(Service Oriented Architecture)で利用するフレームワークでは、ソフトウェアのカイゼンサイクルは、１年以上であり（投資規模に依っては５年程度）、後付け的なカイゼンも難しく、仕様記述も難しく、現場

の知恵が反映させる枠組みになっていない。

Entity

Relation

Entity

Centralized DBEntity-relationship

Diagram, ERD

Top Down Business Logic

on DB

OR mapping

Web BasedService Oriented

ArchitectureDomain Experts

ICT Experts

Low CapabilityOperator

ICTKnowledge

On SiteDomain

Knowledge

Top Down

Design

No Loal Computing

Cloud Solution

No Local Continuous

Improvement (No Kiaizen)

Strong Standaization

IoTで「もの」のカイゼンのサイクルを、ソフトウェアの書き換えサイクルが遅いことが足を引っ張る

２

フォグ領域でのビジネスワークフロー構築に必要とされること

pwcの提唱するマイクロサービス概念は、我々の提唱するロールコンテナとプロジェクトプログラミングのアーキテクチャとは同じ方向を向いている。

PwC Technology Forecasthttp://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/assets/pdf/pwc-rethinking-integration-full-series.pdf

マイクロサービスというトレンド

http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/assets/pdf/pwc-rethinking-integration-full-series.pdf

PwC Technology Forecast

マイクロサービス＋コンテナというアーキテクチャ提案は従来のEAI(エンタープライズアプリケーションインテグレーション）が我々のいうマイクロサービスオーケストレーションへと置き換わるということを意味している。

これは我々がリアルワールドOSとして主張してきた事と同じ

P３８

http://www.pwc.com/us/en/technology-forecast/2014/cloud-computing/assets/pdf/pwc-rethinking-integration-full-series.pdfPwC Technology Forecast

pcwの技術予測でいう「マイクロサービス」は、我々がIoE時代のアーキテクチャとして主張してきたデータフローソリューションとプロジェクトプログラミング、それを支援するリアルワールドOSと極めて近い概念

P２３

マイクロサービスとそのオーケストレーションのためのアーキテクチャ

３

(1) マイクロサービスはロールコンテナに格納することでサービス間連携が可能になります。 (2) ロールコンテナ群を制御してオーケストレーションするのがプロジェクトプログラミング

ブラウンフィールドとしての実世界システムの開発には、既に存在する様々なひと・もの・ソフトの局所的なサービスを、相互にハンドシェイクしてオーケストレーションできるフレームワークに収納することが重要となる。そのための枠組みが

ロールコンテナ

Project Manager

Node ManagerOwlie

RWOS Developer Kit

ロールコンテナをオーケストレーションしワークフローをネット上で容易に構築できる枠組みがプロジェクトプログラミングとそのための

DSL（領域固有言語）のOWLIE

WWWRoleComponent

133V3AREFA0A1A2A3A4A55VRSTGNDVIN

12111098765432GNDRSTRX0TX1MISOSCKICSP

MOSIRX/LED

Role Container

ComponentAPI

ControlAPI

DataflowAPI

Brokerを経由してのデータ交換

ロールコンテナを起動させる

コンテナに収納されるコンポーネントWWWRole

Component



MOSIRX/LED

Role Container

ComponentAPI

ControlAPI

DataflowAPI



コンテナに収納されるコンポーネント

マイクロサービスを収納するコンポーネントとしてのロールコンテナ

３）MQTTブローカを経由してデータ転送するデータフロー

API

WWWRoleComponent



MOSIRX/LED

Role Container

ComponentAPI

ControlAPI

DataflowAPI



コンテナに収納される

コンポーネントWWWRole

Component



MOSIRX/LED

Role Container

ComponentAPI

ControlAPI

DataflowAPI



コンテナに収納される

コンポーネント

!２）役割の起動に関するControl

API

!１）ソフトウェアや人とのインタフェイスやマシンとのやり取りを規定するComponent API

ロールコンテナは、オープンアーキテクチャとして三つのAPIを持つ

マイクロサービスの色々WWWRole

Component



MOSIRX/LED

Role Container

ComponentAPI

ControlAPI

DataflowAPI



コンテナに収納されるコンポーネントWWWRole

Component



MOSIRX/LED

Role Container

ComponentAPI

ControlAPI

DataflowAPI



コンテナに収納されるコンポーネント

Role Contenner

API

DataflowAPI


DataflowAPI

ControlAPI


ControlAPI

職人に仕事の割当を通知したり進捗を受け取るマイクロサービス

ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



NC Machine

Role Contenner

API

Sensor

加工機械の稼働状況をセンシングして通知するマイクロサービス

ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



WWWData logger


12111098765432GNDRSTRX0TX1MISOSCK

ICSPMOSIRX/LED

Role Contenner

API

データ保管マイクロサービスEmergency Light

Role Contenner

API

警告灯表示のマイクロサービス

ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



Role Contenner

CalcNode

API

諸計算マイクロサービス

ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



Pub/SubPLC

Role Contenner

API

アクチュエータ・コントロールのマイクロサービスサービス

ControlAPI

DataflowAPI



ControlAPI

DataflowAPI



Show on Display

Role Contenner

API

データ共有用表示のマイクロサービスData Input

Role Contenner

API

Data Output

情報の入力や表示のマイクロサービス

　様々な既存の現場で必要とされるサービス群は、ロールコンテナに収納されることで、マイクロサービスとして相互に結び付けられます。

!　マイクロサービスは必要に応じて、現場の工夫で、小規模投資でどんどん付け加えられて進化します。

ロールコンテナを、ライブラリー化することで、容易にマイクロサービスの組合せをプログラミング

できる

Pub/Subによるメッセージ交換に基づくマイクロサービス間のデータ交換

ロールコンテナはひと・もの・ソフトからなる多様なサービスエージェントを収納し、メッセージバス上でのやり取りを支援する。

プロジェクトプログラミング言語OWLIEでは、ロールコンテナに収納されたマイクロサービス間の協調分散的な動作を、ステージモデルによりプログラミングし、ネット上での実行制御を行う

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

データ入力

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

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

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

会計処理モジュール

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

統計分析モジュール

データアーカイバ

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

制御用計算モジュール

統計分析モジュール

制御用計算モジュール

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

会計処理モジュール

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

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

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

をつぶやく

ツイッタからデータ取得

健康データ取得

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

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

Twitter

Polling new tweet

tweet

Intel Edison !!

MQTT Broker

Publish /cat/photo (+tweet ID)

Subscribe

Raspberry Pi

!Camera

Send the photo back

RWOS Role Container File Set

Analyzing Tweet

Convert to MQTT topic

Sensing Stage

Calculation StageExecution Stage

その他のアク• • • • • •

チュエータ• • • • • Motor, etc.

RWOS Role Container File Set

Camera controller

RWOS Project Manager

How is my cat doing?

遠隔でツイッタからの入力に基づき作業する３ステージモデル !・１：センシングはツイッタを代用して自然言語でのメッセージを取得 !・２：Intel Edisonで自然言語処理し、実行すべきコマンドを作成 !・３：Raspberry Piでコマンドを受けて、それを実行する。ここでは写真をとって報告

センシング・ステージ

計算ステージ

実行ステージ

マイクロサービス・オーケストレーションの事例：ネコマネージャ

自然言語を解析したコマンドに応じて色々な動作をさせる事ができる

User’s tweet (User’s will)

ツイートを分析しコマンドをMQTTにトピック付きで送る

センシング・ステージ

計算ステージ

実行ステージ

マイクロサービスオーケストレーションに於けるデータフローアーキテクチャ

と規格化

４

　代数的なデータ記述層を基盤として、データフローソリューションを用いる事で、後付けてき変更・カイゼンが容易でかつ大規模な規格化は不要になります。

SourceData 1

Filter 1

Filter 2

Filter 3SourceData 2

SourceData 3

DerivedData 2 Derived

Data 3

DerivedData 1

Filter 4

SourceData 4

SourceData 1

Filter 1

Filter 2

Filter 3SourceData 2

SourceData 3

DerivedData 2 Derived

Data 3DerivedData 1

DerivedData 4

上流のソースデータを明確にし、そこから出発し、計算Filterというマイクロサービスにより逐次導出されるデータ処理のストリームそのものがデータ構造であるという立場！

Figure １

Figure ２

図２のフィルター４とデータソース４は後付的に改善で追加してもプロセスに干渉しない

データフロー・ソリューションデータ構造=データの上流からのフィルター型計算のストリーム

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,...}

データフローソリューションは現場知に基づく絶えざるカイゼンを可能とする

We have to develop new information processing architecture that allow continuous change of

system called “Kaizen”.製品コード顧客住所

注文

会計伝票出庫伝票

データ構造=データの上流からのフィルター型計算のストリーム

計算フィルタ計算フィルタ

Transaction_Set ={d1, d2, d3, d4,...}d1= 600<Accounts receivable, Yen> + 3^<screw 3mm, Pieces>!d2= 2000<Accounts receivable, Yen> + 5^<condenser 10F, Pieces>!d3= 8000<Accounts receivable, Yen> + 10^<Switch, Pieces>!d4= w1<Accounts receivable, Yen> + z3^<x2, Pieces>!!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 ={ 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 }

6002000


Quantity Accounts




Accounts

Switchz2


Transaction Set D

(1) Algebraic Multi Dimensional Accounting

注文取引会計伝票計算の代数表現

会計伝票

計算フィルタ

OR001OR002



OR003 Switchv1 v2

Quantity3510v3


Customer Name

Tamachi Saburov4

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

Parcel Slip Set E

!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={e1, e2, e3,...}

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 }

出庫データテーブルの計算の代数表現

出庫伝票

計算フィルタ

＊プロジェクトプログラミングの３ステージモデルを用いることで、データフロー型のマイクロサービスオーケストレーションを、入出力や計算資源の割当等を含め実装することができる。

Calc Stage

Execution Stage

SensingStage

S

Ordering

Data Input

Calculation Node

Parcel Data Sharing on Display

3 Stage Project

Receiving Parcel Info.

Archiver

RDB

Accounting Filter Module

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,...}

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>

Calculating Filter of Parcel Data Module

Shipping Label Printing

Product Set A

Product Data Table

C001

C002

Suzukake Taro

Ooka Jiro

Customer Number Customer Name

C003 Tamachi Saburo

y1 y2

Adress

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

y3

CustomerSet B

Customer Data Table

Order Data Table

Data Algebra

Data Algebra

6002000


Quantity Accounts




Accounts

Switchx2


WWWMQTTPub/Sub

Account Receivable TableExchange Algebra

k7789

K7900


Product Code Product Name

k8800 Switch

x1 x2

Unit Price

200 yen

400 Yen

800 Yen

x3

Sub

Pub

Pub

SubPub

Sub

Pub

Sub

OR001OR002



OR003 Switchv1 v2

Quantity3510v3

Data Algebra

Data Algebra

Parcel Slip TableSub

Pub

WWWMQTTPub/Sub

（１）生産システムの加工機械等の設備自体の設計・導入・管理

（２）生産されるロット単位の製品の設計・生産・管理

　この二つの課題は連動し、（２）は（１）を前提とするが、両者は異なる

フェーズ。

生産システムでのマイクロサービスオーケストレーションの２つの課題

（１）は工場のIoT化のアーキテクチャ設計であり、これは一方でクラウド型のトップダウン型のシステムインテグレーションがある。他方でマイクロサービス・オーケストレーションは、絶えざるカイゼンが可能で後付け的生産システムの変更を許すアーキテクチャとなる。

（２）では、例えばロット単位の生産を行う際の、原価や生産方式の設計・実装・管理に関する、製品ライフサイクル管理（PLM）に関する、マイクロサービスオーケストレーションが課題。　実物簿記で生産タスクのプロジェクトを記述することで、データフローソリューションとしてこれを扱う事ができる。

簡単な生産のWF

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

塗装済完成品

プレス成形仕掛品��

切削加工切削加工

プレス工程

銅板材鉄板材

��

投入サービス

投入サービス

投入サービス

投入資材

投入資材投入資材

塗装工程

投入資材

投入サービス

塗料

銅板切削加工仕掛品

鉄板切削加工仕掛品

プレス加工サービス

塗装サービス

切削加工サービス

切削加工サービス

プレス成形仕掛品


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


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

銅板

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

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

生産資源制約

1 2

3

4

ロット単位の製番管理を製品ライフサイクル管理

（PLM）するためには、個々のタスクを実物簿記の代数的記述を行い、データフローソリューションを構築する必要があ

る

＊IoT時代にPLM：製品ライフサイクル管理システムは必須。＊代数的多元記述を上流としたPLMでは全体規格化は不要。＊論理的に等価なデータはデータフローソリューションでコンバート可能

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

価格データ

按分比率

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

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

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

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

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

環境会計

バッズ評価

生産管理情報

メイン＆サテライト会計情報

部品原料製品流通

User

家計内サービス生産

生産の境界

��

��

� ̀ ��

��

��! �

� ��

��

�� #"!

� ��

�� #"!

� ��

� #"℀

��

例

例

製品或は仕掛品の製造

プロセス

原料或は仕掛品

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

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

副産物(屑等)

MaterialInput

MaterialOutput

ServiceProcessInput

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

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

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

EquipmentWork &

Energy InputFab. Service

Output

サプライチェーンBOMによるトレーサビリティの確保

家計

マイクロサービスとそのオーケストレーションがもたらす新たな産業構造

５

１）第二次のインターネット革命としてのIoT革命では、マイクロサービスオーケストレーションによって低い資本コストで様々なサービスが構築可能です。２）小規模投資で多様なマイクロサービス対応機器が開発され、後付け的に改善可能な工場や地域のIoE化が可能となります！！！

限界費用ゼロ社会― <モノのインターネット>と共有型経済の台頭単行本 –

2015/10/27 ジェレミー・リフキン (著),

柴田裕之 (翻訳)

＊第一のインターネット革命でマスメディア等の巨大なコミュニケーションサービスへの対抗軸が構築された。 !＊第二次のインターネット革としてのIoT革命では、マイクロサービスオーケストレーションによって、ボトムアップに低い資本コストで様々なサービスが構築可能となる。 !＊即ち、従来の巨大な資本設備を必要とするビックビジネス型の製造や流通等の諸サービスに対する、新たな対抗軸がマイクロサービスオーケストレーション型のIoTインフラでは構築可能となる。 !＊類似の主張はリフキンやメレ等によってもなされてはじめている。

IoTマイクロサービスオーケストレーションがボトムアッップに産業構造を根底から変化させる

ビッグの終焉: ラディカル・コネクティビティがもたらす未来社会単行本 – 2014/1/10 ニコメレ (著), Nicco Mele (原

著), 遠藤真美 (翻訳)

IoE,IoT用のプログラミング言語も、開発環境も、コンテナ系の開発環境やそのための言語（DSL）も手掛けていません。通信路としてのMQTT Brokerを一部企業が手掛けているくらい。

日本におけるIoE時代のビジネス生態系の危機

センサー

CPUボード：インテルのエジソンや、Curie(キュリー)、或はアルディーノやラズベリーパイのようなIoE時代のベースになるボード

撤退

CPUチップやメモリー撤退

アプリケーション

ルネサスのSAKURA：影響力０

ここは本来オープンイノベーションが可能な領域で、戦略的にニッチを取るべき領域

OSでも、完全撤退。せめてIoE用のプラットフォーム環境といってもこれもなし。（Copy＆Developmentを除く）

撤退

やる気なし

!!!日本の企業が手掛けているのは生態系の端だけ

ここは基幹技術で必死でくらいつくべき領域だが実態は、大手は模倣か海外技術導入（Copy & Development）

* 我々は、現在工場等幾つ化のフィールドでリアルワールドOSの実証テストを始めており、これらの技術をオープン化して水平展開する為にリアル

ワールドOSコンソーシアムを立ち上げる予定。

!リアルワールドOSコンソーシアムで情報公開と共有活動をする　

20172016 20192018 2020

Real WorldConsortium

Real World OS

Foundation

FactoryHackathon

Supporting RWOS as Open Platform for IoE Business Eco System

RWOS beta release as Open Source trial version

POE data fare use Actas a new type of

Antimonopoly Act for Institutional Innovation

Non Profit RWOS

AllianceOpen Source Development

Alliance

Brown Field

MarketDevelopment

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

IOE時代のマイクロサービスとそのオーケストレーションのため …€¦ ·...

Documents

Transcript of IOE時代のマイクロサービスとそのオーケストレーションのため …€¦ ·...

IOE時代のマイクロサービスと そのオーケストレーションの ため …€¦ ·...

Documents

Transcript of IOE時代のマイクロサービスと そのオーケストレーションの ため …€¦ ·...

IOE時代のマイクロサービスとそのオーケストレーションのため …€¦ ·...

Transcript of IOE時代のマイクロサービスとそのオーケストレーションのため …€¦ ·...