はじめに

ソフトウェア工学の分野では、長年にわたり 構造化設計、モジュール化、抽象化 といった設計思想が発展してきました。
これらの考え方は、ソフトウェアの規模が拡大し複雑化する中で、システムを理解しやすくし、保守や拡張を行いやすくするために整理されてきたものです。

一方で、PLCを中心とした制御ソフトウェアの世界では、これらの設計思想が必ずしも体系的に共有されているとは言えない場面も見られます。その背景には、PLCの歴史や開発文化が関係していると考えられます。

本ページでは

ソフトウェア開発の歴史
PLC文化の特徴
日本と海外の開発スタイルの違い

などを踏まえながら、

制御ソフトウェア設計の考え方がどのように変化してきたのか

を、シーテックの視点から整理します。

初期コンピュータ時代のプログラム

コンピュータの初期時代には、現在のような設計思想が確立されていたわけではありません。
1970年代から1980年代初期のコンピュータでは、

メモリ容量が非常に小さい
CPU性能が限られている

といった制約がありました。

そのためプログラム開発では、

限られたメモリや処理能力を最大限に活用すること

が重要なテーマでした。

この時代のソフトウェア開発ではアセンブリ言語が主流であり、

命令数を減らす
メモリを節約する
処理速度を最大化する

といった目的のために高度な最適化技術が用いられていました。
このようなプログラムは、しばしば「職人的な技術」と表現されることもあります。

ただしその一方で、

プログラム構造が理解しにくい
他の技術者が修正しにくい
長期保守が難しい

といった課題もありました。

例えば、アポロ計画で月面着陸を実現した Apollo Guidance Computer も、現在のコンピュータと比べると非常に限られたメモリ容量で動作するシステムでした。このような制約の中で開発されたソフトウェアは、技術的には非常に高度なものである一方、人間が理解しやすい構造とは限らないという側面もあったとされています。

ソフトウェア危機とソフトウェア工学

コンピュータの普及とともに、ソフトウェアの規模は急速に拡大しました。その結果、

バグの増加
修正の困難さ
開発期間の長期化

といった問題が顕在化しました。

この状況は ソフトウェア危機（Software Crisis） と呼ばれています。
この問題に対応するために発展してきたのが ソフトウェア工学です。

ソフトウェア工学では、

構造化設計
モジュール化
抽象化

といった考え方が整理されてきました。
これらは 人間が理解できる構造を持ったソフトウェアを設計するための方法論 と言えます。

【図】ソフトウェア設計思想の進化

職人的プログラム
        ↓
ソフトウェア危機
        ↓
構造化設計
        ↓
モジュール化
        ↓
オブジェクト指向
        ↓
ソフトウェアアーキテクチャ

PLCの誕生とラダー言語

PLCは リレー回路をソフトウェアで置き換える装置 として誕生しました。
そのためPLCの初期言語として採用されたのが ラダー言語（Ladder Diagram） です。

ラダー言語は電気回路図と似た表現を持ち、

電気設計者が理解しやすい
現場保全が確認しやすい

といった特徴があります。

この特徴は製造現場において非常に実用的であり、PLCの普及に大きく貢献してきました。

日本のPLC開発文化

日本の装置産業では 電気設計者がPLCソフトも担当する ケースが比較的多く見られます。

例えば

電気回路設計
↓
PLCラダー作成
↓
装置調整

といった工程を同じ技術者が担当することも珍しくありません。

このような環境では、電気回路に近い表現である ラダー言語 が扱いやすい言語となります。また、日本の製造現場では 現場で理解できること が重視される傾向があります。

このような背景から、ラダーを中心としたPLC開発スタイルが広く普及してきたと考えられます。

海外のPLC開発スタイル

海外のPLC開発では、ラダーに加えて

Function Block
Structured Text
SFC

などの言語を併用するケースも多く見られます。

特に Siemens や Rockwell Automation のPLCでは、これらの言語を組み合わせた開発スタイルが採用されることもあります。

これは ソフトウェア設計の考え方を制御分野にも取り入れようとする動き の一例とも言えるかもしれません。

ソフトウェア文化とPLC文化

【図】ソフトウェア文化 vs PLC文化

ソフトウェア開発
抽象化
モジュール化
アーキテクチャ設計        ↓PLC開発
機器制御中心
ラダー主体
装置個別設計

両者は優劣ではなく、
それぞれの分野の歴史や目的によって形成された文化と考えられます。

しかし装置が高度化する現在では、

両方の考え方を融合した設計

が重要になってきているように感じています。

PLCソフトウェアが複雑化する理由

PLCプログラムでは、

工程ロジック
機器制御
センサ処理
品種条件

といった異なる役割の処理が同じプログラムに存在することがあります。

このような構造では、

プログラムの巨大化
修正箇所の不明確化
変更影響の拡大

といった問題が発生する場合があります。

【図】PLCソフトが複雑化する典型構造

制御ソフトウェアの構造化という考え方

こうした問題に対応するために、制御ソフトウェアでも 役割を分離した設計 を取り入れることが有効ではないかと考えています。

例えば

工程ロジック
装置の能力
物理機器制御

といった役割を分けて設計することで、

装置変更への対応
保守性
拡張性

を改善できる可能性があります。

【図】機能分離された制御構造

PLC設計思想の進化

【図】PLC設計思想の進化

リレー回路
      ↓
ラダーPLC
      ↓
装置個別設計
      ↓
構造化制御（これから）

現在、制御システムの役割は

ロボット
サーボ
画像処理
データ連携

などへ広がっています。

このような状況では、
制御ソフトウェアをより構造的に設計する考え方 が
重要になっていく可能性があります。

まとめ

ソフトウェア開発の世界では、職人的なプログラム開発の時代を経て、

構造化設計
モジュール化
抽象化

といった設計思想が整理されてきました。

一方、PLCの世界ではリレー回路を起源とする開発文化の影響もあり、装置ごとの設計が中心となってきたという背景があります。

しかし現在では、制御ソフトウェアの役割は急速に拡大しています。

その中で、

ソフトウェア工学の考え方と
製造現場の実用性を両立させた制御設計

を目指していくことが、今後ますます重要になっていくのではないかと考えています。

制御設計支援のご相談

シーテックでは

PLC更新
制御ソフト設計
制御ソフト構造の整理
標準化設計支援

を通じて、製造装置の制御システムを
長期に運用できる構造へ整える支援を行っています。

制御設計思想の変遷