近年の製造業において、製造のためのデータ（情報）を標準化し、設計や保守を統一化することで生産性を上げる等の取り組みは各所で行われている。その一方で、価値創出や競合優位性の強化のためのカスタマイズ（独自仕様化）は、その目的の重要さ故に様々な局面で行われている。このことは必然的に標準化と相反する方向であり、その両立が課題である。

上記課題を解決するために我々は、オープン標準であるOPC UA（OPC Unified Architecture）^1-3）やPackML（Packaging Machine Language）^4-6）を用いて、製造現場で情報の重要なハブ（中心）となるコントローラ上において情報の標準化を簡単に実現できる製品と、カスタマイズが実現できる複数の手法を開発した。これらにより、情報の標準化とカスタマイズが両立し、かつ、情報の分離を強化した。

本稿では上記の取り組みの詳細について説明する。また、この取り組みに基づき、同様の取り組みを他のオープン標準の使用時や個別顧客対応などのケースへも広げていくことを提案する。

1. まえがき

近年の製造現場においては、生産性の持続的な向上や、資源の有効活用などを目指し、情報の標準化が各社・ベンダ・業界・国・経済圏等のレベルの内外において進められている^7-10）。図1に製造システムにおける標準化の例を示す。

一方で、各社・ベンダ・業界・国・経済圏等は、価値創出や競合優位性等を維持するために、各々の暗黙知を含むコアコンピタンスを、カスタマイズされた情報という形で各々固有の仕様として扱おうとする。

図2に製造システムにおける独自仕様や標準化を望まない例を示す。

これらの両立は従来から取り組まれているものの、例えばベンダにおける設計時において、標準仕様とカスタマイズ部分の切り分けや最適化において課題がある。

上記に対して我々は、製造現場で情報の重要なハブ（中心）となるコントローラ上において、現在、注目を集めているオープン標準規格であるOPC UA（IEC62541）やPackML（ANSI/ISA-TR88）を用いて、情報の標準化を簡単に実現できるライブラリ製品と、カスタマイズが実現できる手法を新たに開発した。

本稿では、2章でOPC UAやPackMLについて従来技術における標準化やカスタマイズへの対応について説明する。3章ではそれらの課題を述べ、4章では解決方法について述べる。5章にて考察および今後の課題と展望について述べる。

2. 従来技術における対応

2.1 紹介

OPC UAは、主にIT（Information Technology）-OT（Operational Technology）間で求められる汎用の通信の標準仕様である。機器の種類やオペレーティングシステム（OS）、メーカの垣根を越えて、セキュリティが確保された信頼性の高いデータ交換が行えることからIndustrie4.0の標準通信として推奨され、それを契機に世界中で一気に関心が高まっている^3）。

また、PackMLは、機械アプリケーションに特化した標準仕様である。PackMLでは従来から製造現場レベルの機械の動作・操作・上位システムとのインターフェースを規定していたが、OMAC（Organization for Machine Automation and Control）とOPC FoundationによってOPC UAに適用することが合意され、2018年にV1.00仕様が通信の標準仕様として仕様化されている（OPC UA for PackML）^4）。

本章では、従来技術における標準化やカスタマイズへの具体的な対応状況を説明する。

2.2 標準化への対応

2.2.1 OPC UA

OPC UA仕様では、情報を情報モデルという形で表す。情報モデルは、デバイス・機械・ラインのいわばプロファイルである。デバイス・機械・ラインの特性に合わせた具体的な情報モデルは、コンパニオン仕様と呼ばれている。これら仕様は各業界団体とOPC協議会のコラボレーションなどの形で標準化が行われている^3,4）。 コンパニオン仕様は、人間が読みやすい仕様書（文書）と、データ構造を表す、コンピュータが処理しやすいXMLから成り立っている。標準化されたコンパニオン仕様を記述したXMLファイルは、インターネット上などで取得可能となっている。標準化された情報モデル仕様における各情報項目などは、標準仕様の柔軟性担保などのために唯一無二の仕様とはなっておらず、当該項目についてMandatory（必須）やOptional（必須ではない）などの形で実質的に選択可能な仕様となっている^1）。

一方、本稿で言うカスタマイズ（独自仕様化）とは、顧客独自の情報モデル定義（拡張）を指しており、コンパニオン仕様などの情報モデル定義の上に成り立つ。

図3にOPC UAにおける情報モデルの論理的な構成を示す。また、図4にコンパニオン仕様について示す。

2.2.2 PackML・OPC UA for PackML

PackML仕様では、制御プログラム構造や機械の運転モードや状態遷移、機械の外部インターフェース（PackTag）などを標準定義している^4）。図5にPackMLの状態遷移の例を示す。このうち、主に機械の外部インターフェースをOPC UA仕様として標準定義したものがOPC UA for PackMLとしてコンパニオン仕様化されている。これにより、PackMLで標準定義されている情報に国際標準の通信OPC UAでアクセスできる形となっている^4）。図6にOPC UA for PackMLの情報モデルについて示す。

OPC UA for PackML仕様もコンパニオン仕様であり、その具体的な形はXMLファイルである。このことは前項の他のコンパニオン仕様とも同様である。

2.3 カスタマイズへの対応

前節まででOPC UAにおいて、標準化された情報モデルの具体的な形は、多くの場合XMLファイルとなっていることを述べた。カスタマイズとは具体的にはこのXMLへの対応となる場合が多い。我々の知見に基づき、この時のカスタマイズには主に以下の4種類があると考えている。文脈や要求内容に応じ注意が必要である。

1. 標準化された情報モデル仕様のOptionalの選択を指す場合
2. 標準化された情報モデル仕様の定義内容を変えてしまう場合
3. 標準化された情報モデル仕様にないものを入れ込む場合
4. まったく標準化されていない場合（独自仕様化）

ただし、4.については、論理的にはケースが存在するものの、独自仕様化であれば、従来の技術、製品で十分に実現が可能であり、本稿で言及する標準化にもカスタマイズにも該当しないため、以降は言及しない。

標準化された情報モデルのカスタマイズ要求などに対応するために、各社・ベンダ（機器のみならず、OPC UAのSDK（Software Development Kit）などを提供するベンダも含む）・業界などは、モデラー・情報モデルエディタ・ノードセットジェネレータなどの名前で情報モデルの編集・生成ツールを開発・提供・使用している。これにより、情報モデルの独自新規作成やカスタマイズ要求に対応している。これら編集・生成ツールは、所謂、XMLエディタである。（以後、これら編集・生成ツールを総称して情報モデルエディタと記す）

この情報モデルエディタにおける編集・生成は、一般の開発者が簡単にできるものではない。なぜなら、OPC UA仕様に関する専門知識が必要であること、またその業界や装置の標準仕様も踏まえた上での適切なカスタマイズ仕様化を行うためには、それらの専門家に匹敵する業界・装置知識が必要となるためである。この状況のため、情報モデルエディタのベンダ等は、同エディタの顧客と相談しながらカスタマイズを行う場合がある。あるいは、垂直統合型システム開発が可能な場合、自社内で独自に開発を行う場合もある。あるいは専門の委託先を活用する場合もある。

3. 課題

前章までで標準化やカスタマイズへのOPC UAやPackMLなどの従来技術における具体的な対応を説明した。本章ではこれらの課題を説明する。

3.1 標準化対応における課題

3.1.1 標準仕様準拠でも異なる情報・情報量（MandatoryとOptional）

前章にてOPC UA仕様にはMandatoryやOptionalなどの形で実質的に選択可能な仕様（正確にはModelling Ruleという仕様）となっていることについて触れた。

このことは標準仕様対応として考えた時、厄介な状況を生む。なぜなら、標準仕様準拠と言っても、このOptionalの選択が異なることで、様々な情報構造の組み合わせが発生することにより、そこにアクセスするOPC UAクライアントの開発や、汎用化の難易度などの問題を生じさせる可能性があるためである。図7に標準モデリング・ルール Optional と Mandatory を使った場合の、実際に仕様書に記載されている例を示す。図7は、TYPE_Aの型定義に従って、A1-A14のインスタンスが定義できることを示している。

標準仕様が様々な理由でOptionalを持つこと自体は、これまでの経緯や仕様の知見上、一定の必要性があると見ることができる。また、OPC UAでは、OPC UAクライアントは図7上部にあるType（型）情報をOptional含め取得し把握した上でOPC UAサーバが持つインスタンス情報にアクセスすることが前提として想定されているため、Optionalという仕様を持つことは仕様としては課題にならない。しかし、現実問題としては、例えば図7だけで見てもType_AひとつにA1～A14の全ての情報構造に対応できている必要があることとなり、OPC UAクライアントの開発の困難さは増し、課題となる。

3.1.2 顧客が必要とする情報量と標準仕様の情報量との間のギャップ

次に課題となるのは、顧客が必要とする情報量と、標準仕様が持つ豊富な情報量との間にギャップが生じる場合があることである。

実際に、あるコンパニオン仕様に関して小規模装置メーカにおいて得たVOC（Voice of Customer）としては、「自身の装置がこれまで提供してきた情報量に対して、コンパニオン仕様が持つ最大量の実装を行う必要はない。」というものがあった。

すなわち、コンパニオン仕様に対応するためには、顧客の装置がこれまで提供していなかった情報を新たに提供しなければならない場合が発生し得るため、今まで以上の開発コストがかかり得ることが顧客にとって課題となる。

3.2 カスタマイズ対応における課題

3.2.1 標準化された情報モデル仕様のOptionalの選択を指す場合

MandatoryとOptionalは前節まででも課題として登場したが、標準とカスタマイズの切り分けという視点においても現実問題として下記のとおり課題となる。

標準仕様におけるOptionalの選択が異なる要求をすることは、標準化要求なのか、カスタマイズ要求なのかは明確には言えない。また、OPC UAクライアントがどの範囲までの標準仕様をサポートしていれば標準仕様クライアントなのか、明瞭とは言えない。

これらにより、標準仕様クライアントの開発の困難さは増し、かつ、切り分けが曖昧なことで、顧客が自身のカスタマイズ部分にフォーカスし更なる生産性改善などに注力することなどを阻害する。

実際に、ある顧客においては、標準仕様でよいのであれば何も考えたくはなく、どうしても独自の情報を入れなければならないならば、そこだけに注目したいとの声を得ており、これは顧客にとって課題である。

本ケースは、次章以降では標準化対応における標準仕様準拠の同一性の担保の課題解決として取り上げる。

3.2.2 標準化された情報モデル仕様の定義内容を変えてしまう場合

これまでのOPC Foundationや弊社顧客から知りえた情報などにより、下記のような状況を背景として、標準化された情報モデル仕様の定義内容を変えてしまう形でのカスタマイズが発生している。これらは標準化による更なる生産性向上などを阻害する課題となり得ると分析している。このため本ケースは、次章以降では標準化対応における標準仕様準拠の同一性の担保の課題解決として取り上げる。

1. 各社・ベンダに標準適用の動機が発生しない／しづらい現況

   現在、標準化の実施は改善の一環として多くの場合、各社・ベンダが主体となって自身のために進めている^9-11）。そして、これまでのOPC Foundationや弊社顧客から知りえた情報などにより、各社・ベンダの多くは、“自社内の範囲での”標準化ができればそれでよいと考えていると推測される。しかし、1社・1ベンダ内の標準化などのみでは、今後の生産性・競争力等の更なるサステナブルな向上などの視点は望めない^9-11）。

2. 独自の情報化が自由にできてしまう現況

   1. （ア） 情報モデルエディタは多くの場合、何でも書けるし変えられる。OPC UA標準仕様を持ってきて、これを自社に最適な情報構造に変更し、それを使おうとするのは、これまでのOPC Foundationや弊社顧客から知りえた情報などにより、企業にとって現状自然な行動であると分析している。
   2. （イ） 情報モデルのカスタマイズは、前述のとおり、かなりのスキルを必要とする。このため、多くの場合、コンサルタントが必要になったり、外注が必要になったりする。
   3. （ウ） 現在のベンダの中には、上記までのコンサルティングサービスや機能、請負事業を提供しているところもあり、自由にカスタマイズできる状況にある。

3.2.3 標準化された情報モデル仕様にないものを入れ込む場合

この種類のカスタマイズについて言えば、“標準化された情報モデル仕様にないもの”の質にも依るものの、以下のとおりむしろ前向きな進化のための課題であると分析している。

“標準化された情報モデル仕様にないものを入れ込もう”とする場合や要求する／される場合、これまでのOPC Foundationや弊社顧客から知りえた情報などにより、多くの場合以下のケースに分けられる。

1. 標準仕様として必要な情報にもかかわらず存在しない

   カスタマイズ仕様として要求されるが、その内容は、他社や他装置・他業界・国・経済圏に依らず必要な情報である場合がある。また、複数の標準仕様の混在やマージのために、結果としてカスタマイズ仕様要求となる場合もある。標準仕様の理解上、これらは単に標準仕様やその適用範囲などが不足していると見ることができる。標準仕様にも継続的な進化が求められる。

   本ケースは標準仕様の継続的進化の課題であり、本稿ではこれ以上取り上げない。

2. 標準化（オープン）してはいけない情報である

   これらの情報は、各社・ベンダ・業界・国・経済圏等は、各々の価値や競争力等を維持するために、各々の暗黙知を含むコアコンピタンスを特定し、カスタマイズされた情報という形で形式知化・情報化する情報である。また、将来性や拡張を考えている場合もある。これらの情報は機密性が高いため、堅固に守られなければならない。本ケースが、現状のカスタマイズを更に改善し適切に推し進めようとするときのカスタマイズ対応における課題であると分析している。

   本ケースについてのみを、次章以降のカスタマイズ対応における解決方法として取り上げていく。

4. 解決方法

ここまで見てきたとおり、現状の標準化、カスタマイズを更に改善し推し進めようとしたとき、標準仕様準拠でも異なる情報・情報量や顧客要求とのギャップ、標準とカスタマイズの切り分けには依然課題がある。これら課題の解決方法として、我々は以下を実現した。

4.1 標準化対応における解決

標準化への対応の課題解決方法として、情報の標準化を簡単に実現できるライブラリを新たに開発した^11-15）。具体的には、コンパニオン仕様OPC UA for PackMLを実現するFA 統合開発環境Sysmac Studio用のFB（Function Block）ライブラリ（形SYSMAC-XR101）である。以下その技術的特徴を述べる。

4.1.1 標準仕様準拠の同一性の担保

3.1.1にて標準仕様準拠でも異なる情報・情報量となることや、MandatoryとOptionalの課題について触れた。Optionalの選択のばらつきに伴う、外部から見た時の仕様や実装の違いが出ることを吸収していくために、我々は全てのOptional について本ライブラリとしてサポートすることとした。

これらにより、本ライブラリの使用者の誰にとっても同じ標準・情報となることが担保された。図8にこのイメージを図示する。

4.1.2 実装量の選択性確保

3.1.2にて標準仕様対応をしようとしたときの顧客が必要とする情報量と標準仕様の情報量との間のギャップについて触れた。前節の通り、全てのOptionalを含めて対応したならば尚更である。この点に関して我々は、そのノードのデータを扱うかどうかは、コントローラプログラムの設計として決められるように本ライブラリを設計した。

これにより、本ライブラリの使用者は、Optionalの選択をコントローラプログラムの設計時に決められる。具体的にはFBの引数としてデータをセットするか、しないかで決められるようにした。図9にこの実現イメージを図示する。

4.1.3 標準部分とカスタマイズ部分の完全分離

3章全体を通して、標準とカスタマイズが混在する現況とカスタマイズの種類が複数あることを見てきた。前節までのとおり、我々はこのライブラリをOptionalのデータ領域も含めて誰にとっても同じ標準とすることで、標準部分を確固たるものとし、また、ライブラリの使用者が無制限に改造できないように設計することで、カスタマイズが入り込む余地を排除した。これらにより標準部分とカスタマイズ部分の完全分離が確立した。

4.2 カスタマイズ対応における解決

3.2.3の2項目の課題解決に資するべく、カスタマイズが実現できる3つの手法を開発した^11-15）。以下その技術的特徴を述べる。

4.2.1 PLC情報としての情報モデルの機能拡張（解決方法1）

本稿冒頭で言及した通り、この解決は製造現場で情報の重要なハブ（中心）となるコントローラ上において行われる必要がある。従来の技術、製品で独自の情報化はサポートされていたが、これをカスタマイズ対応としても適切な形に拡充をしていく必要がある。

上記を踏まえ我々は、弊社製品のNJ/NXシリーズCPUユニットで対応していたPLC（Programmable Logic Controller）としてのコンパニオン仕様であるOPC UA Information Model for IEC 61131-3（OPC 30000）^16） の対応範囲を拡大した。具体的には、従来グローバル変数の公開のみの対応であったところを、グローバル変数に加え、（FBの）ローカル変数も公開できる仕様とした。これにより、グローバル変数による単にPLC内の変数の公開であったものが、名前空間機能やFB機能なども使用し、情報をより構造的に分割・構造化し柔軟に表現することが可能となった。また、これらの領域には新たにOPC UAネットワークからのロール（操作権限）を付与できるようにもした。これにより、よりセキュリティが確保された形での情報格納が可能となった。なお、このロール（操作権限）機能は、他のコンパニオン仕様の場合にも適用することができる。

これらの機能拡張対応により、情報はより柔軟に表現できるようになり、かつ、よりセキュリティが確保された形となり、OPC 30000に従う情報格納場所を、カスタマイズ情報を格納するための場所として、よりふさわしい場所とした。

図10にOPC 30000対応の変化点と拡張された後の実現イメージを示す。また、図11にロール機能による情報秘匿のイメージを示す。

4.2.2 OPC UAノード構成のカスタマイズ手段の提供（解決方法2）

前項の方法は、従来仕様の拡張であるため、コントローラとしてのこれまでの情報の見え方の仕様に従う。すなわち、OPC UA for PackMLのノード構成の見え方までをカスタマイズすることはさせない。

このため、OPC UAノード構成をカスタマイズできる方法として、自社SE/開発者が使用することができる販促ツールとして、簡易情報モデルエディタを新たに開発した。

これにより、OPC UA for PackMLのノード構成を変更する手法を提供できるようになった。なお、この手段は、OPC UA for PackMLに限らない他の情報モデルのOPC UAノード構成においても適用することができる。現状の簡易情報モデルエディタの限定的な制約（変数ノード構成のみがカスタマイズできること）については、今後検討を進め、適用範囲を広げられるように努める。

4.2.3 専用ライブラリを開発可能な技術状態へ（解決方法3）

前項の方法では、カスタマイズすることができるのは、言及のとおり、OPC UAノードの一部（変数ノード）の構成についてであり、制約がある。

このため、今回の対応において新たに以下を実現し、顧客専用のカスタムモデルのライブラリも開発可能な技術状態とした。

1. OPC UAの情報空間（アドレス空間）とコントローラ機能の対応付け仕様の汎用仕様化確立

   今回の対応を行うことにより、OPC UAの情報空間とコントローラ機能の対応付け仕様を汎用的にマッピングする内部仕様を新たに確立した。

2. FBをOPC UAネットワークから呼び出す内部汎用I/F確立

   前項同様、FBをOPC UAネットワークから呼び出す内部汎用I/Fを新たに確立した。これらにより、技術的には製品開発者以外でも個別の専用ライブラリが開発可能となる状態を確立した。

5. むすび

本稿での取組みにより、3章で述べた標準化対応における標準の情報・情報量のばらつきや、顧客要求とのギャップなどの現状課題への対応を、簡単化を含めてひとつの形として実現した。また、利用者の環境の規模に応じた標準仕様の適用方法についても提供することができた。これらの実現により、標準部分とカスタマイズ部分は、完全分離できるようになった。このことは、今後、更に進化をするために何が必要となるか、例えば、標準をクラウドに置くとしたらどうなるか・どうすべきかなど、現状の標準化やカスタマイズへの対応の方法を大きく変える材料ともなり得ると考えている。

カスタマイズについては、3章で述べたカスタマイズ対応における標準化との更なる切り分けに関する課題への対応として、標準化対応への統合、およびカスタマイズの3つの機能・手法として新たに開発・提示した。ただし、標準化への簡単さ・堅牢さを重視した分、カスタマイズについては、今後も更なる検討や改善を行っていく必要があると考えている。カスタマイズ情報の格納先として、現状のPLCの情報モデルが最適であるかの議論もあると想定される。

今後については、VOCも取り込みながら、この標準化をより多くの製造現場・業界等に広める活動を進める。また、今回実現された技術は他の標準化や機能追加時等、様々に適用可能である。今後の標準化や機能を更に進化させるよう、技術の展開や課題解決への貢献を目指す。

最後に、本稿で紹介した技術・機能や製品の実現にあたり多大なご協力を頂いた方々、また、この機能や製品の今後の展開などにご協力頂く全ての方々に、この場を借りて深く感謝申し上げる。

参考文献

1）

OPC Unified Architecture Core, OPC10000, 2016-2024.

2）

オムロン株式会社. “オリジナル解説 OPC UAとは？” 特設サイト. https://www.fa.omron.co.jp/product/special/sysmac/nx1/opcua.html（Accessed: Jan. 19, 2024）.

3）

小川喜明. “OPC UAのFA適用におけるソリューション事例.” 日本OPC協議会 OPC UAソリューション紹介セミナー. https://jp.opcfoundation.org/wp-content/uploads/sites/2/2022/09/OPC-UA-Seminar_Session4_Omron.pdf（Accessed: Aug. 26, 2022）.

4）

植木琢也. “複雑化する製造業のデータ活用を支える標準化.” 日本OPC協議会 OPC Day2023. https://jp.opcfoundation.org/wp-content/uploads/sites/2/2023/12/1-3_Standardization%E3%83%BCOPC-UA_for_PackML%E3%83%BC.pdf（Accessed: Dec. 7, 2023）.

5）

OPC UA for PackML, OPC30050, 2020.

6）

オムロン株式会社. Sysmac Library ユーザーズマニュアル OPC UA PackML ライブラリ編　形SYSMAC-XR101, SBCA-505B.（2023）. Accessed: Jan. 19, 2024. ［Online］. Available: https://www.fa.omron.co.jp/data_pdf/mnu/sbca-505b_sysmac-xr101.pdf?id=3459.

7）

川野俊充, “ドイツのモノづくり政策Industrie4.0が狙う製造業の標準化戦略,” 日本ロボット学会誌, vol. 33, no. 5, pp. 318-324, 2015.

8）

小川紘一. “オープン＆クロ―ズ戦略とそのビジネス展開.” エンジニアリング協会 2023年度 第6回 エンジニアリングの最新DXセミナー第3期. https://www.enaa.or.jp/?fname=DX2023-6.pdf（Accessed: Dec. 22, 2023）.

9）

江藤学, “欧州企業の標準化戦略,” 研究・技術計画学会 年次学術大会講演要旨集, 2013, vol. 28, p. 954-959.

10）

徳田昭雄 他, オープン・イノベーション・システム, 初版. 晃洋書房, 2011.

11）

新宅純二郎, “アーキテクチャ分析に基づく日本企業の競争戦略,” MMRC Discussion Paper, no. 54, 2005.

12）

片野浩一, 西尾チヅル, “マス・カスタマイゼーション戦略における顧客インターフェイスとデカップリング・ポイントの効果,” 流通研究, vol. 7, no. 2, pp. 19-37, 2004.

13）

小野晃典, “カスタマイゼーションとパーソナライゼーション,” マーケティングジャーナル, vol. 40, no. 1, pp. 3-5, 2020.

14）

小野晃典, “マス・カスタマイズ製品の購買意図,” 三田商学研究, vol. 50, no. 2, pp. 1-18, 2007.

15）

片野浩一, “マス・カスタマイゼーション戦略から個客経験の共創へ,” 明星大学経営学研究紀要, no. 7, pp. 45-58, 2012.

16）

OPC UA Information Model for IEC 61131-3, OPC30000, 2010-2020.