1

Plattform Industrie 4.0 の管理シェルの概要
調査報告書

平成 30 年９月
ロボット革命イニシアティブ協議会
IoT による製造ビジネス変革 WG

2

【著者】
湯川久美子（Dr. Kumiko Gnibba-Yukawa）
 gnibba-y@prudentia-mr.com

2018 年 9 月

PRUDENTIA Marketing Research Ltd.（デュッセルドルフ）

3

目次
1

はじめに ................................................................................... 5

2

インダストリー4.0 と Plattform Industrie 4.0 ....................................... 7

3

4

2.1

インダストリー4.0 ....................................................................................... 7

2.2

Plattform Industrie 4.0 ............................................................................... 8

参照アーキテクチャモデル RAMI4.0 ............................................. 10
3.1

RAMI4.0 とは .......................................................................................... 10

3.2

第 3 軸 階層レベル ................................................................................. 13

3.3

第 2 軸 アーキテクチャ（レイヤー）.............................................................. 14

3.4

第 1 軸 ライフサイクル（価値の流れ） .......................................................... 15

管理シェルの概要 .................................................................... 17
4.1

管理シェル、アセット、I4.0 コンポーネントの関係 .......................................... 17

4.1.1

アセット ......................................................................................................... 17

4.1.2

管理シェル .................................................................................................... 18

4.1.3

I4.0 コンポーネント .......................................................................................... 20

4.2

管理シェルの構造 ................................................................................... 23

4.2.1

大まかな構造................................................................................................. 23

4.2.2

ヘッダー ....................................................................................................... 24

4.2.3

ボディー ....................................................................................................... 25

4.2.4

サブモデル ................................................................................................... 26

4.2.5

属性（Property）.............................................................................................. 27

4.2.6

ビュー .......................................................................................................... 28

4.3

サブモデルの例 ...................................................................................... 30

4.3.1

架空の活用シナリオ ........................................................................................ 30

4.3.2

サブモデル「MES 接続」................................................................................... 31

4.3.3

サブモデル「エネルギー効率」 .......................................................................... 32

4.3.4

サブモデル「ドリル」......................................................................................... 33

4

4.3.5

サブモデル「ドキュメンテーション」 ..................................................................... 35

4.3.6

サブモデルのデータフィールドの定義 ................................................................ 37

4.4

I4.0 コンポーネント間の通信 ..................................................................... 39

4.5

管理シェルの置き場所 ............................................................................. 40

4.6

管理シェルのユースケース（活用事例） ....................................................... 42

4.7

管理シェルの意義・メリット ........................................................................ 44

4.8

管理シェルが満たすべき要件 ................................................................... 46

4.9

管理シェルの開発と今後の展望 ................................................................ 49

4.9.1

管理シェルの詳細（形式） ................................................................................ 49

4.9.2

具体的な管理シェル（内容） ............................................................................. 52

5

米国中心の IIRA との比較 .......................................................... 54

6

参照文献 ................................................................................ 55

5

1 はじめに■ 抽象的で難解な Plattform Industrie 4.0 の文献
ドイツのインダストリー4.0 推進組織 Plattform Industrie 4.0 は 2016 年春、「Struktur der Verwaltungsschale（管理シェルの構造）」を発表した1。管理シェルにはインダストリー4.0 の世界を実現するための標準化したインターフェイスとして、重要な役割が課せられる。しかし、まだ開発の途上ということもあり理論的・抽象的な議論が中心で、具体性に欠ける。将来に渡ってありとあらゆるケースに対応できるよう、普遍性・拡張性・柔軟性を重要視しており、詳細な事項もみっちりと記載されている。そのため、要点・骨子がなかな
か見えてこない。また一般的に、ドイツ人はやるからには徹底的に（必要な全ての要素を含んだ）完全なシステムをつくろうとする傾向がある。アメリカ人はできるだけ簡単なソリューションを好むが、ドイツ人は複雑で難解なアプローチを重んじる。

■ 他の組織が管理シェルの具体例を発表
難解な文章に慣れたドイツ人であっても、Plattform Industrie 4.0 の作業に関わっていない部外者には、具体例がないとやはり理解しにくい。そこで、ドイツ電気電子工業連盟（ZVEI）のインダストリー4.0 作業グ
ループが 2016 年 10 月、分かりやすい例を用いて管理シェルの内容的な理解を深めるために、「I4.0 コ
ンポーネントの管理シェルの例」というホワイトペーパーを作成した2。このホワイトペーパーに記述されている具体例を本レポート（4.3 節）でも紹介する。また、スマートファクトリーの実証・研究プラットフォーム
SmartFactory KL も 2017 年 4 月にホワイトペーパーを発表し、いかにして管理シェルのコンセプトを同組織のインダストリー4.0 用モデル工場に適用できるか例示している3。

■ 分かりやすい Plattform Industrie 4.0 の最新資料
推進組織 Plattform Industrie 4.0 は先月（2018 年 8 月）、インダストリー4.0 の参照モデル RAMI4.0 と管理シェルに関するプレゼンテーション形式の資料を 2 点発表した4。管理シェルの現在の開発状況と今後の予定について要点が分かりやすくまとめてある。そこで、本レポートではこの最新プレゼンテーション資料をベースとし、冒頭に挙げた「管理シェルの構造（2016 年、ドイツ語版）」などを参照しながら肉付けした。その際、独仏伊の 3 ヵ国のインダストリー4.0 推進組織が共同で作成・発行した「管理シェルの構造（2018 年、英語版）」も、特にアップデートされている箇所について参考にした5。その他、「elektrotechnik（電気工学）」や「Computer & Automation（コンピューター＆オートメーション）」といったドイツの専門誌の記事も適宜引用。本レポートでは、図表や例を多用し、管理シェルの概要や意味・背景・意図を分かりやすく解説することに重点を置いた。

1

Plattform Industrie 4.0(2016)ZVEI – Zentralverband Elektrotechnik- und Elektronikindustrie (2016)
3
Technologie-Initiative SmartFactory KL (2017)
4
Plattform Industrie 4.0(2018a)、Plattform Industrie 4.0(2018b)
5
Plattform Industrie 4.0; Alliance Industrie du Futur; Piano Industria 4.0 (2018)2

6

表 1：本レポートのベースとなった資料

本レポート作成のために主として参照した文献【発行者】 Plattform Industrie 4.0【発行者】 Plattform Industrie 4.0【発行年】 2018 年 8 月【発行年】 2018 年 8 月【タイトル】 Die Verwaltungsschale im Detail - Von
der Idee zum implementierbaren Konzept（ドイツ語）【タイトル】 RAMI4.0 – Ein Orientierungsrahmen fürdie Digitalisierung（ドイツ語）（管理シェルの詳細 – アイデアから実装可能なコンセプトまで）（RAMI4.0 – デジタル化のためのオリエンテーション
補助）【発行者】 Plattform Industrie 4.0【発行者】 Plattform Industrie 4.0 など【発行年】 2016 年 4 月【発行年】 2018 年 3 月【タイトル】 Struktur der Verwaltungsschale Fortentwicklung des Referenzmodells für die
Industrie 4.0-Komponente（ドイツ語）【タイトル】 The Structure of the Administration
Shell: TRILATERAL PERSPECTIVES from France,
Italy and Germany（英語）（管理シェルの構造 – I4.0 コンポーネントのための参照モデルの発展）（管理シェルの構造 – フランス、イタリア、ドイツの 3
国の視点）【発行者】 ドイツ電気電子工業連盟（ZVEI）【発行者】 Technologie-Initiative SmartFactory KL【発行年】 2016 年 11 月

【発行年】 2017 年 4 月【タイトル】 Beispiele zur Verwaltungsschale derIndustrie 4.0-Komponente – Basisteil（ドイツ語）【タイトル】 Exemplarische Übertragung der RAMI
4.0-Verwaltungsschale auf die
SmartFactoryKLSystemarchitektur für Industrie
4.0-Produktionsanlagen（I4.0 コンポーネントの管理シェルの例 - 基本部分）（ドイツ語）（インダストリー4.0 生産工
場のためのSmartFactoryKL システムアーキテクチャへの RAMI
4.0・管理シェルの例示的な
適用）

72 インダストリー4.0 と Plattform Industrie 4.0
2.1 インダストリー4.0■ 企業の壁を超えてビジネスプロセスをネットワーク化
インターネットが広く普及し、簡単に低価格で利用できるようになった。また、AI 技術により機器がインテリジェントになってきている。この 2 つのトレンドを上手く活かせば、インダストリー4.0 の新しいサービスや機能の世界が開ける。現在すでに、クラウドやネットワーク、ネット接続できるオートメーション機器、インターネットを使ったサービスが存在する。企業や業界の垣根を超えて統一した標準をつくれば、ビジネスプロ
セス全体（バリューチェーン全体）をインターネットでつなげ、デジタル化した情報を隅々まで流せる。情報フローから付加価値が生まれ、（プラグ＆プロデュース、予知保全など）新しいビジネスモデルやアプリ
ケーションが創出される6。
図 1：インダストリー4.0 への発展

出所：Plattform Industrie 4.0 の資料を参考に独自作成

6

Plattform Industrie 4.0（2018a）

8

2.2 Plattform Industrie 4.0■ 産学官連携の推進団体•「官」 （ドイツ教育研究省、ドイツ経済エネルギー省）•「学」 （フラウンホーファー協会など）•「産」 （VDMA（ドイツ機械工業連盟）、Bitkom（ドイツ情報通信協会）、ZVEI（ドイツ電気電子工業
連盟）、多数の民間企業）

Plattform Industrie 4.0（プラットフォーム・インダストリー4.0）は、製造業のデジタル化を推進するドイツの中核組織。2013 年、情報通信、機械、電気電子のドイツの 3 つの工業会の共同プロジェクトとしてスタート。ドイツ政府による「ハイテク戦略 2020 年」の未来プロジェクト「Industrie 4.0」を発展・実践する意味合いがある。インダストリー4.0 では、情報通信技術、自動化技術、生産技術が結びついて相互作用するため、
3 つの工業会の連携が必要となった。
2015 年、同協会は企業、協会、労働組合、学術・政治機関にも門戸を開き、現在、産学官の約 160 団体が加盟する。民間企業の会員では、ボッシュ、SAP、シーメンス、ドイツテレコム、フエスト、ジック、フエニ
ックス・コンタクト、ハーティングなど、インダストリー4.0 の中核技術を担うドイツ企業が揃って会員となっている。同国の製造業を代表する自動車メーカー（フォルクスワーゲン、ダイムラー、アウディ）、機械メーカ
ー（トルンプ、フォイトなど）、自動車部品メーカー（シェフラー）、鉄鋼メーカー（ティッセンクルップ）、化学メーカー（BASF）なども会員に含まれる。その他、米国企業（IBM、インテルなど）、日本企業、中国企業など海外の企業も参加。英系法律事務所 Bird & Bird も加わっており、多彩な顔ぶれとなっている。

■ 製造業デジタル化のエコシステムの中心
Plattform Industrie 4.0 では自らを「製造業デジタル化のエコシステムの中心」と位置付ける。学術、産業、
政治、業界団体、労働組合が連携することで、社会全体のプロジェクトとしてインダストリー4.0 の成功を目指す7。製造業のデジタル化は、技術イノベーションから社会の変化まで幅広いテーマ分野に及ぶため、多方面のノウハウを束ねて連携することが欠かせない。同組織では下記の 3 つの活動を中心としている。
•

専門分野のノウハウ・技術を束ねる•

中堅・中小企業のサポート•

国際的な活動■ 6 つの作業グループ
Plattform Industrie 4.0 の‘心臓’は作業グループで、現在、表 2 に示す 6 つのグループがある。企業、職員団体、労働組合の代表者の作業フォーラムで、参加資格のある全ての者に門戸が開けれている8。

7
8

Plattform Industrie 4.0（2018a）
Plattform Industrie 4.0（2018a）

9【Plattform Industrie 4.0 の作業グループへの参加資格】•

専門知識や技術がある•

所属する組織から委任されている•（所属組織の）地域における乗数効果が期待できる

表 2：Plattform Industrie 4.0 の 6 つの作業グループ

Plattform Industrie 4.0 の作業グループ
作業グループ

テーマ

リーダー

AG1

参照アーキテクチチュア、標準、
規格化・標準化

Kai Garrels

AG2

技術、活用シナリオ

Johannes Kalhoff

AG3

ネットワークでつながったシステムのセキュリティ

Michael Jochem

AG4

法的な枠組みDr. Hans-Jürgen
Schlinkert

AG5

仕事、職業訓練、研修

Martin Kamp

インダストリー4.0 におけるProf. Dr.
SvenjaFalk（所属企業）ABB STOTZ-KONTAKT（オートメーション・産業用ロボットの世界的なメーカー、ABB グループの子会社）
フエニックス･コンタクト

AG6（産業用接続機器、インターフェース製品のメーカー）
ロバート・ボッシュ

デジタルのビジネスモデル（自動車部品、産業機器、電動工具、白物家電など複合テクノロジー企業）
ティッセンクルップ（鉄鋼・工業製品メーカー）
IG Metall（ドイツ最大の労働組合）
アクセンチュア
（コンサルティング会社）

出所：Plattform Industrie 4.0 の資料を参考に独自作成■ 管理シェルは作業グループ「AG1」が担当
作業グループ「AG1」がインダストリー4.0 の標準化・規格を担当しており、管理シェルのコンセプト開発も手掛けている。2017 年 10 月には「管理シェルデー（Tag der Verwaltungsschale）」を開催。10 のイニシア
ティブ（SmartFactoryKL など）や 70 人以上の専門家が参加した。参加したパートナー企業にはボッシュ、
シーメンス、SAP、IBM の重鎮も含まれる。
作業グループ「AG1」は管理シェルを段階的に開発しており、管理シェルについての記述や発表が複数回に分割して行われている。
【Plattform Industrie 4.0 による管理シェルに関する文献（抜粋）】•

Struktur der Verwaltungsschale（管理シェルの構造）•

Security der Verwaltungsschale（管理シェルのセキュリティー）•

Beziehungen zwischen I40.-Komponenten – Verbundkomponenten und intelligente Produktion（I4.0 コンポーネント間の関係、複合コンポーネントとインテリジェント生産）•

Weiterentwicklung des Interaktionsmodells für Industrie 4.0-Komponenten（I4.0 コンポーネントのための相互作用モデルの開発）

103 参照アーキテクチャモデル RAMI4.0
3.1 RAMI4.0 とは■ RAMI4.0 ＝ インダストリー4.0 の（標準化の）ためのガイダンス
前のページに記した通り、インダストリー4.0 の世界は標準化なしに実現しない。
【標準化 ＝ インダストリー4.0 の前提条件】•

インダストリー4.0 では、これまで分かれていた技術分野（生産技術、オートメーション技術、情報通信技術）が融合し、（サプライヤーや顧客など）他社ともインターネットを介してつながる•

企業、業界・分野の枠を超えてインターネットでつながり、バリューチェーンの全ての参加者の間で情報・データが流れる•

インダストリー4.0 の実現には、通信構造（ネットワーク、プロトコル）を始め、サイバーセキュリティ
やデータ保護、概念・専門用語・記号などの標準化が必要

推進組織 Plattform Industrie 4.0 は 2014 年 4 月、インダストリー4.0 のための参照アーキテクチチュアモ
デル「Reference Architecture Model Industry 4.0 （RAMI4.0）」を発表した。RAMI4.0 は、インダストリー
4.0 の全ての参加者・関係者が共通の見方、共通の理解を深め、標準化に向けて邁進するための共通のフレームワークである9。インダストリー4.0 の最も重要な側面を 3 次元の図にまとめている（各軸の詳細については 3.2～3.4 節を参照）。
図 2：インダストリー4.0 の参照アーキテクチチュアモデル「RAMI4.0」

出所：Plattform Industrie 4.0

9Plattform Industrie 4.0 (2018b)

11【RAMI4.0 の 3 軸】•

階層レベル（Hierarchy level）： ネットワークでつながった生産システムの階層レベル•

アーキテクチャ 「レイヤー」（Architecture ‘Layers’）： 情報通信工学的な階層構造•

ライフサイクル・価値の流れ（Life cycle & value stream）： アセット（機械・製品など）のライフサイクル

RAMI4.0 では複雑な関係性を可視化し、一口サイズの部分集合に分割することで、アセットをモデル化している（「アセット」が具体的に何を意味するか、次章 4.1.1 で解説する）。RAMI4.0 は管理シェルのベースでもある。Plattform Industrie 4.0 の現在のアプローチを反映する図を下記に示す10。
図 3：Plattform Industrie 4.0 の現在のアプローチ

出所：Plattform Industrie 4.0■ 参照モデルとは？
ドイツ技術者協会（VDI）/ ドイツ電気電子協会（VDE）が作成した「インダストリー4.0 用語集」によると、参照モデルとは「ある特定のモデルを導き出す・得るために、広く用いられ、目的に適っていると認められた、
奨励する性質のあるモデル」のことである11。技術分野（特に通信分野）ではそのような参照モデルは珍しくない。通信プロトコルのための 7 つの層からなる「OSI 参照モデル」が最も有名で、このモデルから派生した「DARPA モデル」や「TCP/IP プロトコル」なども知られる。

■ 手本はスマートグリッド分野の 3 次元モデル「SGAM」
上述の OSI 参照モデル、DARPA モデル、TCP/IP プロトコルなどは全て 1 次元のモデルだが、RAMI4.0
は 3 軸から構成されるサイコロ型の 3 次元モデルである。RAMI4.0 は 3 次元のスマートグリッド・アーキテ
1011

Plattform Industrie 4.0（2018a）
VDI/VDE-GMA(2017)12

クチャ・モデル（SGAM）を手本とした。Plattform Industrie 4.0 では「参照にされ、標準化・規格化に向けた議論を可能にするアーキテクチャ モデルは 3 次元にする必要がある」との結論に達したそうだが、複雑で見慣れない 3 次元モデルのため、RAMI4.0 の使用はドイツの組織や企業にとって「難題」となっている。

RAMI4.0 の手本となった「SGAM」とは？
•【概要】 スマートグリッド（次世代送電網）分野の 3 次元的に整理したアーキテクチャ モデル。このフ
レームワークは関係者の間で幅広く受け入れられ、スマートグリッドのシステムアーキテクチャの開発の際にも頻繁に用いられている•【開発・提案者】 2012 年、欧州レベルでスマートグリッドのシステムアーキテクチャの標準化を推進している 3 組織の合同団体によって提案された。この 3 組織とは、欧州標準化委員会（CEN）、欧州電気標準化委員会（CENELEC）、欧州電気通信標準化機構（ETSI）である•【目的】 スマートグリッドのシステムアーキテクチャの標準化を合理的に進めるために欧州共通のフレームワークを構築すること。このモデルを用いることで、欧州の様々な標準化・規格作成団体がスマートグリッド分野の重要な標準を特定し、空白部分を見付け出し、標準化に向けて邁進することができる。欧州仕様の作成、アメリカ国立標準技術研究所（NIST）仕様の見直し、規格作成団体への働きかけを合理的に進めようとしている

13

3.2 第 3 軸 階層レベル■ オートメーションの階層モデルを拡張
RAMI4.0 ではネットワークでつながる生産システムの粒度を表すために、7 つの階層レベル（Hierarchy
level）を定義している。ビジネス・製造システム統合の国際標準 IEC 62264 の階層レベルを拡張した形で、
イン ダストリー 4.0 の要 件を満 たすた めに 最 下層に 「 製 品 （Product ） 」 、最上層 に 「 つ ながる 世 界（Connected World）」を付け加えた12。
•

つながる世界（Connected World）•

企業（Enterprise）•

ワーク センター（Work Centers）•

作業ステーション（Station）•

制御装置（Control Device）•

フィールド機器（Field Device）•

製品（Product）

図 4：RAMI4.0 の第 3 軸（階層レベル）

出所：Computer&AUTOMATION

12

Plattform Industrie 4.0 (2018b)

14【インダストリー3.0 との相違】•

自社に留まらず、サプライヤーや顧客など他社の生産設備ともインターネットを介してつながる（‘Connected
World’ つながる世界）•

階層の垣根を超えて生産システムの全てのコンポーネントがつながり、全てのコンポーネントの間で通信が行われる（⇔ インダストリー3.0 では階層から階層に通信が行われた）•生産予定の製品（青写真、設計図）
や生産した製品が生産システムとネッ
トワークでつながる
出所：Plattform Industrie 4.0

3.3 第 2 軸 アーキテクチャ（レイヤー）■ IT 分野のやり方で複雑なシステムをレイヤーに分割
RAMI4.0 の第 2 軸では、生産システムの構成要素を情報通信工学的視点から 6 つのレイヤー（層）に分離している。オートメーション技術分野では馴染みの薄いアプローチだが、情報通信分野では複雑なシ
ステム/プロセスを複数のレイヤー（層）に分割する手法はよく用いられる（OSI 参照モデルなど）。こうする
ことで、ビジネスプロセス、機能記述、データイメージ、通信動作（QoS も含む）、アセットの統合の各側面が明瞭になる。

15

表 3：RAMI4.0 の第 2 軸（6 つのレイヤー）

RAMI4.0 の第 2 軸： 6 つのレイヤー
Business
ビジネス

組織とビジネスプロセス

Functional

提供する機能

機能

デ
ジ
タ
ル
の
世
界

Information

必要なデータ情報

ビジネスモデル （例：プラグ&プロデュース）•

アセットの全ての機能が含まれる•

下層の情報レイヤーからデータを得て、再び情報レイヤーにリターン•

アセットに関する全ての情報・データを含む•

従来、データは機能と一体化した要素とみなされていたが、（インダストリー4.0 の）データ駆動型システムではデータは情報とは別に考える•

通信インターフェース

情報へのアクセス•

他の I4.0 コンポーネントに情報を与え、他のI4.0 コンポーネントから情報を得る

Integration

物理的な世界から•統合

デジタルの世界への移行

例えば、物理量を電気的値に変換し、ある特定のフォーマットに従いコンピューター的数値に変
換する

Asset

物理的世界における•アセット

現実の‘もの’生産設備、機械、コンポーネント、部品、製品など

Communication
通信

物
理
的
世
界

•

出所：Plattform Industrie 4.0 の資料を参照に作成■ IT セキュリティは全レイヤーで
RAMI4.0 では、IT セキュリティのための単独のレイヤーを設けていない。セキュリティはインダストリー4.0と一体化した要素で、全てのレイヤーにセキュリティが関係することがその理由。

3.4 第 1 軸 ライフサイクル（価値の流れ）■ （機械など）アセットの最初のアイデアから解体・再生まで
RAMI4.0 の左側の軸は IEC 62890 に従って、アセット（機械など）の「ライフサイクル＆価値の流れ」を表す。その際、「タイプ（＝ 製品になる前の青写真・設計図・試作品）」と「インスタンス（＝ 製品）」に区別している。「タイプ」のフェーズにはアイデア創出から、設計やシミュレーション、プロトタイプ・試作までが含まれる。「インスタンス」のフェーズでは、前の段階で開発した製品（すなわち、「タイプ」の「インスタンス」）を生産する。生産までは大概、当該アセットの開発製造メーカー（例：機械メーカー）にて行われる。その後、製品は顧客（例：自動車メーカー）に納入され、顧客企業の生産システムに活用される13。
使用していた部品の生産中止、品質改良など、製品に関する変更が必要になると、まずは「タイプ（設計図・試作品）」にて変更が行われ、その後に「インスタンス（製品）」に反映され、新しい製品バージョンとなる。「タイプ」と「インスタンス」は全ライフサイクルを通してつながっている。

13

Plattform Industrie 4.0 (2018b)

16

表 4：RAMI4.0 の第 1 軸（ライフサイクル軸）

RAMI4.0 における（機械など）アセットのライフサイクル

Development

Maintenance, Usage

Production

Maintenance, Usage

開発

メインテナンス・活用

生産メインテナンス・活用‘タイプ’‘インスタンス’

【設計】

【手直し】

【製造】

【利用】

開発

ソフトウェアアップデート

製品

使用

設計

操作説明書

品質データ

サービス

コンピューター・シミュレ
ーション

製品変化

製造番号

保守

…

リサイクル

…

プロトタイプ試作…

…
開発製造メーカーにて
出所：Plattform Industrie 4.0 の資料を基に作成

顧客企業（工場）にて

17

4 管理シェルの概要
4.1 管理シェル、アセット、I4.0 コンポーネントの関係
4.1.1 アセット
■ アセット ＝ インダストリー4.0 の世界につなぐ必要のある‘もの’全て
ドイツ技術者協会（VDI）/ ドイツ電気電子協会（VDE）が作成した用語集「Industrie 4.0 Begriffe/Terms（2017 年 4 月）」では、アセットを「ある組織にとって価値のあるもの」と定義している14。推進組織 Plattform
Industrie 4.0 の古い資料では、Asset（財、アセット）ではなく「Gegenstand（物）」という呼称を用いていた。
インダストリー4.0 における「アセット」は幅広い意味合いを持ち、インダストリー4.0 のソリューションのためにネットワークへの接続を必要とする全ての‘もの’を意味する15。機械がアセットの代表例として挙げられる。
表 5：アセットの定義と意味

Industrie 4.0 における「アセット」とは名称

ドイツ語： Asset

英語： Asset

日本語： 財、アセット

旧称・別称

ドイツ語： Gegenstand

英語： Item

日本語： 物

公式な定義•

ある組織にとって価値のあるもの•

インダストリー4.0 のソリューションために接続を必要とする全ての‘もの’→ 生産設備の全ての階層の‘もの’（生産システム全体、個々の機械や作業ス
テーション、それぞれの機械の内部のコンポーネント・部品など）意味→ アセットには物質的な‘もの’だけではなく、（生産計画、注文書など）非物質的な‘もの’も含まれる
出所：Plattform Industrie 4.0 の資料を参考に独自作成■ 生産システムの全ての階層の‘もの’
前章 3.2 で示した通り、インダストリー4.0 では生産システムの全ての階層レベルがネットワークでつながり、全階層の‘もの’の間で通信が行われる。工場全体、作業ステーション、機械、機械の内部の部品、ス
イッチギヤ、電動機、チューブなど、全ての階層のありとあらゆる‘もの’が生産アセットになることができる。

14

15

VDI/VDE-GMA(2017)
Plattform Industrie 4.0(2018a)

18■ 非物質的な‘もの’も対象
アセットは物質的な‘もの’に限定されず、バリューチェーン上のパートナー企業と交換する必要のあるドキュメント（例：生産計画、注文書）など非物質的な‘もの’であってもよい。表 6 に示すように、多種多様な性質のものが含まれる16。
表 6：物質的・非物質的なアセットの例

Industrie 4.0 における「アセット」の例
設備（機械、キャビネット、コンピューター、アクチュエーター、ケーブル、コネクター、センサーなど）
原材料
物理的な
‘もの’

部品・コンポーネント・構成要素（ねじ、ホイールなど）
備品
消耗品（紙など）
製品（最終製品、半製品）

ソフトウェア（ファームウェア、アプリケーション、エンジニアリング設計ツールなど）

ドキュメント（データ媒体、ライフサイクルの情報管理など）

非物質的な（ライセンス、著作権、アイデア、計画、プロセス定義、標準、特許、基本手順、レシピ・処方、設備タイプ定義、製品タイプ定義、生産計画、プロジェクト計画、業務・ビジネス
手順、現状など）

‘もの’
情報
人間

（サービス技術者、プログラマー、機械の操作者など）サービス
出所：Plattform Industrie 4.0 の資料を参考に独自作成

4.1.2 管理シェル■ 管理シェル ＝ アセットをインダストリー4.0 の世界につなぐインターフェイス
前節で、アセットには物理的な生産設備（例：機械）や非物質的なドキュメント（例：生産計画）など、インダ
ストリー4.0 の世界とつなぐ必要のある‘もの’全てが含まれると記載した。物質的、非物質的に関わらず、それぞれのアセットをインダストリー4.0 の世界（インターネットでつながったデジタルの世界）に結び付けるのが管理シェルである。管理シェルは標準化された通信インターフェイスで、バリューチェーン上の全てのアセットとアセットが互いに通信できるようする17。
インダストリー4.0・デジタル化の時代には、（製造技術、オートメーション技術、情報通信技術など）これまで分かれていた技術分野や業界・業種が融合する。業種が異なるサプライヤーや顧客ともネットワークでつながる。従来、異なる分野・業界ではそれぞれ異なる標準・規格を使用してきたが、インダストリー4.0

16
17

Plattform Industrie 4.0; Alliance Industrie du Futur; Piano Industria 4.0 (2018)
Plattform Industrie 4.0(2018a)19の実現にはそれらを 1 つに束ねなくてはならない。統一したオープンなインダストリー4.0 の標準をつくり、
インダストリー4.0 のエコシステム内で異なるシステムやコンポーネントが全てスムーズに相互運用できるようにする必要がある。推進組織 Plattform Industrie 4.0 の管理シェルは相互運用性（インターオペラビリティ）への道を切り拓く18。

■ 管理シェル ＝ アセットの‘代理人’
それぞれの管理シェルの中に、そのアセット（機械など）に関する全ライフサイクルに渡る、全ての重要な情報やデータが収集・保存される19。管理シェルはインターネット上でアドレスで呼び出せ、そのアセット
が一意識別できる20。管理シェルはアセットの全情報への（制御可能な）アクセスを可能にする21。
表 7：管理シェルの定義と意味

Industrie 4.0 の「管理シェル」とはドイツ語：
Verwaltungsschale

名称
別称
公式な定義

英語： Administration Shell

日本語： 管理シェル

英語： Asset
administration shell (AAS)

日本語： アセット管理シェル（AAS）•

インダストリー4.0 システムにおける I4.0 コンポーネントのデジタルでアクティブな
仮想表現•

アセット（例：機械）とインダストリー4.0 の世界をつなぐインターフェイス→ 管理シェルにより、アセットがデジタルの世界に統合される→ 管理シェルはインダストリー4.0 対応の通信インターフェイスで、バリューチェーン上の全てのアセットの間の標準化された安全な通信を可能にする。
→ 管理シェルはインターネット上でアドレスで呼び出せ、アセットが一意識別できる→ 管理シェルはアセットの全ての情報への（制御可能な）アクセスを可能にする意味→ 管理シェルは（通信インターフェイスを持たない）‘受動的な’アセットも、バーコードや QR コードなどを介してデジタルの世界と結び付ける•

インダストリー4.0 の世界におけるアセット（例：機械）の仮想イメージ→ 管理シェルにはアセットの全ライフサイクルに渡る全ての重要な情報が含まれている→ 管理シェルはインダストリー4.0 の世界（インターネットでつながったデジタルの世界）で、アセットの‘代理人’の役割を果たす

出所：Plattform Industrie 4.0 の資料を参考に独自作成

18

Plattform Industrie 4.0(2018d)
具体例については表 19（43 ページ）参照
20
具体例については図 8（24 ページ）参照
21
アクセス権の具体例についてはの表 20（50 ページ）参照
19

20

4.1.3 I4.0 コンポーネント■ I4.0 コンポーネント ＝ アセット ＋ 管理シェル
前節で、管理シェルはアセットとインダストリー4.0 の世界をつなぐインターフェイスと説明した。管理シェ
ルが付け加えられ、インダストリー4.0（デジタル）の世界とつながったアセットが「インダストリー4.0 コンポーネント」、もしくは略して「I4.0 コンポーネント」と呼ばれる。アセットにサイバーフィジカルシステムの性質が備わり、インダストリー4.0 対応のコンポーネントとなる。I4.0 コンポーネント同士は社内、もしくは企業の壁を越えてインターネットを介して通信し合える22。
【サイバーフィジカルシステム】
サイバーフィジカルシステムとは、物理的な世界（実世界）にある多様なデータをセンサーネットワーク等で収集し、物理的な世界とサイバー世界の情報がリアルタイムで融合するシステムのことである。インダス
トリー4.0 では、モノのインターネット（IoT）で結ばれたサイバーフィジカルシステムの中で、人間、機械、設備、物流、製品などが直接、コミュニケーションを取り合い、協調して機能する。
図 5：管理シェル、アセット、I4.0 コンポーネントの関係（例：作業ステーション）

出所：Plattform Industrie 4.0 の資料を参考に独自作成
22

具体例については図 14（39 ページ）参照

21

表 8：I4.0 コンポーネントの定義と意味

Industrie 4.0 における「I4.0 コンポーネント」とは
名称

ドイツ語：
Industrie 4.0-Komponente

別称・略称

•

英語：
Industrie 4.0 component

日本語： インダストリー4.0
コンポーネント

英語：

日本語：

ドイツ語：

I4.0 component、

I4.0 コンポーネント、

I4.0-Komponente

Smart Manufacturingcomponent

スマート製造コンポーネン
ト

管理シェルとアセットからなる、世界のどこでも一意に識別可能な通信能力のある（CP24、CP34、もしくは CP44 に沿った）デジタル接続を有する、インダストリー4.0

公式な定義

システムの「参加者」で、定められた QoS(Quality of Service)の性質を持つサービスを提供する•

管理シェルを付け加えることで、インダストリー4.0 の世界（デジタルの世界）とつながった（機械などの）アセット

意味→ 管理シェルのおかげで、アセットにサイバーフィジカルシステムの性質が備わり、インダストリー4.0 対応のコンポーネントとなる→ I4.0 コンポーネントとなったアセット同士は社内、もしくは企業の壁を越えてイ
ンターネットを介して通信し合える

出所：Plattform Industrie 4.0 の資料を参考に独自作成■ 多種多様な I4.0 コンポーネント
各々の I4.0 コンポーネントが内包するアセットはすでに表 6（18 ページ）に示した通り、作業ステーション、
機械、機械部品、製品、ソフトウェア、人間、非物質的な‘もの’（例：生産計画、注文書）など、多種多様である。次ページの図 6 に、スマートファクトリーの実証・研究プラットフォーム SmartFactory KL のモデル
工場に I4.0 コンポーネント（＝アセット＋管理シェル）を適用した場合の例を幾つか示す23。

SmartFactory KL の概要•

SmartFactory KL は 2005 年、独カイザースラウテルン工科大学の生産自動化の専門家 Detlef Zühlke
教授によって設立•

未来の工場「スマートファクトリー」の研究開発プロジェクトを産学共同で実施するための、メーカーの垣根を越えた実証・研究プラットフォーム•

革新的な情報通信技術の活用を実証するためのモデル工場（生産現場の模擬環境）がある•

現在、民間企業や研究機関など 46 団体が加盟。シーメンス、ボッシュ、SAP、ピルツ、ハーティング、
フエスト、フエニックス・コンタクト、ワイドミュラーなどドイツのインダストリー4.0 分野の主要企業が名を連ねる、IBM、ファーウェイ（華為技術）、デンソーなどの外国企業も参加•

23

設立当初より、ドイツ人工知能研究センター(DFKI)とカイザースラウテルン工科大学と緊密に連携

Technologie-Initiative SmartFactory KL (2017)

22

図 6：SmartFactoryKL モデル工場における I4.0 コンポーネントの例

出所：SmartFactoryKL

23

4.2 管理シェルの構造
4.2.1 大まかな構造■ 管理シェルは開発途上
管理シェルの技術的な詳細につていは今現在まだ、Plattform Industrie 4.0 にて開発を進めている段階にある（詳細は 4.9 節に後述）。ただし、管理シェルの大まかな構造についてはすでにガイドラインが存在する。管理シェルの構造化の際にデジタルファクトリー（DF）の標準 IEC 62832 を参照にしている。同組
織では、「管理シェルはオートメーション分野と情報通信技術（ICT）分野のすでに確立したコンセプトに基づくと同時に、インダストリー4.0 の将来の発展にも備える必要がある」としている。

■ ヘッダーとボディから構成
管理シェルはヘッダーとボディから構成される。
図 7：管理シェルの一般的な構造

出所：Plattform Industrie 4.0

24

4.2.2 ヘッダー
■ ヘッダー： 管理シェルとアセットの ID
ヘッダーには、管理シェルとアセットを（世界中で一意に）識別できる情報（ID、識別子）が含まれている。この識別子（ID）には URL を用いることができる24。
下記に架空の例を示す。

図 8：ヘッダー内の管理シェルとアセットの ID（架空の例）

ヘ
ッ
ダ
ー

管理シェル

管理シェル

管理シェル

作業ステーション１

作業ステーション２

作業ステーション３

ID 管理シェル

http://www.zvei.de/demo/11232322

http://www.zvei.de/demo/11232342

http://www.zvei.de/demo/11282322

ID アセット[http://pk.festo.
com/3S7PLFDRS35][http://pk.festo.
com/3S7PL9X6K32][http://pk.festo.
com/3S7PLFNCKDZ]

出所：ドイツ電気電子工業連盟（ZVEI）

24

識別子（ID）に関する要件については 46、47 ページ参照

25

4.2.3 ボディー■ ボディー： サブモデルの集まり
ボディーは複数（多数）のサブモデルから構成される。それらのサブモデルを介して、アセットの様々な側面（例：セキュリティ面、安全面、エネルギー効率、ドリル能力、組立能力など）について記述することができる。
ある 1 つの側面（例：エネルギー効率）に関する情報は 1 つのサブモデルにまとめられる。ある 1 つの側面につき、サブモデルが１つ存在する。そうする
ことで、例えばサブモデル「ドリル」を介して、インダ
ストリー4.0 のネットワーク上で適した性能・特徴を備えたドリルを見付けることができる。
図 9：管理シェル内のサブモデル（架空の例）

出所：ドイツ電気電子工業連盟（ZVEI）

26

4.2.4 サブモデル（ドイツ語：Teilmodell、英語： Summodel、日本語：サブモデル）■ 基礎サブモデル、自由サブモデル
通常、ある 1 つの管理シェルはボディーの中に多数のサブモデルを含有する。各サブモデルは明確に定義された何か 1 つの分野・テーマ（例：エネルギー効率）を扱う。サブモデルは「基礎サブモデル」と「自由サブモデル」に分けられる。
•【（標準化された）基礎サブモデル】 インダスト
リー4.0 の世界のアセットの多くに適用される、共通のサブモデル（例：カタログデータなど）•【自由サブモデル】 バリューチェーン上の取引
企業の間で、ある具体的な用途のために取り決められるサブモデル■ すでにある様々な規格・標準にサブモデルで対応
すでに多数存在する様々な国際標準やコンソーシアムが策定した仕様を、管理シェルに反映させる必要がある。まさにこの目的のために、管理シェル内で多数のサブモデルを用いる。例えば、安全に関する
ISO 12100、ISO 13849-1、IEC 61508、IEC 61511、IEC 62061 といった標準・仕様がサブモデル「安全」の構成要素となり得る（図 10 参照）。
図 10：サブモデルと規格・標準の関係（架空の例）

出所：ドイツ電気電子工業連盟（ZVEI）

27■ サブモデル ＝ 階層に分類された属性（Property）の集合
各サブモデルは、階層に分類された多数の属性（Property）から構成される。アセットのデータ（仕様、性能）や機能など、アセットに関するあらゆる情報が属性となり得る。
図 11：サブモデルと属性（架空の例）

出所：Plattform Industrie 4.0

4.2.5 属性（Property）■ 具体的な属性についてまだ不明確
どの属性を管理シェルに含めるべきか、Plattform Industrie 4.0 にてまだ明確に定められていない。しかし、基礎属性、必須属性、任意属性、自由属性を区別する必要があることはすでに明らかになっている。
標準化された義務的な属性の他、それぞれのメーカーが独自の情報を自由属性として管理シェルに含めることができる25。

25•【基礎属性（Basic Property）】 標準化された必須の属性で、全ての管理シェルに適用される•【必須属性（Mandatory Property）】 標準化された必須の属性で、サブモデルに適用される•【任意属性（Optional Property）】 標準化された属性だが、サブモデルへの適用は任意•【自由属性（Free Property）】 （メーカーが定めた仕様など）限定された用途の属性

Plattform Industrie 4.0; Alliance Industrie du Futur; Piano Industria 4.0 (2018)

28■ 属性を介してアセットの情報を提供「属性」の概念は広義で用いられ、アセットに関する情報が全て含まれる26。
•（IEC61360-1、ecl@ss が意味する）製品特性•

プロセス変数、プロセスパラメータ、テレメトリデータ•

外部のデータソースやファイルへのリンク（参照先）•

他の管理シェル、他のサブモデルや属性へのリンク（参照先）•

アセットの能力・性能、呼び出し方法の記述•

属性の集合（例：リスト、表）など。
アセットの仕様・性能、機能、現在の状態、過去の出来事など、アセットの全ライフサイクルのありとあらゆ
る情報が属性として提供される。管理シェルは属性を介して、アセットからのランタイム情報（例えばサーボ増幅器の実際位置、実電流など）を記録し、提示することもできる。サブモデルにおける属性の具体例
は次節 4.3 で示す。
図 12：サブモデル内の属性（架空の例）

出所：Plattform Industrie 4.0

4.2.6 ビュー
■ ビュー： 各ユーザーグループに必要な情報のみ提供
前項に記したように、管理シェルはサブモデルの属性（データ、機能）を介して、アセットのありとあらゆる情報を提供する。しかし、その情報の全てがバリューチェーン上の全ての参加者に一様に重要なわけではない。例えば、アセットのドキュメンテーションは「設計」に携わる人たちには重要だが、「ビジネス」のレベルでは必要性が低い。それぞれのユーザーグループが必要な情報のみ見られるように、「ビュー（View）」を設定する。図 13 に示すように、ビューは複数の属性から構成される。それぞれの属性には 1
つ、もしくは複数のビューがあてがわれる27。通常、 各属性のビューへの割り当ては当該アセットの製造メ

26
27

Plattform Industrie 4.0(2018a)
Plattform Industrie 4.0（2016）29

ーカーが行う28。ビューを用いることで、ユーザーはアセットに関する大量の情報に溺れることなく、必要な情報のみ見られ、利便性が向上する。
図 13：ビューと属性の関係

出所：Plattform Industrie 4.0 の資料を基に独自作成

次節 4.3 の表 9～12、15（31～35 ページ）を見ると分かるように、サブモデルのデータフィールドには「ビュー」が含まれている。サブモデル「MES 接続」の架空の例では、「アセットの生産状況」の属性には「ビジネス」のビュー、「アセットの運転時間」の属性には「性能」のビューがあてがわれている。

■ 基礎ビューと追加のビュー
Plattform Industrie 4.0 では下記の「基礎ビュー29」を定めている30。
•

ビジネス（Business）•

設計（Construction）•

性能（Performance）•

機能（Function）•

位置（Location）

上記の基礎ビューの他、必要に応じて管理シェルに追加的なビューを含めることも可能。

28

Plattform Industrie 4.0; Alliance Industrie du Futur; Piano Industria 4.0 (2018)
IEC CDV 62890（“Industrial-process measurement, control and automation – Life-Cycle-Management for systems andcomponents”）にて定められている「5 つの典型的なグループ」が基礎ビューとなっている。
30
Plattform Industrie 4.0（2016）、Plattform Industrie 4.0; Alliance Industrie du Futur; Piano Industria 4.0 (2018)29

30

4.3 サブモデルの例■ ドイツ電気電子工業連盟が作成した具体例
推進組織 Plattform Industrie 4.0 が 2016 年 4 月、「管理シェルの構造」を発表したが、抽象的で理解しにくい。そこで、ドイツ電気電子工業連盟（ZVEI）のインダストリー4.0 作業グループは 2016 年 10 月、分
かりやすい例を用いて管理シェルの内容的な理解を深めるために、「I4.0 コンポーネントの管理シェルの例」というホワイトペーパーを作成した31。
このホワイトペーパーに記載された 4 つのサブモデルの例を 4.3.2～4.3.5 項に紹介する。この例はファク
トリー・オートメーションとプロセス・オートメーションの両方の産業向けに作れている。ただし、あくまでも抽象的な管理シェルを分かりやすい架空の例を用いて説明することが目的で、現実のサブモデルの内容を反映するものではない。また、分かりやすくするために、標準化に向けた現在の動向も反映していない。

4.3.1 架空の活用シナリオ■ 競合する 3 つの作業ステーション
本例では、製造注文を巡って競合する 3 つの似通った I4.0 コンポーネント「作業ステーション」があると仮定する（下図参照）。それぞれ管理シェルを介して上層の製造実行システム（MES）と I4.0 対応の通信でつながっている。製造実行システム（MES）は製造注文を巡る、この 3 つの I4.0 コンポーネントの間の市場競争を統括し、さらに製造実行を制御する。
本例では架空のサブモデルを 4 つ用いる。
•

MES 接続： 作業ステーション
を上層の製造実行システム（MES）とつなぐ•

エネルギー効率： センサーなどを介して集取した電力消費量などの情報を提供する•

ドリル： ドリル（穴あけ）工程を開始・停止・シミュレーション
するためのデータや機能を含む。デモンストレーターにて作動状況を表示するために外部のアクチュエーターを制御することも可能•

31

ドキュメンテーション： PDF など複雑なデータをドキュメントとして保管する

ZVEI(2016)31

4.3.2 サブモデル「MES 接続」■ 作業ステーションを MES とつなぐ
サブモデル「MES 接続」は、属性を介してそれぞれの作業ステーションを上層の製造実行システム（MES）とつなぐ。例えば、作業ステーションが現在、生産中、準備中、故障中、整備中なのか提示する。表 9 の
架空のサブモデルでは MES への接続を簡素化した方法で示しており、機械の現在の状況のみ記述している。このサブモデルは 2 つの属性「アセットの生産状況」と「運転時間」から構成されている。
（※ 実際のサブモデルの作成にあたっては、ドイツ電気電子工業連盟（ZVEI）の作業グループ「MES」による定義などを参照する必要がある）
表 9：サブモデル「MES 接続」（架空の例）
属性（Property）の定義
階層

|

|

ID

AAA020AAA021

単位

ﾃﾞｰﾀ
ﾀｲﾌﾟ

値リスト

値

役目

比較
演算子

ビュー

R/D/
F/A/-

備考

ENUM

[遊休状態、
運転中、
故障中、
拘束中、
計画的停止、
計画外停止]

運転中

測定

等しい
(=)

ビジネス

D

-

153453 s 測定

等しい
(=)

性能

D

-

名称

定義

アセットの
生産状況

この属性は、
当該アセットが生産タスクを
実行可能か
提示する

運転時間

この属性は、
当該アセットが累積でどのぐらいs（秒） INT64の時間オンになっているか提示する

n/a

属性（Property）の表示

0..*

出所：ドイツ電気電子工業連盟（ZVEI）

上記の表に示したサブモデル「MES 接続」のデータフィールド「属性（Property）の表示」については、下記の表を参照のこと。「属性（Property）の定義」に関しては表 18（37 ページ）に後述する。
表 10：サブモデルのデータフィールド（架空の例）

属
性
の
定
義

データフィールド

英語の名称

解説

必須/任意

例

階層

Hierarchy

サブモデルの属性の階層的な構造を可能にする

必須

+-+

ID

ID

（表 18 参照）

必須

名称

Preferred name

（表 18 参照）

必須

定義

Definition（表 18 参照）

必須

単位

Unit of measure（表 18 参照）

必須、
n/a（該当なし）
でも OK

データタイプData type（表 18 参照）

必須

値リスト

Value list

（表 18 参照）

必須、
n/a（該当なし）
でも OK

32

値

属
性
の
表
示

Value

現在の値

任意

2250 1/min
要請（Requirement）、確認（Confirmation）、
測定（Measurement）

通信（インターアクション）の際の当該属性の役割
必須、•
要請（承認または拒否が必要な照会）
n/a（該当なし）•
確認（アセットの能力に関する照会）でも OK•
測定（測定値の提供）

役目

Expression
semantic

比較演算子

Expression
logic

比較する必要がある場合に用いるべき比較演算子

任意等しい（=）、
以上（≧）、
以下（≦）

ビュー

View

当該属性にあてがわれたビュー

必須

ビジネス

必須、
n/a（該当なし）
でも OK

F

必須、
“-”でも OK

IEC 61131 に基づいた
次の 61131 対応の制御に利用すべき
機能ブロック・ライブラリー

備考欄に何が含まれているか示す•
R：参照
R/D/F/A/- R/D/F/A/•
D：複雑なデータ内容
•
F：機能
•
A：注記
•
•
備考

参照（R）の場合： 参考にするもの
データ内容（D）の場合： フォーマットな
どの参照先
機能（F）の場合： 機能の内容、使用される場所など注記（A）の場合： 当該属性に関する単なるコメントやメモ•

Contents•

出所：ドイツ電気電子工業連盟（ZVEI）

4.3.3 サブモデル「エネルギー効率」■ エネルギー効率に関する情報提供
サブモデル「エネルギー効率」は、（センサーなどを用いて収集可能な）エネルギー効率に関する情報を提供する。下記の架空のサブモデルでは、現在のエネルギー消費量が属性→サブモデル→管理シェル
を介して提示可能なことを示す。このサブモデルは計 9 つの属性から構成されている。
表 11：サブモデル「エネルギー効率」（架空の例）
属性（Property）の定義

属性（Property）の表示

名称

定義

単位

ﾃﾞｰﾀ
ﾀｲﾌﾟ

値リスト

値

役目

比較
演算子

ビュー

R/D/
F/A/-

備考

+-- AAB010

電気
エネルギー

電気エネルギー
消費に関する
属性のグループ

n/a

n/a

n/a

n/a

n/a

n/a

性能

n/a

-

|

電力消費量
（実際）

現在の実際の
電力消費量

W

REAL

0..*

93.6 [W]

測定

等しい
(=)

性能

n/a

-

電力消費量
--| AAB012 （累積エネルギ
ー）

累積の
電力消費量

Wh

REAL

0..*

118.86 [Wh]

測定

等しい
(=)

性能

n/a

-

A

XML 協定世界時（UTC）時刻フォーマットに関してはhttps://www.w3schools.com/xml/schema_dt
ypes_date.asp
を参照のこと階層

ID

AAB011--| AAB013

電力消費量 電力消費量の累計
n/a（累積開始日） を開始した日時.

UTC
Date &
Timen/a

2002-05等しい
測定
30T09:30:10Z
(=)

性能

33

+-- AAB020

空気
エネルギー

空気エネルギー
消費に関する
属性のグループ

n/a

n/a

n/a

n/a

n/a

n/a

性能

n/a

-

--| AAB021

実際の
供給圧力

アセットの吸気口で検知したアセットの bar
供給圧力

REAL

0..*

8 [bar]

測定

等しい
(=)

性能

n/a

-

--| AAB022

空気消費
（実際）

現在の実際の
空気消費量

l/h

REAL

0..*

212 [l/h]

測定

等しい
(=)

性能

n/a

-

累積の
空気消費量

l

REAL

0..*

3424 [l]

測定

等しい
(=)

性能

n/a

-

空気消費
空気消費量の累計
n/a（累積開始日） を開始した日時

UTC
Date &
Timen/a

2002-05等しい
測定
30T09:30:10Z
(=)l

性能

n/a

-

空気消費量
--| AAB023 （累積エネルギー）--| AAB024

出所：ドイツ電気電子工業連盟（ZVEI）

4.3.4 サブモデル「ドリル」■ ドリル工程の開始、停止、シミュレーション
サブモデル「ドリル」には、ドリル（穴あけ）工程を開始、停止、シミュレーションするための複数の情報や機能が含まれている。デモンストレーターにて作動状況を表示するために外部のアクチュエーターを制御することも可能。表 12 の仮想のサブモデルでは、アセットの能力を「確認」するための属性をどのように設定するか、シミュレーションやプログラム実行の機能をどのようにアクティブにするか示している。
表 12：サブモデル「ドリル」（架空の例）
属性（Property）の定義

属性（Property）の表示

階層

ID

名称

定義

単位

ﾃﾞｰﾀ
ﾀｲﾌﾟ

値リスト

値

役目

比較
演算子

ビュー

R/D/
F/A/-

備考

|

AAC001

ドリル工具
直径
最大

使用可能なドリル
工具の最大直径

mm

REAL

0..*

12 [mm]

確認

より小さ
い（＜）

性能

n/a

-

|

AAC002

ドリル
回転毎分
最大

ドリルの最大回転毎分

1/min REAL

0..*

2000 [1/min] 確認

より小さ
い（＜）

性能

n/a

-

同期関数
呼び出し、
入力パラメータ(AAC004..
AAC007)を得て、1 つの実数（REAL）を返答

シミュレーショ
F-= AAC003
ン
ドリル時間

シミュレーションや推定による
全ドリル工程の工程所要時間

sec

REAL

0..*

0.21 [sec]

確認

より小さ
い（＜）

性能

F

--| AAC004

ドリル工具
直径

使用する
工具の直径

mm

REAL

0..*

5 [mm]

要請

等しい
(=)

性能

n/a

--| AAC005

ドリル
送り速度

使用する
送り速度

mm/s
REAL
ec

0..*

3 [mm/sec]

要請

等しい
(=)

性能

n/a

--| AAC006

ドリル
深さ

ドリルする
深さ

mm.

REAL

0..*

8.2 [mm]

要請

等しい
(=)

性能

n/a

--| AAC007

加工対象物
材料

ドリルする
材料の分類

n/a

®
CAA001n/a

CAA005

要請

等しい
(=)

性能

n/a

34

F-= AAC008

ドリル
プログラム
開始

予め設定したドリルプログラム
を開始

n/a

®
CAB001

n/a

n/a

n/a

n/a

性能

F

--| AAC004

ドリル工具
直径

使用する
工具の直径

mm

REAL

0..*

5 [mm]

要請

等しい
(=)

性能

n/a

--| AAC005

ドリル
送り速度

使用する
送り速度

mm/s
REAL
ec

0..*

3 [mm/sec]

要請

等しい
(=)

性能

n/a

--| AAC006

ドリル
深さ

ドリルする
深さ

mm

REAL

0..*

8.2 [mm]

要請

等しい
(=)

性能

n/a

--| AAC007

加工対象物
材料

ドリルする
材料の分類

n/a

®
CAA001n/a

CAA007

要請

等しい
(=)

性能

n/a

--| AAC009

ドリル位置
X

ドリルする
X 座標

mm

REAL

0..*

12 [mm]

要請

等しい
(=)

性能

n/a

--| AAC010

ドリル位置
Y

ドリルする
Y 座標

mm

REAL

0..*

42 [mm]

要請

等しい
(=)

性能

n/a

F-= AAC011

ドリル
プログラム
停止

現在の
ドリルプログラム
を停止

n/a

®
CAB001

n/a

n/a

n/a

出所：ドイツ電気電子工業連盟（ZVEI）

本例では、材料の分類（ID：AAC007）も属性を介して行っている。
表 13：材料の分類（架空の例）
階層

ID

名称

+

CAA001

材料+-+

CAA002

金属+-+-+

CAA003

非合金+-+-+-+

CAA004

鉄鋼+-+-+-+-|

CAA005S275JR+-+-+-+

CAA006

アルミニウム+-+-+-+-|

CAA007

AW-6060+-+-+-+-|

CAA008AW-7020+-+-+

CAA009合金+-+-+-+CAA010銅+-+-+-+-|CAA011

CR004A

出所：ドイツ電気電子工業連盟（ZVEI）

定義

n/a

性能

F

非同期的に
ドリルプログラム
を開始し、
即座に成功
（success）/
エラー（error）を
返答

非同期的に
ドリルプログラム
を停止し、
即座に成功
（success）/
エラー（error）を返答

35

下記の表はプログラム実行の成否の一般的な分類を示す。成功/失敗の分類が簡単に確認でき、同時に詳細なエラーメッセージを表示するためには階層をつくる必要がある。
表 14：成功/不成功の分類（架空の例）
階層

ID

名称

定義

|

CAB001

OP OK

操作成功

+

CAB002

OP NOK

操作失敗

OP INV

操作失敗、前提条件が無効/満たされていなかったため+-|

CAB003

出所：ドイツ電気電子工業連盟（ZVEI）

4.3.5 サブモデル「ドキュメンテーション」■ 複雑なデータをドキュメントとして保管
サブモデル 「ドキュメンテーション」では、PDF など複雑なデータをドキュメントとして保管する。表 15 の仮
想のサブモデルでは、複雑なデータ要素をどのようにして収めるか示している。
（※ 実際のサブモデルを定義にあたっては、VDI 2770、AK Produktdaten、“dublin core“などが参照可
能）
表 15：サブモデル「ドキュメンテーション」（架空の例）
属性（Property）の定義

属性（Property）の表示

名称

定義

単位

ﾃﾞｰﾀ
ﾀｲﾌﾟ

値リスト

値

役目

比較
演算子

ビュー

R/D/
F/A/-

備考

+-- AAD001

ドキュメントアイテム

ある 1 つのアイテムに関する
複数の属性の
グループ.

n/a

属性の
セット

n/a

n/a

n/a

n/a

設計

A

同じ ID
“AAD001”を持つ
複数のアイテムも可能--| AAD002

アセット ID

ドキュメントアイテムの関連する n/a STRING
アセットの IDn/a

http://
等しい
pk.festo.com 確認(=)
3S7PLFDRS35

設計

A

管理シェルに
1 つのアセットしかない場合、
デフォルトは“”--| AAD003

ドキュメントアイテム
種類

ドキュメントの種類

n/a®
CAC001

n/a

等しい
(=)

設計

n/a

-

--| AAD004

ドキュメントアイテム
タイトル

ドキュメントのタイトル

n/a STRINGn/a"…のための
等しい
アナログ
確認
(=)
モジュール"

設計

n/a---| AAD005

ドキュメントアイテム
ファイル名

サプライヤーから提供された
データファイルの
ファイル名

n/a STRINGn/a"CPX_AM01.P
等しい
確認
DF"
(=)

設計

n/a

-

--| AAD006

ドキュメントアイテムバージョン

ドキュメントの
バージョン

等しい
(=)

設計

n/a

-

階層

ID

n/a STRING "1.1"確認"2.0.0"確認

36

ドキュメントアイテム
複雑なデータの--| AAD007
データフォーマ データフォーマット
ット

n/a

®
CAD001
CAD001

ドキュメントアイテム
BLOB--| AAD008（バイナリ・
ラージ・
オブジェクト）n/a

BLOB

ドキュメントアイテムの複雑なデータ

CAD001 ==
PDF

確認

等しい
(=)

設計

n/a

-

n/a

確認

等しい
(=)

設計

n/a

-

n/a

出所：ドイツ電気電子工業連盟（ZVEI）

下記に、様々な種類のドキュメントを分類する例を示す（VDI 2770 参照）。
表 16：ドキュメントの種類の分類（架空の例）
階層

ID

名称

定義

+

CAC001

ドキュメント

全ての種類のドキュメント+-+CAC002

技術文書

+-+-|

CAC003

技術仕様書

データ記録シート、
応力解析、仕様書シート、 ….

+-+-|

CAC004図 / 図式

分解図,、3D モデル、…

+-+-|

CAC005

部品表

部品表（BOM）+-+-|

CAC006

認証・証明書ATEX 認証、適合宣言書、…

+-+

CAC007

活動に関する
資料+-+-|

CAC008

組立 / 実装 / 解体

組立要領書、床配置図、…

+-+-|

CAC009操作

使用説明書、IBN instruction+-+-|

CAC010

安全

安全指示

+-+-|

CAC011

点検 / メインテナンス/ 評価

メインテナンスの予定表、
キャリブレーション指示、….

+-+-|

CAC012

修理 / サービス

修理指示、予備部品リスト、…

+-+

CAC013

契約文書

+-+-|

CAC014

契約文書

納品書、請求書、 …

出所：ドイツ電気電子工業連盟（ZVEI）

次に、ドキュメンテーション用に許可されたファイルフォーマットの分類の例を示す。

37

表 17：ドキュメントのファイルフォーマットの分類（架空の例）
階層

ID

名称

定義

+

CAD001

ドキュメンテーション
データ
フォーマット

I4.0 ドキュメンテーションのためのデータフォーマットを許可--|

CAD002PDF

PDF ファイル、--|

CAD003HTML

単一ファイル、HTML ファイル

出所：ドイツ電気電子工業連盟（ZVEI）

4.3.6 サブモデルのデータフィールドの定義■ 外部ダイレクトリーで属性を定義紹介したサブモデルの例では、属性の定義を外部ダイレクトリー（例えば IEC CDD、eCI@ss）で行うと仮定している。サブモデル（表 9、11、12、15）で属性を具体的に表すために、外部ダイレクトリー（表 18）にある定義を使用している。
（※ 紹介した架空の例では、少数のデータフィールドのみ使用して属性を（IEC 61360 に従って）定義しているが、実際のサブモデルではもっと多くのデータフィールドを定義する必要がある）
表 18：サブモデルのデータフィールド：属性の定義
データフィールド

英語の名称

解説

必須/
任意

例

ID

ID

ISO 29002-5 に基づく識別子
識別子は URI として定義することも可能

必須

BAA120バージョン番号

Version number

当該属性のバージョンを区別するための番号

必須

007

改訂番号

Revision number

当該属性を管理するための番号

必須

01

名称

(preferred) Name

当該属性の 1 つ、もしくは複数の単語からなる名称

必須

最大回転数

略称

Short name

当該属性の省略した名称

必須

文字記号

Preferred letter
symbol

当該分野で用いられている省略記号

任意

n：回転

定義

Definition

当該属性の持つ意味の明確な記述、他の属性と区別できるようにする

必須

モーターが運転可能な
最大許容回転数

38

定義の出所のドキュメントSourcedocument ofdefinition

当該属性の定義が含まれているドキュメントの参照先

任意

http://industrie-i40.
org/2016/interaction/negotiation/property_type/ta
sk_ref_number

データタイプData type

当該属性の値を表示するデータタイプ

必須

INTEGER_MEASURE

値フォーマット

Value format

当該属性の値の表示の方式や長さ

必須

NR1..5 もしくは、その他

単位

Unit of measure

当該属性の値の単位

値リスト

Value list

当該属性の許容値

必須、
n/a（該当なし）でもOK
必須n/a（該当
なし）でも
OK

1/min

0..8000

出所：ドイツ電気電子工業連盟（ZVEI）

注記： 上図の例では、識別子（ID）の短縮された表示を使用している。電動機の回転数の eCl@ss 7.0 における完全な ID は „0173-1#02-BAA120#007“だが、短縮形の“BAA120“を用いている。

39

4.4 I4.0 コンポーネント間の通信■ 個々のサブモデルが回答
I4.0 コンポーネント間のやり取り（インターアクション）の例として、（ドリルなど）ある特定の製造工程を行う能力についての「交渉」が挙げられる。例えば、そのような交渉は作業ステーションに宛てた「工作物の大きさ ≤ 500×300 ㎜、穴径 ≤ 12 ㎜、材料 ＝ ステンレス鋼 V2A、工程所要時間 ≤ 3 秒の条件で、製造工
程“ドリル”は可能か？」という 1 つの質問から始まるかもしれない32。この質問は複数の質問に分割され、作業ステーションの管理シェルの個々のサブモデルを介して回答される。この際に、個々のサブモデルに向けた「確認」や「要請」の属性が用いられる。
表 10（31 ページ）の「役目」の行に記した通り、各属性には I4.0 コンポーネント間の通信（やり取り）の際の役割があてがわれる。
•

要請（Requirement）： 承認または拒否が必要な照会•確認（Confirmation）： アセットの能力に関する照会•測定（Measurement）： 測定値の提供

図 14：管理シェル内のサブモデルに宛てた通信（架空の例）

出所：ドイツ電気電子工業連盟（ZVEI）

32

ZVEI(2016)

40

4.5 管理シェルの置き場所■ オートメーション機器、またはクラウドに管理シェル
管理シェルはオートメーション機器内に含まれている場合があれば、クラウドのコンピューターにある場合もある。下記に示すように様々な実現方法がある33。
•（例えばネジなどの場合）簡単な静的な情報源（HTML ファイル）として•フィールド機器上•（複数の機器を操作する）ゲートウェイ上•

ネットワークを介した IT ソリューション（クラウド・ソリューション）として

21 ページで紹介したスマートファクトリーの実証・研究プラットフォーム SmartFactoryK は、「概念的には、管理シェルを制御レベルとその上にある IT 系の層の間に置き、オートメーション技術と IT システムのゲートウェイを形成すべきである」としている34。管理シェルのコンテナとして、産業用のシングルボードコン
ピュータ（例：Harting MICA）を用いることができる。すでにある生産装置をレトロフィットする手法に基づくと、この産業用シングルボードコンピュータを PLC（プログラマブルロジックコントローラ）に接続し、制御レベルにアクセスするために（Web サービス、MQTT プロトコル、OPC UA サーバーなど）様々な通信標準のインターフェイスを備える必要がある。さらに、収集したデータをセマンティックに補充し、情報を上にある IT 層に伝送するために、PLC のインターフェイスに合わせて設定したソフトウェアが産業用シングルボードコンピュータ上に必要である。
SmartFactoryKL はインダストリー4.0 用モデル工場における計測モジュールの管理シェルを技術的にどのように実現したか、その例を示した（図 16 参照）。この際、計測モジュールの管理シェル内の情報を 3つに分けている（図 15 参照）。
•

静的データ（性能や技術文書など、時間が経過しても変わらないデータ）•

状況データ/ログ（例えば状況監視や予知保全に必要な動的なデータ）•

プラグ&プロデュースのデータ（「プラグ&プロデュース」のユースケースに必要なデータ）

図 16 の例では、収集したデータが OPC UA を介してエンタープライズ・サービス・バス（IBM IntegrationBus）に伝送される。静的データは SAP 社の ERP（Enterprise Resources Planning）、またはデータベース
から読み込むことができる。ERP もエンタープライズ・サービス・バスとつながっている。サードパーティーの新しいアプリケーションは MQ Telemetry Transport （MQTT） や REST（Representational State Transfer）などを介して、エンタープライズ・サービス・バスから必要なデータを取得することができる。

33
34

Plattform Industrie 4.0(2018a)
Technologie-Initiative SmartFactory KL (2017)

41

図 15：SmartFactoryKL モデル工場における計測モジュールの管理シェル

出所：SmartFactoryKL

図 16：SmartFactoryKL モデル工場における計測モジュールの管理シェルの技術的実現

出所：SmartFactoryKL

42

4.6 管理シェルのユースケース（活用事例）■ 3 段階のバリューチェーンの例
推進組織 Plattform Industrie 4.0 が 2018 年 8 月に発表した文献「管理シェルの詳細：アイデアから実装
可能なコンセプトまで」にて紹介されている、管理シェルのユースケース（活動事例）を図 17 に示す35。
図 17：管理シェルのユースケース（活用事例）

出所：Plattform Industrie 4.0 の資料を参考に作成

35

Plattform Industrie 4.0（2018a）

43■ 管理シェルは全ライフサイクルをカバー
前述の Plattform Industrie 4.0 の文献では、管理シェルがアセットの全ライフサイクルをカバーする様子
を電動機の例を用いて示している36。
表 19：アセットの全ライフサイクルに渡る管理シェルの使用例（架空の例）

工場運営者の視点から見た（全ライフサイクルに渡る）電動機の管理シェル「タイプ」の•工場の運営に必要な電動機の機能（回転モーメント、波高など）を計画する

開発段階１

•

電動機のフィーチャーの幾つかを（電動機の「タイプ」の）管理シェルに記述する「タイプ」の•あるサプライヤーのある特定の電動機の「タイプ」を選択する

開発段階 2•

選択した電動機の「タイプ」の情報を管理シェルに追加する「タイプ」の•電動機のサプライヤーから提供された情報を用いて、選択した電動機をシミュレ
ーション・確認する•

シミュレーション・確認しておいた電動機をサプライヤーに注文する•電動機の「タイプ（デジタルの設計データ）」は「インスタンス（物理的な製品）」となり、製造番号など特有のデータが（電動機の「インスタンス」の）管理シェルに加えられる「インスタンス」の•納品された電動機の操業中には、運転パラメータ（温度、振動など）を計測する

活用段階

•

運転パラメータの情報が電動機の管理シェルに付け加えられる•電動機の保守が行われると、その情報が管理シェルに追加される•

電動機の製品寿命が過ぎると、新しい電動機に交換される•

古い電動機を交換したことや新しい電動機の「タイプ」と「インスタンス」に関する全情報が（新たに作成した）管理シェルに記録される

活用段階「インスタンス」の生産段階「インスタンス」の活用・保守段階
製品寿命※ 管理シェルに記録・収集・保存される情報は、バリューチェーン上のパートナー企業（サプライヤー、開発パートナー、システム・インテグレーター、工場運営者、サービス提供会社）と共有することができる
出所：Plattform Industrie 4.0 の資料を参考に作成

36

Plattform Industrie 4.0（2018a）

44

4.7 管理シェルの意義・メリット■ （将来の）インダストリー4.0 実現のためのツール
インダストリー4.0 では、企業や業界・分野の壁を超えてバリューチェーン全体がネットワークでつながる。
その実現のためには、通信（ネットワーク、プロトコル）、サイバーセキュリティ、データ保護、概念・専門用
語・記号などの標準化が業界の垣根を超えて必要となる。同時に、各分野にすでに存在する国際標準・コンソーシアムの仕様も考慮しなくてはならない。また、将来的に生じるだろう新たな要件にも柔軟に対応できなくてはならない。管理シェルは（将来に渡って）インダストリー4.0 実現のためのツールである。
推進団体 Plattform Industrie 4.0 は管理シェルの利点として、下記のポイントを挙げている37。
【管理シェルの利点】•

インダストリー4.0 ユースケースのための情報をひとつにまとめる、包括的な枠組み•

様々な異なる企業や業界を橋渡しする•

拡張・拡大可能 （※ サブモデルやビューを拡張することで、管理シェルは将来的に生じる新たな要件にも柔軟に対応できる）•

アセットのライフサイクルの全段階（設計、運用、メインテナンスなど）をカバー■ 管理シェルがもたらす付加価値
ドイツ電気電子工業連盟（ZVEI）は、管理シェルが下記の付加価値を生み出すとしている38。
•【データ】 管理シェルには、CAD データ、配線図・接続図、取扱説明書などメーカー側が供給した大量のデータや情報が含まれる。システムインテグレーターや工場運営者が、（メインテナンスの情報、他のハードウェアやソフトウェアと接続するための情報など）重要な追加情報を管理シェ
ルに加えることもできる。Plattform Industrie 4.0 がデータセキュリティのための措置を定め、デー
タの可用性、信頼性、保全性・整合性が保証されるようにする。

•【機能】 管理シェルに、様々な機能（プロジェクトプラン、設定、操作、メインテナンス、ビジネスロ
ジックの複雑な機能など）を含めることができる。

•【サービス】 管理シェル内にあるデータ・機能に、企業内ネットワークやクラウドを介してアクセスできる。データや機能の情報を一度だけ保存すれば、IT サービスを介して（アクセス権のある）全てのユーザーが全ての活用ケースのためにアクセスできる。

•【統合】 インダストリー4.0 対応の通信プロトコルと管理シェルのコンセプトを組み合わせることで、生産システムの垂直方向と水平方向の統合が実現できる。

•【隅々まで情報】 管理シェルによって、アセットの全ライフサイクルの隅から隅まで（設計・エンジ
ニアリングから運用・運転、メインテナンスまで）情報が行き渡る。

37
38

Plattform Industrie 4.0（2018a）
ZVEI(2015)45•【モジュール方式】 インダストリー4.0 の成功には、まるごとの機械の情報だけではなく、機械内部の重要な部品・コンポーネントの情報も管理シェルに収めることが必要である。例えば、電気
軸は機械機能のクオリティーを大きく左右する。将来的に電機軸に関する情報も中央保守シス
テムから直接、アクセス可能にすべきである。同様にオートメーション技術分野では、独自のデータ・インターフェイスを持たない生産コンポーネントの情報も管理シェルに入れるべきである。
例えば端子台に関して、何を・いつ・何の目的で接続したかといった情報を管理シェルに記録することができる。このように、全ての部品が‘つながる生産’における‘スマート部品’となる。

【企業にとっての具体的なメリット】•（自社製品や自社で使用している）ハードウェアやソフトウェアをインダストリー4.0 対応にするために、管理シェルを利用できる。

•

管理シェルに保存されている情報は任意に拡大可能。メーカーやシステムインテグレーターは新たな情報、知識モデル、専門機能などを追加することで、バリューチェーン上の企業に‘スマート・サービス’を提供できる。

Tilo Bötcher 氏（マイクロソフト（ミュンヘン拠点）のインテリジェント・クラウドの責任者）の見解39“製品を管理シェルとともに納品すれば大きなメリットが得られる。バリューチェーンの川下の企業にその製品をどのような条件下で製造したのか知らせることができるからだ。川下の企業は例えば（製造時の）温度を知ることができる。この情報を基に他の部品も同じ温度下で取り付けたら、テンションが避けられるので良いかもしれない”

39

MM MaschinenMarkt (2016)

46

4.8 管理シェルが満たすべき要件
推進組織 Plattform Industrie 4.0 は管理シェルが満たすべき要件をあらかじめ定めている40。

■ 様々な異なる技術分野の規格・標準・仕様を考慮•【要件１】 管理シェルは、様々な技術分野の属性をそれぞれ異なるサブモデルに取り入れることが可能であるべき。各サブモデルは（他のサブモデルに依存することなく）独自にバージョン管理や保守ができなくてはいけない。
すでに多数存在する様々な国際標準やコンソーシアムの仕様を管理シェルに反映させる必要があり、そのために多数のサブモデルが必要となる。サブモデルはそれぞれ、あるひとつの特定の技術分野（例：安全、エネルギー効率）をテーマとする。例えば、安全に関する ISO 12100、ISO 13849-1、IEC
61508、IEC 61511、IEC 62061 といった標準・仕様がサブモデル「安全」の構成要素となり得る。

•【要件 2】 管理シェルは幅広い異なる技術分野の属性を取り入れることができ、それらの属性がどの分野に由来するのか特定できなくてはならない。
（→ 図 10（26 ページ）参照）•【要件 3】 それぞれの技術分野の重要な属性を特定するために、国際標準、コンソーシアムの仕様、メーカーの仕様をそれぞれ満たす、様々なプロセスモデルを見付けなくてはならない。

■ 異なる管理シェル同士のつながり•【要件 4】 あるひとつのアセットに複数の異なる管理シェルがある場合、互いに参照し合うことが可能であるべき。ある特定の管理シェルの要素は、他の管理シェルの対応する部分の「コピー」の役割を果たさなくてはならない。
例えば、メーカーがアセット（例：機械）の開発段階で社内向けに「タイプ/開発」の管理シェルを作成
し、顧客向けには「タイプ/利用」の管理シェルをつくる。顧客企業は納品されたきたアセット（例：機械）のために「インスタンス/利用」の管理シェルを作成する。「タイプ」の管理シェルをアップデートした場
合、「インスタンス」の管理シェルにもアップデートの内容が（自動的に）反映される必要がある。（→ 15～16 ページも参照）•【要件 5】 個々の管理シェルはその構造を保ちながら、ひとつの総合的な管理シェルに統合する（組み合わせる）ことが可能であるべき。
例えば、機械軸、電動機、サーボ増幅器など個々のアセットは軸装置を構成する。これらの個々のアセットはそれぞれ管理シェルとともに、軸装置のメーカーに納品される。このメーカーが軸装置を販売する際に、個々の部品の管理シェルは軸装置の管理シェルとしてひとつにまとめられる。

■ 識別子（ID）•【要件 6】 アセット、管理シェル、属性、分類の関係の識別には、広く普及している識別子（IRDI、
URI、GUID）を使用すべき。可能であれば、世界中で一意識別できるようにする。

40

Plattform Industrie 4.0(2016)、Plattform Industrie 4.0; Alliance Industrie du Futur; Piano Industria 4.0 (2018)

47

グローバルな識別子は、自社の管理シェル/I4.0 コンポーネントがバリューチェーン上の他社の管理
シェル/I4.0 コンポーネントと通信（やり取り）することを可能にする。グローバルな識別子として、IRDI（国際登録データ識別記号）と URI （Uniform Resource Identifier、統一資源識別子）がある。他社がアクセスする必要のないアセットの管理シェルには、（世界中で一意識別できない）社内の識別子も使える。

•【要件 7】 管理シェルは、ある特定のアセットの識別子（ID）の代替識別子（GS1、GTIN）の検索も可能にすべき。
GS1 識別コードなど、追加的な識別子も管理シェルに記述し、検索できるようにすることに意味がある。

■ 管理シェルに関する要件•【要件 8】 管理シェルはボディーとヘッダーからなる。
（→ 4.3.1 項を参照）•【要件 9】 ヘッダーは識別に関する情報を含む。
（→ 4.3.2 項を参照）•【要件 10】 ボディーは各アセットに関する情報を含む。
ボディーには（サブモデル、属性を介して）アセットに関する情報が含まれる。（→ 4.3.3 項を参照）•【要件 11】 管理シェルに含まれている情報や機能は API（アプリケーション・プログラミング・イン
ターフェース）を介してアクセス可能。
管理シェル内の情報や機能にアクセスするためには標準化された API が必要。Plattform Industrie
4.0 ではオンライン・アクセスのためのサービス（CRUD）を開発する計画でいる。（→ 管理シェル開発の今後の予定については次節 4.9.1 項を参照）•【要件 12】 管理シェルは一意識別子（ID）を持つ。
（→ 図 8（24 ページ）参照）•【要件 13】 アセットは一意識別子（ID）を持つ。

•（→ 図 8（24 ページ）参照）•【要件 14】 工場自体もアセットであり、管理シェルを有し、ID を介してアクセス可能。
管理シェルのコンセプトは、工場の全ての階層レベル（工場全体、生産ライン、作業ステーション、制御・フィールド機器など）に適用される。（→ 階層レベルについては 3.2 節を参照）•【要件 15】 「タイプ」はタイプとして、「インスタンス」はインスタンスとして特定されるべき。
管理シェルは、「タイプ（＝ 製品になる前の青写真・設計図・試作品）」と「インスタンス（＝ 製品）」の両方のために作成可能である。両者を区別できるように、ヘッダーで当該アセットが「タイプ」なのか「インスタンス」なのか示すようにする。

•【要件 16】 管理シェルは、他の管理シェル、インダストリー4.0 の情報へのリンク（参照先）を含む
ことができる。

48

情報と情報をつないでノレッジ（知識）とするためには、管理シェルが他の管理シェルを参照できるよう
にすべき。

•

【要件 17】 追加の属性（例えばメーカー独自の属性）も含むことが可能であるべき。
インダストリー4.0 の将来的なニーズを満たすためには、国際標準に加えて、コンソーシアムやメーカー独自の仕様もサポートしなくてはいけない。（→ 4.2.5 項を参照）•【要件 18】 各管理シェルに必要な最低限の数の属性を定義すべき。
管理シェルは他の管理シェルや他のシステムにとって、信頼できる情報ソースでなくてはいけない。
そのためには最小限の属性を定義することが必要である。（→ 例えば 4.3.4 項で紹介したサブモデル「ドリル」では計 15 の属性を用いている）■ 属性（データ・機能）に関する要件
下記の要件は管理シェルの属性に適用される。（→ 属性については 4.2.5 項を参照）•【要件 19】 管理シェル内の属性やその他の情報要素は「タイプ」や「インスタンス」に適していなくてはならない。
管理シェルは「タイプ（＝ 製品になる前の青写真・設計図・試作品）」と「インスタンス（＝ 製品）」の両方のために作成可能である。このため、属性は当該アセットの「タイプ」に加えて、「インスタンス」についても対応できる必要がある。（→ 「タイプ」と「インスタンス」については 3.4 節を参照）•【要件 20】 階層的で番号付けが可能な属性構造にすべき。
インダストリー4.0 の進展につれて属性の量が次第に多くなると予想されるが、人間や機械にとって把握・管理しやすい構造にする必要がある。（→ 属性の階層構造については図 12（28 ページ）参照のこと。表 9（31 ページ）、11（32 ページ）、12（33 ページ）、15（35 ページ）に記したサブモデルの架空の例では属性の階層が 1 列目に記載されている）•【要件 21】 属性が（他の管理シェル内にある）他の属性も参照できるようにすべき。
管理シェルが他の管理シェルを参照できるように、属性も他の管理シェル内にある属性を参照できるようにする。そのようにして情報と情報をつなぐと、ノレッジ（知識）が形成される。異なる技術分野（の標準）を関連付けることもできる。

•【要件 22】 属性が管理シェルのデータや機能を参照できるようにすべき。
管理シェル内の複雑なデータや機能が属性を介して参照できるようにする。（→ 属性とデータ・機能について図 11（27 ページ）参照。サブモデル「ドリル」の例（表 12（33 ページ））では機能（シミュレー
ション、プログラム実行）を参照、サブモデル「ドキュメンテーション」の例（表 15（35 ページ））では複雑なデータ要素（PDF）を参照している）

49

4.9 管理シェルの開発と今後の展望■ 管理シェル開発の 2 つのプロジェクト
23 ページに、管理シェルの技術的な詳細について今現在、まだ開発を進めている段階にあると記した。
Plattform Industrie 4.0 の作業グループ「AG1」では管理シェルを段階的に開発しており、その成果を随時発表している。現在の作業は、「管理シェルの詳細」と「具体例な管理シェル」の 2 つのプロジェクトに大別される。
•

管理シェルの詳細 - 形式 - メタ情報モデル： これまでに案出してきた内容的要素を 1 つの構造にまとめる。実装可能にする•

具体例な管理シェル - 内容 - サブモデルの内容：例示的な I4.0 シナリオをデモンストレーターで実現する。具体的なテンプレートを作成する

現在、管理シェルの内容の詳細な定義とそれを実証・実装することに重点が置かれている。

4.9.1 管理シェルの詳細（形式）4.9.1.1 プロジェクトの概要■ 「メタ情報モデル」に関する開発作業「管理シェルの詳細（Verwaltungsschale im Detail）」のプロジェクトでは、これまでに案出してきた内容的要素を 1 つの構造にまとめて、実装可能にすることに重点を置く41。
【内容的要素】

41•（管理シェルの）重要な要件•

管理シェルの構造•識別子（ID）

•

サブモデル

•

属性（性能、参照先、…）•

権利・役割管理のコンセプト•

統一モデリング言語（UML）による基礎的表現•

内容のシリアライズ（XML、JSON、…）•

OPC UA、AutomationML(Automation Markup Language)にマッピング•

複合コンポーネント

Plattform Industrie 4.0（2018a）

50•

I4.0 コンポーネント同士のやり取り（インターアクション）•‘インフラ’の中における管理シェル•

管理シェルとそのコンポーネントのためのサービスインタフェース

4.9.1.2 今後の予定■ 2018 年秋以降、公表予定「管理シェルの詳細 パート 1」
Plattform Industrie 4.0 の作業グループ「AG1」は 2018 年秋以降に、「管理シェルの詳細 （パート 1） バリューチェーン上のパートナー間における情報の交換」の文献を発表する予定。管理シェルに含まれている全情報をパケット（フェイルの束）として、あるパートナーから別のパートナーに伝送するために、どのように情報（データ）を編集・処理、整理すべきか示すことを計画している42。
•

管理シェルの情報内容とシリアライゼーション形式を記述する•

UML ダイアグラム、XML スキーマ、JSON スキーマも含む予定（OPC UA、AutomationML は準
備中）•

情報の保全性と信頼性を保証するために、情報が入ったパケットをどのように署名・暗号化するか示す•

各々の情報要素にアクセス権を当てがうために、最小限の役割コンセプトを規定する。

表 20：管理シェルの役割コンセプト

管理シェルの役割コンセプト• どの情報要素（管理シェル、サブモデル、属性）に関しても、‘役割’に基づいたアクセス権をあてがう• バリューチェーン上の各パートナーは自らのセキュリティー領域の中で、役割と権利を確認・保証する• メーカー側は個々の情報要素がどの役割と権利を含むべきか、提案することができる【ロボットの例】
役割 ‘立上げ・試運転の専門家’• プログラムを読み込む、移動する、削除するなど、ロボットに何をしてもよい• プログラムをスタート、停止してよい役割 ‘操作者’役割 ‘メインテナンス要員’• プログラムを削除したり、読み込んだりしてはいけない• プログラムを停止し、ロボットをある決まった整備用のポジションに動かしてよい• プログラムをスタートしてはいけない

42

Plattform Industrie 4.0（2018a）

51

実現のために…
•

役割の定義： 管理シェル内のサブモデルとして定義する•

アクセス権： それぞれの役割につき、各情報要素が定義可能•

上層の‘役割’の者は下層の‘役割’の者に自分の権利を与えることができる•

最小限度の役割コンセプトは必須要件（OPC UA の役割コンセプトを参照にする）
出所：Plattform Industrie 4.0

表 21：管理シェル伝送のパケット・フォーマット

管理シェルの内容を伝送するためのパケット・フォーマット
ZIP ファイル、Office Open XML/ Open Packaging Conventions（ISO/IEC 29500-2）のようにパケット（複数のファイルの束）として伝送•

ヘッダー、ボディー（サブモデル、属性、値）を 1 つに束ねる•

複数の管理シェルを１つのパケットにまとめることも可能•

サブモデルと属性が個々のファイルとして表示可能•

各ファイルは署名・暗号化できる

出所：Plattform Industrie 4.0■ 今後の展望前述の通り、Plattform Industrie 4.0 は 2018 年秋冬に「管理シェルの詳細 パート 1」を公表する予定。それに続いて、オンライン・アクセスのためのサービス（CRUD ）、管理シェル同士のやり取り、セキュリティ対策、内部アーキテクチャなどの続編も計画している。
図 18：プロジェクト「管理シェルの詳細」の今後の展望

出所：Plattform Industrie 4.0

52

4.9.2 具体的な管理シェル（内容）4.9.2.1 プロジェクトの概要■ 「サブモデルの内容」に関する開発作業「具体的な管理シェル（Verwaltungsschale konkret）」のプロジェクトでは、ユーザー企業が実際に管理シェルを利用できるようにサブモデルの具体的な内容を定めたり、管理シェルをデモンストレーター（インダ
ストリー4.0 のシナリオの具体例）に実装することに主眼を置いている43。
•

管理シェルとサブモデルの具体的な実装（出発点：明らかに有用な具体的な活用事例）•

ヘッダーの具体化、管理シェルや属性を介したサブモデルのメタデータ•

サブモデルの定義のための手引き•

標準化された基礎サブモデルの定義•

バリューチェーン上のパートナー同士で取り決めた、自由サブモデルの具体化•

デモンストレーターでの実装【具体的なテンプレート、デモンストレーターで例示的な活用シナリオを作成】•

ドイツ電気電子工業連盟（ZVEI）、ドイツ機械工業連盟（VDMA）、ドイツ技術者協会（VDI）/
VDE（ドイツ電気電子協会）にて、電気駆動装置やドキュメンテーションのサブモデル開発•「人気のあるサブモデル」（例えば NAMUR-Core-Parameter）の開発•

OPC UA コンパニオンスタンダード、実践的な手引き「How to write a companion standard」

4.9.2.2 今後の予定■ 2018 年秋以降に公表予定の文献 「具体的な管理シェル」
Plattform Industrie 4.0 は、「Verwaltungsschale konkret（具体的な管理シェル）」に関する文献を 2018 年
秋以降に発表する予定。この新しい文献では管理シェルに関する実用的なポイントをまとめる。容易に理解でき、ユーザー企業が自ら試行するのに適した内容になるという44。
•

ユーザーがどのようにサブモデルを自ら開発できるか解説する•

インダストリー4.0 の世界の多くのアセットに共通する基礎サブモデルを定義する（カタログデータ
など）

43
44

•

サブモデルのためのテンプレートを提供する（その中には識別、ドキュメンテーションも含まれる）•管理シェルを実装して、利用するための 2 段階のインダストリー4.0 の活用シナリオを記載する

Plattform Industrie 4.0（2018a）
Plattform Industrie 4.0（2018c）、Plattform Industrie 4.0（2018a）

53■ 今後の展望
Plattform Industrie 4.0 ではステップ・バイ・ステップで「具体的な管理シェル」を開発している。ステップ 1
は（ヘッダー、ボディー、サブモデルからなる）管理シェルの構造の実装で、2018 年 4 月のハノーファーメ
ッセに際して発表した。ステップ 2 は管理シェルと管理シェルの間のやり取り（インターアクション）で、I4.0
コンポーネント同士が自律的に行う通信をデモンストレーターで実証する。ステップ 2 は 2018 年第 4 四半期に予定している。
図 19：プロジェクト「具体的な管理シェル」の今後の展望

出所：Plattform Industrie 4.0

54

5 米国中心の IIRA との比較
■ 米国の参照アーキテクチャモデル「IIRA」との相違
推進組織 Plattform Industrie 4.0 は 2014 年 4 月に「RAMI 4.0」を発表したが、米国を中心とする産業用
IoT の推進組織 Industrial Internet Consortium（IIC）も 2015 年 4 月に参照アーキテクチャモデル「Industrial Internet Reference Architecture（IIRA）」を発表した。ドイツの専門誌「elektrotechnik（電気工学）」、「Computer & AUTOMATION（コンピューターとオートメーション）」は 2016 年の記事で両方の参照
アーキテクチャモデルを比較し、下記のポイントを指摘した45。
•

RAMI 4.0 と IIRA の本質的な違いは、RAMI 4.0 ではアセットのライフサイクルを明白に考慮している点である。RAMI 4.0 ではアセットの全ライフサイクルに渡り、データを収集、管理・保守、拡張する。これに対して、IIRA では必要に応じてデータが発生し、ある指定された目的（ビックデー
タ解析、プロセスの制御など）のみに使用される。

•

IIRA では物理的なモノのみ考慮しているが、RAMI 4.0 では（生産計画や注文など）非物質的な‘もの’もアセットに含めている。

•

RAMI 4.0 では、デジタル化した製造業のバリューチェーンをつなぐことに焦点をあてている。これに対して、IIRA はエネルギー、健康、製造、公共機関、交通など、幅広い分野の産業用 IoTのフレームワークを目指している。

■ RAMI 4.0 と IIC の連携
Plattform Industrie 4.0 と Industrial Internet Consortium は 2016 年 3 月、連携することで合意した。両イ
ニチアチブは標準化において協力し、RAMI 4.0 と IIRA の 2 つの参照アーキテクチャの相互運用性についても協議するとした。同年 11 月、合同プロジェクトを立ち上げ、Plattform Industrie 4.0 と Industrial
Internet Consortium の 2 つの規格間でデータ交換を可能にする取り組みに着手。
2018 年 2 月には、両イニチア
チブの共同ホワイトペーパー「Architecture Alignment andInteroperability（アーキテクチ
ャの位置合わせと相互運用）」を発表した46。2 つの有力な産
業用 IoT の参照アーキテクチ
ャモデルである RAMI と IIRA
をマッピング・位置合わせし、両者が「大いに補足し合う」と結論付けている。

45
46

Computer & Automation (2016)、Electrotechnik (2016)、Electrotechnik (2015)
Plattform Industrie 4.0; Industrial Internet Consortium (2018)

55

6 参照文献Computer & Automation (2016): Industrie 4.0: Was hinter der Referenzarchitektur RAMI 4.0 steckt（インダストリー4.0： 参照アーキテクチャ RAMI 4.0 の後ろにあるもの; ドイツ語）,
https://www.computer-automation.de/steuerungsebene/steuern-regeln/artikel/129204/,2018/9/7 アクセス.
Electrotechnik (2015): Interview zur Industrie 4.0 Standard-Debatte: „Wille zum Kompromiss kann RAMI
und IIC zusammenbringen“（インダストリー4.0 の標準の議論についてインタビュー「妥協の意思がRAMI と IIC を く っ つ け る 」 ; ド イ ツ 語 ） , https://www.elektrotechnik.vogel.de/wille-zumkompromiss-kann-rami-und-iic-zusammenbringen-a-506774/, 2018/9/7 アクセス.
Electrotechnik (2016): Industrie 4.0 versus IIC: Zwei Architekturansätze für das industrielle Internet（インダストリー4.0 対 IIC：産業用インターネットのための 2 つのアーキテクチャ・アプローチ; ドイツ語）,
https://www.elektrotechnik.vogel.de/zwei-architekturansaetze-fuer-das-industrielle-interneta-547745/index3.html, 2018/9/7 アクセス.
MM MaschinenMarkt (2016): Führungskreis Industrie 4.0: Konferenz zeigt Kriterien eines Industrie-4.0Produktes auf（インダストリー4.0： コンファレンスでインダストリー4.0 製品の基準を提示; ドイツ語）,
https://www.maschinenmarkt.vogel.de/index.cfm?pid=5112&pk=569448&print=true&printtype=article, 2018/9/7 アクセス.
Plattform Industrie 4.0 (2016): Struktur der Verwaltungsschale - Fortentwicklung des Referenzmodells
für die Industrie 4.0-Komponente（管理シェルの構造 – I4.0 コンポーネントのための参照モデルの発展; ドイツ語）,
https://www.plattform-i40.de/I40/Redaktion/DE/Downloads/Publikation/struktur-derverwaltungsschale.pdf?__blob=publicationFile&v=10, 2018/9/7 アクセス.
Plattform Industrie 4.0 （2018a）: Die Verwaltungsschale im Detail - Von der Idee zum implementierbaren
Konzept（管理シェルの詳細 – アイデアから実装可能なコンセプトまで; ドイツ語）,
https://www.plattform-i40.de/I40/Redaktion/DE/Downloads/Publikation/verwaltungsschaleim-detail-pr%C3%A4sentation.pdf?__blob=publicationFile&v=3, 2018/9/7 アクセス.
Plattform Industrie 4.0 (2018b): RAMI4.0 – Ein Orientierungsrahmen für die Digitalisierung（RAMI4.0 –デジタル化のためのオリエンテーション補助; ドイツ語）, 2018/9/7 アクセス不可.
Plattform Industrie 4.0 （2018c）： Zusammenfassung - Verwaltungsschale konkret（サマリー 具体的な管理シェル; ドイツ語/英語）,
https://www.plattform-i40.de/I40/Redaktion/DE/Downloads/Publikation/hm-2018verwaltungsschale-konkret.pdf?__blob=publicationFile&v=9, 2018/9/7 アクセス.
Plattform Industrie 4.0 (2018d): Industrie 4.0-Komponenten werden interoperabel – mit der
Verwaltungsschale（管理シェルでインダストリー4.0 コンポーネントが相互運用性になる; ドイツ語/
英語）,

56

https://www.plattform-i40.de/I40/Redaktion/DE/Downloads/Publikation/2018verwaltungsschale-im-detail.pdf?__blob=publicationFile&v=10, 2018/9/7 アクセス.
Plattform Industrie 4.0; Alliance Industrie du Futur; Piano Industria 4.0 (2018): The Structure of the
Administration Shell: TRILATERAL PERSPECTIVES from France, Italy and Germany （管理シェルの構造 – フランス、イタリア、ドイツの 3 国の視点; 英語）,
https://www.de.digital/DIGITAL/Redaktion/DE/Publikation/the-structure-of-theadministration-shell.pdf?__blob=publicationFile&v=4, 2018/9/7 アクセス.
Plattform Industrie 4.0; Industrial Internet Consortium (2018): Architecture Alignment andInteroperability（アーキテクチャの位置合わせと相互運用; ドイツ語）,
https://www.iiconsortium.org/pdf/JTG2_Whitepaper_final_20171205.pdf, 2018/9/7 アクセス.
Technologie-Initiative SmartFactory KL (2017): Exemplarische Übertragung der RAMI 4.0Verwaltungsschale

auf

die

SmartFactoryKL-Systemarchitektur

fürIndustrie

4.0-

Produktionsanlagen（インダストリー4.0 生産工場のための SmartFactoryKL システムアーキテクチャ
への RAMI 4.0・管理シェルの例示的な適用; ドイツ語）,
http://smartfactory.de/wp-content/uploads/2017/08/SF_WhitePaper_2-1_DE.pdf; 2018/9/7 アクセス.
VDI Verein Deutscher Ingenieure e.V.; VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik(GMA)（ドイツ技術者協会/ドイツ電気電子協会） (2017): Industrie 4.0 Begriffe/Terms（インダスト
リー4.0 の概念; ドイツ語/英語）,
https://m.vdi.de/fileadmin/vdi_de/redakteur_dateien/gma_dateien/7153_PUB_GMA__Industrie_4.0_Begriffe-Terms_-_VDI-Statusreport_Internet.pdf, 2018/9/7 アクセス.
ZVEI – Zentralverband Elektrotechnik- und Elektronikindustrie（ドイツ電気電子工業連盟） (2015):
Industrie 4.0: Die Industrie 4.0-Komponente（インダストリー4.0： I4.0 コンポーネント; ドイツ語）,
https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2015/april/Die_I
ndustrie_4.0-Komponente/Faktenblatt-Die-Industrie-4_0-Komponente.pdf, 2018/9/7 アクセス.
ZVEI – Zentralverband Elektrotechnik- und Elektronikindustrie（ドイツ電気電子工業連盟） (2016):
Beispiele zur Verwaltungsschale der Industrie 4.0-Komponente – Basisteil（I4.0 コンポーネントの管理シェルの例 - 基本部分; ドイツ語）,
https://www.zvei.org/fileadmin/user_upload/Presse_und_Medien/Publikationen/2016/November/
Beispiele_zur_Verwaltungsschale_der_Industrie_4.0-Komponente_-_Basisteil/BeispieleVerwaltungsschale-Industrie-40-Komponente-White-Paper-Final.pdf, 2018/9/7 アクセス.

57

図目次
図 1：インダストリー4.0 への発展 ............................................................................................ 7
図 2：インダストリー4.0 の参照アーキテクチチュアモデル「RAMI4.0」............................................. 10
図 3：Plattform Industrie 4.0 の現在のアプローチ ..................................................................... 11
図 4：RAMI4.0 の第 3 軸（階層レベル） .................................................................................... 13
図 5：管理シェル、アセット、I4.0 コンポーネントの関係（例：作業ステーション） ................................ 20
図 6：SmartFactoryKL モデル工場における I4.0 コンポーネントの例 ............................................. 22
図 7：管理シェルの一般的な構造 .......................................................................................... 23
図 8：ヘッダー内の管理シェルとアセットの ID（架空の例） ........................................................... 24
図 9：管理シェル内のサブモデル（架空の例） ........................................................................... 25
図 10：サブモデルと規格・標準の関係（架空の例） .................................................................... 26
図 11：サブモデルと属性（架空の例） ...................................................................................... 27
図 12：サブモデル内の属性（架空の例） .................................................................................. 28
図 13：ビューと属性の関係 ................................................................................................... 29
図 14：管理シェル内のサブモデルに宛てた通信（架空の例） ...................................................... 39
図 15：SmartFactoryKL モデル工場における計測モジュールの管理シェル .................................... 41
図 16：SmartFactoryKL モデル工場における計測モジュールの管理シェルの技術的実現 ................ 41
図 17：管理シェルのユースケース（活用事例）.......................................................................... 42
図 18：プロジェクト「管理シェルの詳細」の今後の展望 ............................................................... 51
図 19：プロジェクト「具体的な管理シェル」の今後の展望 ............................................................ 53

58

表目次
表 1：本レポートのベースとなった資料 ..................................................................................... 6
表 2：Plattform Industrie 4.0 の 6 つの作業グループ .................................................................. 9
表 3：RAMI4.0 の第 2 軸（6 つのレイヤー） ............................................................................... 15
表 4：RAMI4.0 の第 1 軸（ライフサイクル軸） ............................................................................. 16
表 5：アセットの定義と意味 ................................................................................................... 17
表 6：物質的・非物質的なアセットの例 .................................................................................... 18
表 7：管理シェルの定義と意味 .............................................................................................. 19
表 8：I4.0 コンポーネントの定義と意味 .................................................................................... 21
表 9：サブモデル「MES 接続」（架空の例）................................................................................ 31
表 10：サブモデルのデータフィールド（架空の例） ..................................................................... 31
表 11：サブモデル「エネルギー効率」（架空の例）...................................................................... 32
表 12：サブモデル「ドリル」（架空の例） ................................................................................... 33
表 13：材料の分類（架空の例） .............................................................................................. 34
表 14：成功/不成功の分類（架空の例） .................................................................................. 35
表 15：サブモデル「ドキュメンテーション」（架空の例） ................................................................ 35
表 16：ドキュメントの種類の分類（架空の例） ........................................................................... 36
表 17：ドキュメントのファイルフォーマットの分類（架空の例） ....................................................... 37
表 18：サブモデルのデータフィールド：属性の定義 .................................................................... 37
表 19：アセットの全ライフサイクルに渡る管理シェルの使用例（架空の例） .................................... 43
表 20：管理シェルの役割コンセプト ........................................................................................ 50
表 21：管理シェル伝送のパケット・フォーマット ......................................................................... 51