VITALIFY.ASIA logo

なぜヨーロッパの工場はデータが崩れないのか - ISO 81346の思考法に学ぶ

ISO 81346は、工場・プラント・建築物・電気設備などの機器や構造を一貫したIDで管理するための国際規格です。本記事では、機能・製品・場所の3アスペクト、参照指定システム(RDS)、1文字コードの考え方、設備変更に強いID設計、デジタルツインのデータ管理への活用方法を解説します。

なぜヨーロッパの工場はデータが崩れないのか - ISO 81346の思考法に学ぶ
目次

「工場やプラントのデジタルツインを作ってみたものの、設備変更のたびにデータが崩壊して困っている……」

「CAD設計者、電気担当、プログラマー、保全チームで機器の呼び方がバラバラで会話が噛み合わない」

製造業やITの現場でよく耳にするこうした悩み。自分たちも気になって調べてみたところ、どうやらその背景には「データの命名ルール(ID管理)」の壁があることが見えてきました。

そして、この問題を解決するために海外(特にヨーロッパ)で広く使われているのが、「ISO 81346(IEC/ISO 81346)」という国際規格なのだそうです。

最初は「なんだか難しそうな工場・図面の古いルールなのかな?」と思って調べていたのですが、掘り下げてみると「複雑なシステムを頭良く整理するための抽象化思考ツール」として非常に完成度が高く、目からウロコの連続でした。

今回は、素人目線ながら「調べて分かったこと」をわかりやすくまとめてみました。

そもそも ISO 81346 ってなに?

調べてみると、ISO 81346(または IEC/ISO 81346)は、産業プラント、機械、建築物、電気設備など、あらゆるシステム内の「構造」や「機器」に対して、一貫した名前(ID)を割り当てるための国際標準ルール(参照指定システム:RDS)とのことでした。

ISO(国際標準化機構)とIEC(国際電気標準会議)が共同で制定したもので、日本では JIS B 0142 として標準化されています。

なぜこれが注目されているのか?

大きな工場や複雑なシステムを作るとき、現場では部門ごとに好きな名前を使いがちです。

  • CAD設計者: 「給水ポンプA」
  • 制御ソフト(PLC)担当: 「P_101_Start」
  • 保全チーム: 「1階奥のモーター」

これだと、仕様変更や故障対応のたびに「どれのこと!?」と確認が発生してしまいます。ISO 81346 は、設計から運用・保守までの全プロセスで「共通のID」を使うことで、情報の食い違いやデータ連携の失敗を防ぐ役割を果たしているようです。

3つのアスペクト(視点)という考え方

調査していて「これはすごい!」と感じたのが、ISO 81346 のコアにある「3つのアスペクト(視点)」という整理術です。

私たちは普段、無意識に「機器の名前」と「置かれている場所」を混ぜて名前をつけてしまいがちですが、この規格ではそれらを明確に記号で区別して整理します。

アスペクト記号意味・視点質問のイメージ具体例
機能(Function)= それが何をするか(役割)何のための系統?冷却機能、給水機能
製品(Product)-それが何でできているか(物理部品)どの型番の部品?モータ、ポンプ実体、バルブ
場所(Location)+それがどこにあるか(空間)どこに置いてある?キャビネットA、101号室

例:1台の「給水ポンプ」はどう表現される?

例えば、1台の給水ポンプがある場合、次のように書き分けます。

  • =G1 :給水(機能グループ1)
  • -P1 :ポンプ(物理機器1)
  • +R101 :101号室(設置場所)

組み合わせることで、「どこ(+R101)にある、何の役割(=G1)をする、どの部品(-P1)」かが一目でわかる仕組みになっています。

なぜ分けると便利なのか?

もしポンプが壊れて、別の型番のポンプに交換したとします。

従来の方法(名前と場所が混ざったID)だと、IDそのものが変わってしまうため、プログラムや図面、台帳をあちこち修正する必要がありました。

しかし、ISO 81346 の考え方なら「機能(=G1)」や「場所(+R101)」はそのままです。変わるのは「製品(-P1)」の型番データだけなので、制御プログラムや図面の参照を書き直さずに済みます。これは確かに合理的です。

「野良デジタルツイン」が直面する壁とは?

最近よく聞く「デジタルツイン(現実の工場を仮想空間に再現する技術)」ですが、この ISO 81346 のような命名ルールを知らずに独自ルールで作ってしまうケース(いわゆる「オレオレデジタルツイン」)も多いようです。

独自ルールで作られたデジタルツインは、初期のデモ(PoC)では綺麗に動いて感動されるものの、本番運用や設備改修のタイミングで限界を迎えることが多いと分かりました。

設備を入れ替えた時
IDルールが破綻して、3Dモデルやプログラムを手動で直す作業に追われる。

他のシステムと繋ぐ時
基幹システム(ERP等)とIDが合わず、手作業で対応表(マッピング)を作り続けるハメになる。

ヨーロッパ(特にドイツ)などでは、こうした過去の失敗経験から「まず ISO 81346 のような共通データ構造を決めてから、3D化やシステム化に入る」という手順が定着しているようです。

記号の割り当て(1文字コード)が知的なパズルのようで面白い

ISO 81346-2 では、機器や機能を分類するための「1文字コード(アルファベット1文字)」が定められています。これも調べていくと非常に面白いルールでした。

多くの人は「ポンプ=P」「モータ=M」のように英語の頭文字で分類しがちですが、この規格では「それがどんな物理的作用(目的)を持っているか」で分類されています。

代表的な1文字コード(調べてまとめた一覧)

コード目的・タスク(作用)対象になるものの例
B状態を検出・測定するセンサー(温度・圧力)、スイッチ
Cエネルギーや物質を蓄えるコンデンサ、バッテリー、受水槽
E光や熱を放射する照明、ヒーター、レーザー
F危険や過負荷から保護するヒューズ、安全弁
Gエネルギーを供給・発生させる発電機、電源装置
K信号や情報を処理するPLC(CPU)、制御リレー
M目的の動作(機械エネルギー)を提供するモータ、シリンダ
P物質の流れを導く・変換する給水ポンプ、トランス
Q流れを開閉・制御するブレーカ、開閉バルブ
R流れを制限・安定化させる抵抗器、減圧弁
S人間からの操作を信号に変えるボタン、タッチパネル
T物質・エネルギーを運ぶ(維持・転送)配線、配管、コンベア

「名詞」ではなく「目的」で分類する

例えば「バルブ(弁)」ひとつとっても、用途によってコードが変わります。

  • 単に開け閉めするバルブ ➔ Q (開閉・制御)
  • 流量を絞って調整するバルブ ➔ R (制限・安定化)
  • 圧力を逃がす安全弁 ➔ F (保護)

「名前(バルブ)」ではなく「そこで何をしているか(作用)」で分類されているため、電気・機械・プラントといった専門分野を超えて同じ記号で話ができる仕組みになっています。

もし自社で試すなら?(スモールスタートのコツ)

この規格、全部を完璧に導入しようとすると大変そうですが、まずは最小限のルールだけ借りてスモールスタートするのがおすすめです。

ポイントは以下の3点です。

「機能(=)」と「製品(-)」のIDを分ける
「役割」と「型番(物理的なモノ)」を分けて管理するだけでも、将来の修正作業がかなり楽になります。

プレフィックス記号(= - +)を使ってみる
IDの頭に記号をつけるだけで、「これは機能のことだな」「これは設置場所だな」とチーム内で共通認識が持ちやすくなります。

まずは1文字コードの大分類だけ使ってみる
細かな分類まで一気に決めず、「M=動作」「B=センサー」といった大まかな1文字コードから少しずつ馴染ませていくのがコツのようです。

おわりに:システム思考のヒントとしても面白かった

今回 ISO 81346 について調べてみて感じたのは、単なる「工場や図面の固いルール」という枠を超えて、「複雑なものを整理して捉えるための思考フレームワーク」としてすごくよくできているな、ということです。

例えば、プログラミングの設計で「機能と実装を分ける」考え方や、ビジネスの業務プロセスを「検出(B)」「判断(K)」「実行(M)」「保護(F)」といった役割で整理してみるなど、身近な整理術としても応用できそうな発見がありました。

もし「データの命名規則や構造化で困っている」「デジタルツインのデータ管理に悩んでいる」という方がいれば、この ISO 81346 の考え方を覗いてみると、何かヒントが見つかるかもしれません!

1,000社以上の事業成長を支えた圧倒的な『スピードと柔軟性』で、御社のアイデアを最短で形にします。まずは無料で壁打ちしませんか?

ブログに戻る
ぼくはデューパー、なんでもきいてね!