ファンクションブロックとは？FBDの書き方

PLCのプログラムを見直したとき、箱と線だけで処理の意味が追えれば、現場保守はかなり楽になります。

接点とコイルのラダー図だけで複雑な演算を組むと、比較や補正が増えるほど全体像が読みにくくなります。

ファンクションブロックとは、入力、処理、出力をひとまとまりの部品として扱う設計上の考え方です。

FBDは、その部品を線でつないでデータの流れを表す、PLC制御向けの標準グラフィック言語です。

本記事では、ファンクションブロックの意味、FBDの書き方、ラダー図との使い分け、保守時の注意点を実務目線で解説します。

1. ファンクションブロックとは：処理を部品として扱う考え方

ファンクションブロックとは、一定の入力を受け取り、決められた処理を行い、結果を出力する制御用の部品です。

電気図面でタイマやリレーを部品として扱うように、PLCプログラムでも処理のまとまりを一つの箱として扱います。

FBDを理解する第一歩は、箱の中身を全部読むことではなく、箱の外側にある入力端子と出力端子を正しく読むことです。

たとえば温度入力を受けて上限警報を出す処理なら、温度、しきい値、警報許可が入力になり、警報出力が結果になります。

このように部品単位で考えると、処理の目的、必要な信号、外へ渡す結果が分離されるため、後からの修正範囲も見えやすくなります。

入力、処理、出力を一つの箱にまとめる

ファンクションブロックを箱として見ると、左側に入力、中央に処理名、右側に出力が並ぶ形になります。

入力にはセンサ値、操作スイッチ、許可信号、設定値などが入り、処理は比較、演算、時間計測、状態保持などを行います。

出力にはランプ点灯、モータ起動指令、異常フラグ、計算後の数値などが出てきます。

この形を守ると、処理を読む人は「何を入れて、何を判断し、何が出るのか」を順番に確認できます。

特にFBDでは線が多くなるほど画面が混みやすいため、箱の目的が名前だけで分かることが重要です。

たとえば「TEMP_ALM」だけでは警報なのか警報条件なのか曖昧ですが、「HighTempAlarm」とすれば上限温度警報の部品だと分かります。

処理の箱を増やすほど便利になる一方で、名前が雑だとブラックボックス化してしまいます。

部品化の目的は隠すことではなく、読み手が必要な粒度で処理を追えるように整理することです。

ファンクションブロックは内部状態を持てる

PLCで使う部品には、ファンクションとファンクションブロックという似た言葉があります。

ファンクションは基本的に、その時点の入力だけで結果が決まる処理です。

加算、減算、AND、OR、大小比較のように、同じ入力であれば同じ出力を返す処理が該当します。

一方のファンクションブロックは、状態を持つ部品として扱える点が重要です。

タイマなら経過時間、カウンタなら現在のカウント値、フリップフロップなら保持中の状態を内部に持ちます。

そのため、同じ入力を与えても、過去の動作履歴によって出力が変わることがあります。

たとえばオンディレイタイマでは、入力がONになった直後と5秒経過後では同じON入力でも出力が変わります。

この違いを理解せずに同じ部品を複数箇所で使い回すと、意図しない状態共有やリセット漏れを招く可能性があります。

実務では、記憶を持つ処理には必ず個別のインスタンス名を付け、どの設備や条件の状態なのかを明確にします。

このインスタンス名の管理こそが、FBDを安全に使ううえでの基本です。

2. FBDとは：ブロックと線でデータの流れを書く言語

FBDはFunction Block Diagramの略で、ファンクションやファンクションブロックを図として配置し、線で接続して処理を表します。

接点の導通を読むラダー図と違い、FBDでは信号や数値がどのブロックを通ってどの結果になるかを追います。

そのため、アナログ値のスケーリング、上限下限の比較、PID演算、複数条件の組み合わせなどを表しやすい書き方です。

プログラムというより、制御ロジックの信号線図を描く感覚に近いと考えると理解しやすくなります。

ただし、見た目が図であることと、自由に線を引いてよいことは同じではありません。

実際には、データ型、実行順序、インスタンス、スキャン周期を意識して設計する必要があります。

左から右へ処理を読むのが基本

FBDの最も基本的な読み方は、入力信号を左側から受け取り、右側へ向かって処理結果を渡すことです。

ツールやメーカーによって細かな表示は違いますが、読み手が迷わない図にするには、左から右へ流す配置を徹底します。

たとえば「温度入力を比較し、警報条件を作り、タイマで遅延し、警報出力へ渡す」という処理は左から右へ一直線に並べます。

途中で線を戻したり、上下に大きく回り込ませたりすると、処理の順番と信号の依存関係が分かりにくくなります。

FBDの線は単なる見た目の配線ではなく、あるブロックの出力が次のブロックの入力になることを示します。

そのため、ある出力を複数のブロックへ分岐させる場合は、分岐先が同じ意味の信号を使っているかを必ず確認します。

一つの比較結果を警報表示にも停止条件にも使う場合、警報表示と設備停止では求められる安全側の考え方が異なることがあります。

同じ線を便利に分岐させる前に、その信号がどのレベルの責任を持つ条件なのかを整理しておくことが大切です。

変数、端子、ネットワークで構成を分ける

FBDでは、ブロックに接続される信号は変数として扱われます。

変数にはBOOL、INT、REAL、TIMEなどのデータ型があり、入力端子と出力端子の型が合っていないと正常に接続できません。

BOOLはON/OFFの論理、INTは整数、REALは実数、TIMEは時間を扱う型として使われます。

たとえば温度計の値をREALで扱うのに、比較先のしきい値を整数のままにすると、小数点以下の扱いが曖昧になります。

また、FBDエディタでは処理をネットワーク単位で区切ることがよくあります。

一つのネットワークに多くのブロックを詰め込むと、横に長くなり、画面スクロールなしでは流れを追えなくなります。

実務では「入力変換」「条件判定」「出力生成」「異常保持」のように、目的ごとにネットワークを分けると保守しやすくなります。

ネットワークの分け方は動作そのものだけでなく、後から読む人がどこを見ればよいかを決める設計でもあります。

PLCの入出力信号を整理する考え方は、I/Oとは何かでも詳しく扱っています。

3. IEC 61131-3での位置づけ：標準言語としてのFBD

FBDは、PLCのプログラミング言語を標準化するIEC 61131-3に含まれるグラフィック言語です。

この規格は、メーカーごとに異なっていたプログラムの考え方を統一し、設計、保守、教育を進めやすくする役割を持ちます。

日本ではJIS B 3503として対応する規格体系があり、PLCopen Japanも普及活動を行っています。

現場では「IEC 61131-3の5言語」と説明されることが多いものの、2025年版ではILの扱いが変わっている点に注意が必要です。

記事としては古い説明をそのまま繰り返すより、現在の規格と現場で残る慣用的な説明を分けて理解する方が正確です。

従来の5言語説明と2025年版の違い

従来のIEC 61131-3では、LD、FBD、ST、ILに加えて、SFCを含めて5言語として説明されることが一般的でした。

LDはラダー図、FBDはファンクションブロック図、STは構造化テキスト、ILは命令リスト、SFCはシーケンス制御の構造を表します。

一方でIEC 61131-3:2025では、言語の中心としてST、LD、FBDが示され、SFCはプログラムやファンクションブロックを構造化する要素として扱われます。

また、ILは古い環境で残っていても、新しい設計で積極的に選ぶ言語ではありません。

そのため、FBDの記事で重要なのは「FBDはIEC 61131-3で標準化されたグラフィック言語である」という点です。

現場の既存設備では旧来のILやSFCの説明が残ることもありますが、新規設計では可読性と保守性を重視して言語を選ぶ必要があります。

略称	名称	主な表現	実務上の向き不向き
LD	ラダー図	接点とコイル	リレー回路、ビット論理、インターロックに向きます。
FBD	ファンクションブロック図	箱と線	演算、比較、アナログ処理、部品化に向きます。
ST	構造化テキスト	文字コード	複雑な計算、配列処理、条件分岐に向きます。
SFC	シーケンシャルファンクションチャート	ステップと遷移	工程順序や状態遷移の整理に向きます。
IL	命令リスト	命令列	既存設備の保守で見ることはありますが、新規設計では優先度が下がります。

POUとインスタンスを理解すると混乱しにくい

IEC 61131-3の考え方では、プログラム、ファンクション、ファンクションブロックをPOUとして整理します。

POUはProgram Organization Unitの略で、制御プログラムを管理しやすい単位に分ける考え方です。

このうちファンクションブロックは、使用するときにインスタンスとして呼び出されます。

インスタンス名は、同じ型のファンクションブロックを複数使うときの個別名です。

たとえば同じオンディレイタイマ型を使っても、ポンプ起動遅延用なら「PumpStartDelay」、警報遅延用なら「AlarmDelay」のように別名にします。

この2つは同じタイマ機能を持っていますが、経過時間や完了状態は別々に保持されます。

逆に、同じインスタンスを複数箇所で不用意に参照すると、片方の処理がもう片方の状態に影響することがあります。

FBDで起きる読みにくさの多くは、ブロックの機能そのものより、インスタンス名と状態の関係が曖昧なことから生まれます。

PLC全体の役割やスキャン処理の前提は、PLCとは何かの理解と合わせると整理しやすくなります。

4. FBDが向く処理：演算、比較、連続制御を見える化する

FBDは、信号を処理ブロックへ入れ、結果を次のブロックへ渡す流れが見えるため、演算や比較の多い処理に向いています。

ラダー図でも同じ処理は書けますが、接点の直列並列が増えると、数値演算の流れや変換の順番が見えにくくなります。

温度、圧力、流量、速度、位置などのアナログ量を扱う場面では、FBDの箱と線の表現が強みになります。

特にプロセス制御や装置の条件判定では、複数の値を比較し、許可条件や異常条件を作る処理が多くなります。

FBDはその条件の組み立てを視覚的に示せるため、試運転時の確認や保全担当者への説明にも向いています。

アナログ処理とPID制御を整理しやすい

アナログ入力を使う処理では、センサ値をそのまま使うのではなく、スケーリング、フィルタ、上下限監視、補正を行います。

たとえば4mAから20mAの信号を0度から200度の温度に変換し、その値を上限警報や制御演算へ渡す流れがあります。

FBDでは、入力変換ブロック、フィルタブロック、比較ブロック、警報ブロックを順番に並べれば、信号の加工手順が見えます。

PID制御でも、目標値、現在値、偏差、出力制限、手動自動切替をブロックとして整理できます。

このとき重要なのは、演算結果だけでなく、単位と有効範囲を変数名やコメントで残すことです。

「TempPV_degC」「ValveOut_percent」のように単位を意識した名前にすると、後からスケール違いを発見しやすくなります。

制御量の補正やPID動作を詳しく扱う場合は、PID制御とは何かも関連します。

FBDはPIDの理論を置き換えるものではなく、現場で必要な入出力と補助条件を読みやすく接続するための表現です。

ラダー図やSTと役割分担すると使いやすい

FBDが便利だからといって、PLCプログラムをすべてFBDで書く必要はありません。

押しボタン、リミットスイッチ、電磁接触器のようなON/OFF条件は、ラダー図の方が電気図面に近く読みやすい場合があります。

逆に、配列をループで処理したり、複雑な条件分岐を文章のように書いたりする処理はSTの方が向くことがあります。

FBDは、信号の流れを図として見せたい処理に使うと効果が大きくなります。

たとえば安全インターロックの最終接点はラダー図で表し、温度や圧力の前処理はFBDで表す構成が考えられます。

また、工程の順序をSFCで整理し、各ステップ内の演算や条件判定をFBDで書く方法もあります。

このように言語を役割で分けると、各担当者が得意な視点でプログラムを読めます。

制御の全体像を理解するうえでは、シーケンス制御とは何かとFBDの関係を意識するとよいです。

処理内容	向く表現	理由
リレー的なON/OFF条件	LD	接点とコイルで、電気図面に近い読み方ができます。
アナログ値の変換と比較	FBD	信号の加工順と比較結果を線で追いやすくなります。
PIDや補正演算	FBDまたはST	標準ブロックならFBD、独自計算が多いならSTが向きます。
配列、ループ、文字列処理	ST	図よりもコードの方が短く正確に書ける場合があります。
工程順序、状態遷移	SFC	ステップと遷移条件として、工程の順番を整理できます。

5. FBDの書き方：いきなり箱を置かず信号から分解する

FBDを書くときに失敗しやすいのは、先にブロックを探して画面へ並べてしまうことです。

ブロックから考えると、便利そうな部品をつないだだけの図になり、処理の目的が曖昧になります。

最初に決めるべきことは、設備として何を入力し、どの条件で何を出力するのかです。

つまり、FBDはプログラム画面から始めるのではなく、入出力表と動作仕様から始めます。

この準備を行うだけで、ブロックの数、配置、変数名、ネットワーク分割が自然に決まりやすくなります。

Step 1：仕様を入力、処理、出力に分ける

まず、制御仕様を入力、処理、出力の三つに分解します。

たとえば「タンク温度が80度を超えた状態が3秒続いたら警報を出す」という仕様を考えます。

入力はタンク温度、警報許可、リセット信号であり、設定値は80度、遅延時間は3秒です。

処理は温度比較、警報許可とのAND条件、オンディレイタイマ、警報ラッチの順に分けられます。

出力は温度高警報、HMI表示用フラグ、ブザー指令、上位監視へ渡す異常コードなどになります。

この分解をしないままFBDに入ると、比較条件と出力条件が同じネットワークに混ざり、修正時に影響範囲が分かりません。

特に異常や停止を伴う処理では、表示だけの条件と設備を止める条件を分けて設計します。

入力、処理、出力の分解表を作ってからFBDへ落とし込むと、レビュー時にも仕様との対応が説明しやすくなります。

分類	例	FBDでの扱い
入力	温度、圧力、運転許可、リセット	左側に置き、型と単位を明確にします。
設定値	上限値、下限値、遅延時間	定数化せず、調整可能な変数として扱います。
処理	比較、AND、タイマ、ラッチ	目的ごとにブロックを分け、線を短く接続します。
出力	警報、停止、表示、ログ	右側にまとめ、責任範囲を分けます。

Step 2：ブロックを配置して配線を短くする

仕様を分解したら、次にブロックを左から右へ配置します。

入力変換、条件判定、時間判定、状態保持、出力生成の順に並べると、処理の流れが自然になります。

このとき、線が交差しないようにブロックの上下位置を調整します。

線が交差しているFBDは、動作として正しくても、読み手が信号を取り違える危険があります。

また、同じ信号を何度も遠くへ引き回す場合は、中間変数を作ってネットワークを分けた方が読みやすくなります。

たとえば「運転許可条件」が多くの場所で使われるなら、Permit_Runという中間変数にまとめてから各処理へ渡します。

FBDでは便利なブロックを詰め込むより、配線が短く、信号名が読める配置にすることが重要です。

完成後は、左から右へ説明してみて、途中で言葉に詰まる箇所がないか確認します。

説明できない線や、名前だけでは意味が分からない変数は、将来の保守で必ずつまずく場所になります。

6. 代表的なファンクションブロック：よく使う部品を知る

FBDでは、標準的な演算ブロックや比較ブロックに加えて、メーカーが用意する制御用ブロックを組み合わせます。

どのPLCにも完全に同じ名前で存在するわけではありませんが、考え方は多くの環境で共通します。

よく使う部品の意味を知っておくと、他人が作ったFBDも読みやすくなります。

ただし、同じ名前に見えるブロックでも、入力端子の意味、リセット条件、初期値、エラー出力はメーカーごとに差があります。

実務では、標準的な呼び方を覚えるだけでなく、使用するPLCのヘルプや命令リファレンスで端子仕様を確認します。

論理、比較、演算ブロック

論理ブロックは、AND、OR、NOTのようにBOOL信号を組み合わせる部品です。

複数の許可信号をANDでまとめたり、異常条件をORでまとめたりするときに使います。

比較ブロックは、GT、GE、LT、LE、EQのように数値の大小や一致を判定します。

温度が上限以上、圧力が下限未満、速度が設定値と一致、といった条件をBOOL結果として出力します。

演算ブロックは、ADD、SUB、MUL、DIV、MIN、MAXのように数値を加工します。

センサ値の平均、上下限の丸め、速度から距離への換算、係数補正などに使います。

これらのブロックは記憶を持たない処理が多いため、同じ入力なら同じ出力になります。

ただし、入力の評価順やデータ型の違いによって、見た目より結果が変わることがあります。

しかし、DIVで0割りが起きる場合や、型変換で小数が丸められる場合など、単純な演算でも注意点はあります。

種類	代表例	確認ポイント
論理	AND、OR、NOT	安全条件と表示条件を同じ信号で兼用しないことです。
比較	GT、GE、LT、LE、EQ	以上、超過、以下、未満の境界を間違えないことです。
演算	ADD、SUB、MUL、DIV	単位、型、0割り、桁あふれを確認することです。
制限	LIMIT、SEL、MUX	異常値や手動自動切替時の出力を確認することです。

タイマ、カウンタ、PID、エッジ検出

FBDで実務上よく使う状態付きブロックとして、タイマ、カウンタ、PID、エッジ検出があります。

オンディレイタイマは、入力がONになってから設定時間が経過した後に出力をONにします。

オフディレイタイマは、入力がOFFになった後もしばらく出力を保持したいときに使います。

カウンタは、ワーク個数、異常回数、リトライ回数などを数えるときに使います。

PIDブロックは、目標値と現在値の差から操作量を計算し、温度や流量などの連続量を制御します。

エッジ検出は、信号がOFFからONへ変わった瞬間、またはONからOFFへ変わった瞬間だけ処理したいときに使います。

これらは内部状態を持つため、リセット条件と初期状態を必ず設計します。

たとえばカウンタのリセット漏れは、次のロットへ前回の数を持ち越す原因になります。

タイマの設定時間をHMIから変更できる場合は、0秒や異常に長い値が入ったときの動作も確認しておく必要があります。

HMI側で設定値を扱う場合は、HMIとは何かと合わせて、画面表示名とPLC変数名の対応をそろえることが重要です。

7. FBDの実務例：温度警報とポンプ運転許可で考える

FBDの理解は、抽象的な説明だけではなかなか定着しません。

ここでは、現場でよくある温度警報とポンプ運転許可を例に、どのようにブロックへ分解するかを考えます。

どちらの例も、単純なON/OFFだけでなく、比較、時間、許可条件、リセットを含みます。

こうした処理はラダー図でも書けますが、FBDで書くと信号の加工手順が見えやすくなります。

大切なのは、最初から完璧な図を描こうとせず、仕様を小さな判断単位へ分けてから接続することです。

温度高警報：比較とタイマで誤検出を防ぐ

温度高警報では、温度がしきい値を超えた瞬間に警報を出すと、ノイズや瞬間的な揺れで誤検出が起きます。

そのため、まず温度現在値と上限設定値を比較し、比較結果が一定時間続いたときだけ警報を出す構成にします。

FBDでは、温度現在値をGTブロックへ入れ、もう一方に上限設定値を入れます。

GTの出力を警報許可信号とANDし、その結果をオンディレイタイマへ接続します。

タイマ完了出力を警報ラッチへ入れ、リセット入力で保持を解除できるようにします。

この構成では、比較、許可、遅延、保持の四つの役割が分かれるため、試運転時の原因切り分けが簡単になります。

警報が出ない場合は、温度比較が成立していないのか、警報許可がOFFなのか、タイマ中なのか、ラッチがリセットされているのかを順番に見られます。

また、上限値に対して復帰値を別に持たせると、しきい値付近で警報がON/OFFを繰り返すチャタリングを抑えられます。

このようなヒステリシスは、アナログ警報では非常に重要な設計ポイントです。

ポンプ運転許可：安全条件と操作条件を分ける

ポンプ運転許可では、運転ボタンだけでなく、液位、バルブ状態、過負荷、非常停止、インターロックを同時に見ます。

FBDで書く場合、まず安全条件と操作条件を別々のネットワークに分けます。

安全条件には、非常停止なし、過負荷なし、液位下限以上、吐出弁開などをANDでまとめます。

操作条件には、自動運転要求、手動起動要求、停止要求、遠隔許可などを整理します。

最後に、安全条件と操作条件を組み合わせて、ポンプ起動指令を作ります。

ここで避けたいのは、画面からの運転要求をそのままポンプ出力へ近い場所で接続してしまうことです。

安全条件を通らない経路が残ると、後から機能追加したときに危険なバイパスになります。

FBDでは線が見えるため、こうしたバイパスの有無をレビューしやすい一方、線を安易に分岐すると見落としも起こります。

ポンプや搬送機のように安全停止が関わる処理では、停止側が必ず優先される配置になっているかを確認します。

8. FBDを保守しやすくする注意点：読める図にする

FBDは図として分かりやすい反面、書き方が悪いと巨大な配線図のようになり、かえって読みにくくなります。

とくに後から機能を追加した設備では、線の引き回し、名前の不統一、同じ条件の重複が増えやすくなります。

プログラムは一度動けば終わりではなく、トラブル対応、仕様変更、担当者交代のたびに読まれます。

したがってFBDでは、動作することに加えて、第三者が短時間で意図を理解できることを品質として扱う必要があります。

ここでは、保守性を落とさないための実務上の注意点を整理します。

命名、コメント、ネットワーク分割を先に決める

FBDの保守性を左右する最初の要素は、変数名とブロック名です。

「M1」「TEMP1」「FLAG_A」のような名前だけでは、設備、単位、用途が分かりません。

最低限、設備名、信号の意味、単位、状態を読み取れる名前にします。

たとえば「TankTemp_degC」「PumpRunPermit」「HighTempAlarmLatch」のようにすれば、画面上の線を追う前に信号の意味を推測できます。

コメントは、ブロックの機能そのものではなく、なぜその条件が必要なのかを書くと効果があります。

「AND条件」ではなく「空運転防止のため液位下限を確認」のように書くと、将来の修正時に削除してよい条件か判断できます。

ネットワーク分割も保守性に直結します。

入力処理、演算処理、異常処理、出力処理を分けておけば、トラブル時に見る場所が限定できます。

多くのブロックを一枚の画面に押し込むより、目的が分かる小さなネットワークに分ける方が、レビューもデバッグも速くなります。

スキャン周期、初期値、安全側の状態を確認する

PLCは周期的に入力を読み、プログラムを実行し、出力を更新します。

そのためFBDの処理も、スキャン周期の中でどのタイミングで評価されるかを意識する必要があります。

短いパルスを扱う場合、スキャン周期より短い信号変化は見落とされる可能性があります。

タイマやエッジ検出を使う処理では、1スキャンだけONになる信号を後段が確実に受け取れるかを確認します。

また、起動直後の初期値も重要です。

前回状態を保持する変数と、起動時に必ずリセットする変数を混同すると、停電復帰後に意図しない出力が出ることがあります。

安全に関わる出力は、安全側の初期状態になるよう設計します。

たとえば通信異常やセンサ断線時に、最後の正常値を保持して運転を続けるのか、異常として停止するのかは仕様で決めるべき内容です。

FBDでは見た目の線だけではこうした前提が伝わりにくいため、初期値、保持条件、異常時動作を変数名やコメントで残します。

スキャン周期の考え方を深める場合は、PLCスキャンタイムとは何かも確認しておくとよいです。

9. まとめ

ファンクションブロックとは、入力、処理、出力を一つの部品として扱うPLCプログラムの考え方です。

FBDは、その部品を箱として配置し、線で接続してデータの流れを表すグラフィック言語です。

ラダー図が接点とコイルによるON/OFF条件に強いのに対し、FBDは演算、比較、アナログ処理、PID、状態付き処理を整理しやすい特徴があります。

一方で、FBDは線が増えるほど読みにくくなるため、左から右への流れ、変数名、ネットワーク分割、インスタンス管理が重要です。

特にタイマ、カウンタ、PIDのような状態を持つブロックでは、リセット条件、初期値、保持条件を明確にしておく必要があります。

FBDを書くときは、いきなりブロックを置くのではなく、仕様を入力、処理、出力に分けてから配置します。

そのうえで、比較、許可、遅延、保持、出力生成の役割を分ければ、試運転時にも保守時にも原因を追いやすくなります。

FBDは「見た目が簡単な言語」ではなく、制御ロジックを部品化し、読みやすく保守するための設計手法です。

部品の意味、信号の流れ、状態の持ち方を意識すれば、複雑なPLC処理でも第三者が追えるプログラムにできます。