130人の声が示すPLCの“現在地” 製造現場が抱える課題、期待を分析 : PLCの現在 過去 未来(2) (5/5 ページ)
アンケートの最後には、PLCについて現場で感じていること、困っていること、伝えたいことを自由記述で回答者に求めた。
学習のハードルがもっと低くなってほしい
高級言語出身者を業界に入れるため、STに特化していくのではないかと考えています。生成AIでプログラム作成している記事やポストもよく見かけるようになってきたのでいろいろ試したいです
PLCからプログラミングを始めたが、意外と悪くないスタート地点だったかもしれない。メリット→必要スキルが少ない(自己保持、歩進)、最終目的が明確(アクチュエータ動かす)。その後は、外部通信から通信規格マニアになっても、ASCIIコードから文字列に思いをはせても、構造化プログラムに行っても、モーターの補間制御から座標変換に行ってもよいし、HMIからUIデザインに詳しくなってもよい
保全用途でよいので無線機能のあるユニットが欲しい
現場の状況や人の動きをセンサーで感じ取り、最適な動きを“自律的に選択”できるPLCを期待しますね。匠の勘に一歩でも近づける存在に
私は社内生産設備の制御設計の仕事をしています。PLCは少ない記述量で簡単に機器を制御できます。また、必ずある立ち上げ時(設計時ではなく)、納入後の動作の変更でも、接点を1つ付け足すだけでできたりもします。しかしそのような変更をした回路は、第三者から見ると理解が難しい回路であり、可読性は悪いと言えます。労働環境のホワイト化(育休を皆が取る、外注業者も早く帰る)により、1人で最初から最後までソフトの面倒を見ることは少なくなり、複数人が同じソフトを見るようになってきている状況なので、可読性がより一層求められています。この点でIPCに希望を見いだしています(まだ使ったことはないでので的外れな願望かもしれませんが)
ハードPLCエンジニアの守備範囲を広げにくい。PC制御がある程度でも理解できるラダー屋が現状は極めて少なく、開発プロセス、設計手法の発展が高級言語に比べると明らかに遅い
ラダーや画面をAIで入力補助できるようにMCP(Model Context Protocol)のようなものを各社公開してほしい
長期在庫保証をメーカーがうたう間は(PLCは)なくならないのではないかと考えてます
最終ユーザーとして、いまだに新設設備のPLCが最新のPLCでない現状に危機感を覚えます。ユーザー、装置メーカーともにレベルアップしていきたいのですが……
一時期の三菱長納期の際に、勤めている会社では一気にキーエンスが食い込みましたが、キーエンスPLCのドラレコ機能は本当に便利で感動しました。三菱PLCの設備トラブルとは気持ちの楽さが全然違います
開発環境がとにかくとっつきづらい
今後、STなどのラダー以外で作る設備が増える一方、今日までにラダーで作られた設備が存在している以上、ラダーがなくなることはないし、これまで以上にラダーが理解できる人の価値は高まるのではないかと思う。また生成AIの発展に伴い、高級言語を0→1で書ける人のバリューも下がる可能性もあるので、ラダー+生成AIの活用が求められる時代かと思う
皆、設備仕様書書くならラダー図プログラムの仕様書も書こう。せめてデバイスコメントを残してほしい
OT系エンジニアが増えている感触がなく、今後が不安。IT系のエンジニアがプログラミングできるような方向に流れていく可能性が高いが、装置や設備の自動制御についての幅広い知見がないと物理現象をつかさどることは難しい
今のPLCはさまざまな機器に細分化、複雑化しておりそれがこれからPLCを学ぶ新人の方にとって大きな障壁になっていると感じます
e-LearningやYouTubeを活用したエントリーユーザー向けの解説を充実させていただきたいと思っております
当社では、ゼロから電機設計はしませんが、外部に発注して導入した装置のPLCを触って、適宜改善を自分たちで行っています。ただ、その履歴管理やなぜそうしたのか?という記録が残りにくく、特に軽微な修正は知らぬ間に行われていることがあり、後々影響が出てくることがあります。そういった事象をうまく管理する手法などがあれば知りたい&検討したいです
オムロンもキーエンスのようにI/O番号を分かりやすくしてほしいですね。安くて使いやすいのに説明書を見ずに使うのが難しい。オムロンとキーエンスの昔の取説でプログラムを組んでいます。昔の取説の方が読みやすい
ベッコフ以外のメーカーが開発環境を有償にしているのは課題と思います。せめて商用利用以外は無償にした方が良いかと思っています
関連技術書が進歩しない。情報が少ない
Python、Webと比べてやっていて面白みが感じられない
価格と入手性と情報の分かりにくさが問題
PLCで動かせるもの(アクチュエータなど)とつなぐ際の手間を減らしてほしい
改善、改良を行った際の品質保証、変更点管理のやり方が定まらない
中小零細企業の仕事が大半ですが、通信やST、FBDを要求されるような高度な案件はほとんどありません。ラダーで十分、何ならリレーでも対応可能です。高度な多軸制御の加工機や組み立て機と、後付けの簡易な検査機や工程処理の二分化が進むのではないでしょうか。そうなった場合に、現場で対応できる実戦部隊と開発部隊の乖離(かいり)や対立が発生するのではと危惧しております
PLCの技術者が減っていっている状況を心配しています
一般のプログラマーからすれば、ラダーはとっつきにくいんですかね
昔ながら(といったら失礼になるが)のラダープログラムを扱えるエンジニアが減ってきており、メンテナンスに困っているという声をよく聞きます。COBOLを扱えるエンジニアがいつまでも重宝されるように、ニーモニックを読めるエンジニアがもっと脚光を浴びて(ストレートにいうと高給取りになって)もらいたいです
OPC UAサーバだけでなく、クライアントも持っているPLCがあれば便利
ローコード化で各メーカー互換を望みます
プログラムの規格がない(普及していない)、使い回しができないのが問題で、無駄なエンジ工数が膨大にかかっているのが現状です。統一の規格や使い回しができるようになることで、PLCが発展してほしいです
PLCやPLCとの連携機器など、もっとオープンになって欲しい。現在は囲い込み戦略がすぎる
ラダーしか知らない制御エンジニアの発展性不足
ベンダーロックが非常に邪魔。三菱電機はラベルなど勝手に言葉を作らないでほしい。分かりにくい。生成AIが台頭しているため各メーカーはきちんとした取説を作って欲しい
フィールドバス多すぎ問題。IoTをやろうとしたときのプロトコル変換が面倒
PLCラダーはこれからも現場で生き続けると思います。でも私は、“レアな技術”を磨く道を選びたい
人手も足りないし質も足りていない
プログラムが大きく複雑化しているが、テスト手法は旧態依然なのでバグが増える
遠隔操作機能がほしい
変化を嫌う一部の人間が延々と古いモデルを使いたがるのが困る
生成AIと連携してのソフト開発がどうなっていくか期待しています
いつも試運転時間が足りない
特注の装置で機械設計を担当しているので的外れな回答かもしれないが容赦いただきたい。エンドユーザーごとに違うPLC、その他モータドライバやコントローラー、上位通信方法など近年、安全管理やIoT機能、装置の監視など制御のボリュームがどんどん増えていって、ソフト屋の負担が増加している。制御担当の負担を軽減しないと人手不足で破綻する未来は遠くない。そのため設計開発を容易にし、現場のデバッグを減らし、また誰でも容易にPLCを触れるようになるとよいと思う
属人化、人手不足の課題が大きい。あと、海外の最先端機器などを扱えるようにキャッチアップし続けられるエンジニアが少ない。教育を標準化する環境ないし組織がほぼない。そもそも案件に追われてそのようなキャッチアップが難しい
生産技術からの要求はどんどん複雑になっていて、工場側の要求と板挟み状態です
(IPCなどは)既存のPLCにすぐに代替できるほど便利ではなく、転換期ゆえの難しさを感じる。
フィールドネットワークを統一できたら良いなと思っています。理想のマスターと理想のスレーブがあっても通信規格が合わず部品の選定に苦労してしまうことがあるので
PLCを自由に使いこなせる職人のような人が減ってきていると感じます
いかに使いこなす人を増やすか?だと思います。OJTで自分の会社に合うもののソリューションをお願いしたいところですが、コスト面で無理なことが多いです。コストを抑えたOJTをお願いしたいです。それで生産性が上がって、また導入していく、という好循環に期待です
シンプルにFA業界が縮小していかないか心配です
四則演算をラダーで書くのは地獄。STで書いていけば可読性も上がりますし、修正も楽になります。今後はSTで記述して生成AIでほとんどのコーディングをすることになると思います
改めて、アンケートに協力いただいた皆さまに感謝申し上げます。
⇒その他の連載「PLCの現在・過去・未来」の記事はこちら
岡 実(Minoru OKA) オカピー・パートナーズ代表/中小企業診断士/国家資格キャリアコンサルタント
制御機器メーカー(オムロン)に34年間勤務し、一貫してPLCを中心とした工場自動化機器に関わる。プロダクトマネジャーとして工場IoTや製造業のデジタル化を推進した後、2024年に退職し、個人事業を開業。
現在は、本業である制御システムセキュリティ(OTセキュリティ)のコンサルティングに加え、中小企業の経営・デジタル化支援、キャリア相談、生成AI活用セミナーなども手掛ける。日本OPC協議会マーケティング部会長(2016〜2022年)として、OPC UAの国内普及にも尽力した。
転換期のPLC〜その進化の軌跡と現在地
本稿では、34年間PLCと共に歩んできた筆者の視点から、全3回にわたって今、PLCが迎えている重要な転換期を読み解きます。今回は、まずPLCの進化の軌跡をたどり、その“現在地”を明らかにします。
IEC 61131-3の特長〔前編〕5つのプログラミング言語と変数
「IEC 61131-3」と「PLCopen」について解説する本連載。今回は同規格に規定されている5種類のプログラミング言語と変数について説明します。
IEC 61131-3の最新技術動向とJIS B 3503
「IEC 61131-3」と「PLCopen」について解説する本連載。最終回となる今回は2013年2月に改訂されたPLC用プログラミング言語国際規格「IEC 61131-3 第3版」の内容と、対応するJIS規格である「JIS B 3503」への取り込み状況について解説します。
「OPC UA」とは何か
スマート工場化や産業用IoTなどの流れの中で大きな注目を集めるようになった通信規格が「OPC UA」です。「OPC UA」はなぜ、産業用IoTに最適な通信規格だとされているのでしょうか。本連載では「OPC UA」の最新技術動向についてお伝えする。第1回である今回は、あらためて「OPC UA」の概要と位置付けを紹介する。
OPC UAはなぜ「安全に」通信が行えるのか
スマート工場化や産業用IoTなどの流れの中で大きな注目を集めるようになった通信規格が「OPC UA」です。本連載では「OPC UA」の最新技術動向についてお伝えします。第3回である今回は「つなげる」「安全に」「伝える」の3つのポイントの内、「安全に」を取り上げます。
Copyright © ITmedia, Inc. All Rights Reserved.