HOME > アズビルについて > 会社PR > 会社紹介資料 > azbil Technical Review > 2018 > IoT時代の熱源コントロール・ソリューションの紹介

IoT時代の熱源コントロール・ソリューションの紹介

1．はじめに

原発事故は，我が国のエネルギー政策の大きな転機となり，一時的に化石燃料に依存せざるを得ない状況にある。こうした状況は，エネルギーコストの上昇と温室効果ガスを増大させる原因となり省エネルギーの対応が急務となっている。ボイラや冷温水装置に代表される熱源機器は燃料消費を少なくするために，より効率化が求められ制御は高精度・高速化に向かっている。一方，熱源機器の多くは燃焼を伴うため爆発・火災のリスクに対する安全性の確保が必要である。これまで制御性と安全性はトレードオフの関係にあると考えられ，これらを両立させることは課題となっていた。アズビルでは従来のハードウェアによる安全設計に代わりソフトウェアによる燃焼安全技術を開発した。これはソフトウェアの特性を活かし精度が高く，ユーザーの課題に柔軟に対応することができる。今回，最新の燃焼安全技術を用いた制御性と安全性を高いレベルで両立し，今後の熱源機器のIoT化に対応できるコントローラを開発したので紹介する。

2．アズビルのソリューション

アズビルが販売する燃焼安全機器は，カタログに掲載される標準品と，熱源機器メーカーの要求仕様に応じた相手先ブランド製品（以後，カスタム品と呼ぶ）に分類できる。

バーナコントローラ（形番：BC-R15/25/35）に代表される標準品は，燃焼安全に最小限必要な機能に絞り込むことで汎用性を高め，多種多様なアプリケーションに対応できる。安全機能を集約することで安全系と制御系の分離が容易となり，より確実な安全計装を行うことができる。しかし，別途，調節計やPLC（プログラマブル・ロジック・コントローラ）などの制御機器が必要となるため，コストや省スペースにおいて不利な面がある。また近年，グローバルに展開するため各国の安全規格を取得する必要がある。これらは機能安全規格をベースとしたマイコンおよびソフトウェアを主体とした規格となっており，多くの安全手法を取り入れる必要がある。設計，検証項目は多岐にわたり，最終的に第三者機関による認証を受ける。よって開発のリードタイムは長期化する傾向にある。

一方，アズビルが開発委託を受けるカスタム品の多くは，システム全体を統括する一体型コントローラであり，温度・圧力制御，水位制御，表示操作部，ユーティリティ制御，通信，燃焼制御が含まれる。装置固有の危険源があり，個別にリスクアセスメントを実施し必要な対策を行うことが重要となる。アズビルの安全・安心設計に対するお客さまの期待に応えるために，バーナコントローラ（形番：BC-R15/25/35）などの標準品で培った安全技術のレベルを下げることなく，サイズ，コスト，納期面で制約のあるカスタム品へいかに適用することができるかが課題であった。

これらカスタム品特有の厳しい制約や要求に対して，受託開発に豊富な実績を持つアズビル太信が開発を担当することで開発リードタイムの短縮とサイズ／コストの最適化が可能となった。

電子部品が搭載されるプリント基板は，リードタイプ部品の自動実装，表面実装タイプ部品の自動実装，リレーやコネクタなどの機構部品の人の手による実装，防湿や絶縁のためのコーティング処理など，様々な工程を経て完成する。アズビル太信のものづくりは，組織間の距離が近く，開発と製造部門で密に連携できることで製品の試作段階から，工程の最適化を意識した設計となっている。これにより，試作回数，設計の手戻りが少なくなることで開発期間が短縮でき，また，効率的な生産によりコストの低減が可能となった。

カスタム品における安全確保の方法については，次章以降で紹介する。

3．最新のコントローラ設計

図1に，最新コントローラのアーキテクチャ例を示す。安全システムの基本として安全系と制御系を分離する必要があり，今回，燃焼安全系，システム安全系，制御系の3つの系で構成した。

燃焼安全系は，燃焼安全規格の第三者認証を取得したバーナコントローラ（形番：BC-R15/25/35）と同様のハードウェアおよびソフトウェアで構成している。システム安全系は，重要な機能を，ソフトウェアを介在せずに独立したハードウェアで構成することで安全を確保している。

制御系は，安全関連部と完全に切り離されることで安全設計・検証を不要とし，安全設計を意識せずに制御機能を作り込むことができる。

3.1　燃焼安全系

燃焼安全系の目的は爆発を防ぐことであり，炉内に未燃燃料が蓄積されている状態で点火させないこと，運転中に何らかの原因でバーナが断火した場合は，即座に燃料供給を遮断することが必要となる。

燃焼安全系の構成は，実績のあるアズビルのバーナコントローラ（形番:BC-R15/25/35）のアーキテクチャ（図2）を採用した。安全アーキテクチャは，1oo2D（1 out of 2 channel with Diagnostics）とし，ロジック（CPU）と出力部は2重化されている。

診断機能として出力のモニタリング，ロジック（CPU）間の相互確認が行われる。安全関連の内部信号をパルス化（ダイナミック信号）することで診断系も含めて部品の危険側故障を検出可能とした。ロジック（CPU）部は，次に示す燃焼安全の根幹となる燃焼シーケンスの実行を行う。

（1） 起動時に安全関連部が正しく動作しているか確認を行う（スタートチェック）。

（2） 点火前には決められた時間のパージを行い確実に未燃ガスを排出する（プレパージ）。

（3） 決められた時間内に点火できない場合は，確実に燃料遮断を行う（点火トライアル）。

（4） 運転中に火炎が消失したら，即座に燃料遮断を行う（フレームレスポンス）。

これらが常に正しい順序とタイミングで行われることが，ロジック（CPU）に求められる。万一の事故においては人命を損なう危険性があるため関連する安全規格（IEC60730-2-5）では，ソフトウェアクラスCという一番厳しい安全レベルを満たすことが求められる。ここでは2つの側面がある。側面の1つは，ロジック（CPU）部の故障に対する対応としてハードウェアの構成要素の全てについて可能な限り診断しなければならない。以下に診断の内容について示す。

• 演算/制御結果について自己および相互チェック
• 安全パラメータの自己および相互チェック
• プログラム実行順のチェック
• 内蔵RAM，レジスタの固着チェック
• CRCコードによるFlashROM，EEPROMのチェック
• 割込み処理層のデッドロックチェック
• スタックレジスタのチェック
• 命令コードの動作チェック
• タイマ割込み処理の周期チェック
• CPU間通信のフォールト抑制

もう1つの側面としてソフトウェアのリスクに対処する必要がある。ソフトウェアのリスクは偶発的な故障というものはなく，安全仕様の不備やバグなどの設計ミスによるものであり， 条件がそろえば100%顕在化するものである。複雑に絡み合うソフトウェアの中で作り込まれる人為的なミスを回避するために， 関連規格で定義された開発プロセスや設計技法を適用することが求められている。開発品においては，バーナコントローラ（形番：BC-R15/25/35）で欧州の第三者認証機関に監査を受けたソフトウェアのアーキテクチャ，自己診断処理を，そのまま使用することで安全レベルを維持した。このソフトウェアは，あらかじめ作り込まれている安全機能について任意のパラメータを選択することで設備に要求されるシーケンスやタイミングを実現することが可能となっている。

例えば，プレパージ時間は任意に設定可能となっておりブロアや燃焼室容積に合わせて最適化することを可能とする。安全に関連するパラメータ変更は，プログラムコードの変更を伴わないため検証が不要となり，ソフトウェアの変更リスクや開発工数を低減できる。

燃焼を遮断する安全遮断弁を駆動するリレーの接点溶着故障は最も危険な故障の1つである。そのため，燃焼シーケンスを開始する前にリレー接点の開閉をチェックし，正常に開閉ができることを確認してから動作を開始する。図3のように，安全遮断弁のリレー接点は両切り接点構成とし，3つのリレー接点が直列に入る。また全てのリレー接点は，正しく動作しているか常にモニタリングされていることから極めて安全度は高い。



図3　リレー接点構成

3.2　システム安全系

システム安全系は装置固有のリスクに対応する。缶体の過昇温や，モータ焼損などの火災リスクに対して温度ヒューズを，直接，電源と駆動リレーの間に挿入し，温度ヒューズ作動により供給電源が遮断される構成とした。ソフトウェアが介在しないため安全性が高い設計となる（図1の感震器，温度ヒューズ，サーマルリレーに該当する）。

ボイラ内の水位が低下しているときに燃焼を継続すると空焚きとなり破裂・圧かいや火災のリスクとなるため低水位検出は重要な機能となる。回路故障により水位検出の誤検出とならないように検出信号をパルス化し，故障時は運転停止となるように考慮されている（図1の低水位インターロック回路に該当する）。

3.3　制御系

燃焼安全系の2重化されたCPUとは別に，専用に制御系を担当するCPU（制御用CPUと呼ぶ）を用意し，全体として3つのCPUで構成される。制御系CPUは，表示操作，温度制御，ユーティリティ制御，通信など装置機能を担当する。安全系と分離されているので，制御用CPUのソフトウェア設計は，安全のための設計，検証作業は不要となる。メリットとして制御性をより向上させるために装置を熟知した熱源機器メーカーの技術者がソフトウェアを設計し， アルゴリズム開発を行うことが可能となる。またお客さまから要求される個別要求にも短いリードタイムで対応することが可能となる。アズビルの基幹技術である高度な制御技術や通信技術を組込むことも可能である。

4．アズビル独自の安全設計

4.1　共通原因故障の対応

燃焼安全系は2重化設計としていることで危険側故障率が大幅に低減できていると過大評価される場合がある。 実際のところ2重化しても故障率はそれほど小さくならない。例えば各チャンネルの故障率が10^-6（/hr）の時，故障率が全体として10^-12（/hr）のように2乗で小さくはならない。

機能安全規格IEC 61508では，いかに多重化しても共通原因故障割合βが存在し0.1～0.01程度の改善しか望めないとしている。先の例では，10^-7～10^-8 （/hr）程度の改善となる。通常，燃焼安全機器としては，10^-7（1/hr）未満（数千年に1度程度）の故障率が求められる。共通原因故障とは，ソフトウェアのバグ，マニュアルの間違いなど条件がそろえば2重化された双方で同時に起こる可能性が高い事象が対象となる。関連規格における共通原因故障対策のための設計技法の一部を示す。

（1） 設計時に共通原因故障を考慮し，評価結果がフィードバックされているか。

（2） 異なる設計者が設計したか。

（3） 使用する設計上の技術は5年以上実際に首尾よく稼働したか。

アズビルでは，これら設計技法を開発プロセスに取込み開発を行っている。次に，共通原因故障対策の実施例を紹介する。

4.2　電源故障対策

2重化されていない電源の異常は共通原因故障となる。 CPUなどの半導体部品は許容範囲を超えた電圧の印加に対して動作保証されず，CPUが暴走し制御不能となる危険性がある。本来，電源についても2重化が望ましいが，製品の小型化やコスト面で不利となるため，1つの電源に対して，過電圧検出と電源遮断機能を2重化することで対策としている。

4.3　EMC対策

2重化されていない入力端子がノイズの影響を受け，入力値を誤認識したり，ノイズの影響で2重化されたCPUが同時に誤動作することも共通原因故障といえる。関連規格のノイズ基準を超える独自の試験方法によりマイコンの誤動作レベルと動作モードを確認し，安全確保を行っている。これは燃焼安全機器の長年の販売実績がある当社のノイズ対策ノウハウとなっており，強力なノイズ源となる点火装置や，インバータが発生するノイズを模した機器により試験を行っている。

4.4　CPUクロック故障対策

安全上重要なシーケンスタイミングのカウントはCPUのクロック周期に依存している。2重化されたCPUのクロック源として，それぞれセラミック発振子が実装されているが，発振子は動作原理と製造プロセスが同一のため，温度特性や経年変化が同じ傾向となる場合が多い。したがって同じような割合でクロック周期が変動した場合は，CPU間で相互比較しても異常検出できない危険性がある。そこで商用電源周期のチェックを追加し，シーケンスタイミングの正しさを保証している。

5. 熱源機器のIoTへの方向性

IoTとは，インターネットを通じてあらゆるモノやサービスが連携する仕組みであり，あらゆる分野で，このIoTを活用して新しい価値やビジネスモデルの創出を目指す動きがある。熱源機器の市場においてもメンテナンス効率化や省エネルギーなど，IoTにより多くの恩恵が受けられると考える。IoT活用の一歩としてアズビルでは機器の内部データを有効に利用し，機器の一層の見える化を進め課題の解決と企業の利益に貢献したいと考える。

5.1　メンテナンスの効率化

少子高齢化，人口減少へ向かう中で熟練技術者が少なくなり人手不足の問題と，スキル不足により定期点検の不備や操作ミスによる事故の増加などが懸念される。従来の定期点検主体の予防保全から，機器診断により故障を事前に察知して修理を行う予知保全に移行することでメンテナンス業務を効率化することができ，お客さまにおいてはダウンタイムがより少なくなるメリットがある。効率的な予知保全を実現するための機器の対応としてはアクチュエータが動作してからセンサが応答するまでの遅れ時間を計測し記録し，その結果を見える化する。

これによりアクチュエータの異常，断熱材の劣化など，各部位の状態変化が進んでいることを捉えることができる。計測項目の例を次に示す。

（1） センサ（風圧スイッチ，インターロック）の動作遅れの計測

（2） 着火遅れ時間の計測

（3） 火炎レベルトレンドの計測

（4） 昇温時間の計測

（5） エラーに至らない疑似火炎，残火の頻度の記

（6） リトライの発生状況の記録

燃焼機器のトラブルとして多い着火ミスを具体例として示す。着火を阻害する要素として送風経路の詰まりや，点火ロッドの絶縁劣化，ガス圧の変動，火炎センサの汚れなどがある。多くの場合，これらの劣化は時間経過とともに徐々に進行していくので，正常データを記録し，そのデータとの比較を行うことで，劣化の検出を行うことができる。図4のように点火ごとに現在値と比較し，着火遅れの状況を把握することで機器の劣化を知り，着火ミスに至る前に対処することができる。

また季節などの外的要因で着火性が変わる場合は，季節ごとの初期データを取得し，そのデータと比較することで，劣化判定の精度を向上させることもできる。それぞれの計測データにおいて，時間，日，週，月のそれぞれの時間軸におけるトレンドを見ることで，外的要因の影響などをあらかじめ把握することもできる。



図4　着火遅れ状況の可視化

5.2　現場トラブルの対応

トラブルが発生すると状況把握，修理・調整，確認など数回の訪問サポートが必要になる。機器はブラックボックス化が進み故障要因の特定が難しくなる状況にある。そこで機器の対応としては，次に示す異常発生時の詳細な状況を記録することで原因究明をサポートする。

（1） エラー発生前後の状態のトレンドグラフ

（2） エラー発生履歴

図5に遠隔監視ソリューションのイメージを示す。高解像度のモニタやタブレットを活用し，遠隔地より状況を確認することで現場訪問前に機器状態が把握できる（図6）。この例では，燃焼ガス流量が低下することで空燃比が乱れ，断火に至ったと推定することができる。このように1次対応の段階で原因推定により対策を絞り込み，交換部品やツールを事前に用意することができるため，早期に復旧を行うことができる。



図5　遠隔監視ソリューション



図6　エラー発生前後の状態のトレンドグラフ

熱源機器の省エネ性能は飛躍的に向上した。しかし，機器の省エネ性能を100%発揮させるためには，日々のメンテナンスが重要である。省エネルギー法では，効率，空気比，排ガス温度などの管理指標を設定し計測および記録し，エネルギーの効率的利用を維持することを求めている。将来的には，ネットワークを介して，すべての熱源機器，センサをクラウドと接続し，管理指標の見える化を実現し，さらにディープラーニングを活用した運転状態の最適化を行うことで装置の省エネルギーに貢献していきたいと考える。図7に，azbilグループの熱源コントローラに対するIoT化のアプローチを示す。



図7　熱源コントローラのIoT化アプローチ

6．おわりに

アズビル太信の将来的なコア技術を目指して，2013年秋よりこの燃焼安全機器の開発準備を進めてきた。単なる生産拠点の位置付けではなく，開発を主体的に行い，さらに生産に対する管理，品質保証をも責任をもって行うためには，最新の燃焼安全技術の吸収や最新の開発プロセスの習得，様々な管理体勢の整備が急務であった。そのために技術者のアズビルへの出向と若手技術者の増員など人材計画を実施し，継続的に開発が可能となる体制を作ってきた。

生産体制としても最新鋭の表面実装ラインへの切替え， X線検査装置，コーティング剤自動塗布機などの新規導入など，汎用生産設備の高効率化も並行して検討・実施し効率化と品質面で高いレベルでの体制を構築することができた。生産設備のうち，電気試験設備等は，検査仕様に基づき社内で製作することによって，正確で迅速な生産立ち上げを可能とし，開発効率を上げることができた。

今後も，「人を中心としたオートメーション」の理念に基づき，最新の燃焼安全技術を核として，さらにIoT活用を促進させて，お客さまを含め人々の「安心，快適，達成感」の実現のために，生産活動を追求し続けていきたいと考えている。

＜参考文献＞

（1） IEC61508-3:2010 Functional safety of electrical/electronic/programmable electronic safety-related system – Part 3

（2） 2重化システムのMTBF 共通要因故障の有無の影響
http://controlsystemlab.com/index.php/fs-mtbf-duplex/制御システム研究所　

＜著者所属＞
小林　広伸　アズビル太信株式会社 開発部
山田　晃　アズビル株式会社 アドバンスオートメーションカンパニー CP開発部　

この記事は、技術報告書「azbil Technical Review」の2018年04月に掲載されたものです。

前のページへ
ディマンドリスポンスシステムの開発とバーチャルパワープラント構築実証事業への適用
azbil Technical Review 一覧（2018年4月）
次のページへ