リアルタイムの障害検出を実行する場合、通常はトレードオフに遭遇します。つまり、高いレートでサンプリングしても長い不感時間帯に直面するか、非常に低いレートでほぼ連続的なデータをサンプリングするかのどちらかです。明らかに、どちらの方法も理想的ではありません。ただし、テスト装置をより適切に最適化する方法があります。それは、VHDL とカスタマイズ可能なテスト機器を使用して、一時的な障害検出を自分でプログラムすることです。これにより、FPGA 内でリアルタイムに故障を検出できるようになり、すでに使用しているテストおよび検証装置内で故障を検出することもできます。 FPGA コードの作成は、従来の手続き型プログラミングよりも難しいという当然の評判があることを私たちは知っています。ただし、ChatGPT のような新世代の大規模言語モデルを使用すると、言語の詳細を知らなくても簡単に生産性を高めることが可能です。
従来の方法
テスト装置は一時的な障害の検出にはあまり優れていません。通常、監視と検出には 2 つのアプローチがあります。
- 高レートだが断続的
- 低レートだが継続的
オプション １では、オシロスコープを使用します。 オシロスコープのデッドタイムは通常２０% ～ >９９.９% であるため、画面上で一時的な障害が「見える」ことに依存する可能性はほとんどありません。 これを回避する１つの方法は、オシロスコープが障害検出を実行して結果だけを表示できるようにトリガーを設定することです。 この方法にはいくつかの欠点があります。まず、障害はトリガー可能なものでなければなりません。第２に、障害が１回発生したかどうかを確実に知ることができるのは１回だけです。 障害数、障害率、障害状態の合計時間などを判断することはできません。
オプション２では、データロガーまたはデータ収集装置を使用します。この場合、コンピュータがすべての関連信号をリアルタイムで監視し、中間値を計算することができます。システムは故障と関連パラメーターを検出しますが、この方法にも欠点があります。この方法は、適切なプログラミング環境を備えたコンピューターを必要としますが、さらに重要なことは、コンピューターのパワー、計算の複雑さ、データ収集装置とコンピューター間の接続のスループットによって制限される、ある最大レートまでしか信号を監視できないことです。
両方のアプローチの長所を組み合わせて、複雑な過渡故障状態を検出し、低いサンプリングレートに制限されずにそのパラメータをリアルタイムで測定することが望ましいと考えられます。便利なことに、Moku デバイスはインストルメント・オン・チップ・アーキテクチャとユーザーがプログラム可能な FPGA を利用しています。 Moku デバイス上の最大１２個の他の計測器 (図１) とともに、Mokuクラウドコンパイル(MCC) は、カスタム計測器用のプログラミング環境を提供し、独自の FPGA コードを作成して Moku に展開するために必要なすべてのインフラストラクチャを提供します。
図 1: iPad およびデスクトップインターフェイスを備えたMoku製品ラインナップ
例: 過渡電力イベントの検出
例えば、テスターが電力系統の過渡電力事象を監視する必要があるとします。システムは総電力まで定格されていますが、実際には、イベント発生率、イベント発生時間、および故障状態での総時間がしきい値以下である限り、過渡的な過電力に耐えることができます。別の言い方をすると、私たちは次のことができるテスト装置を設計したいと考えています。
- システム内の点を介して電力を監視する。つまり、電圧と電流を監視してから電力を計算する。
- 電力がしきい値を超える場合は、その回数を数える。
- 電力がしきい値を超えた合計時間を記録する。
また、１つの故障の最大継続時間、故障状態の総エネルギーなどを記録することもできますが、ここではこの３つのステップに限定することにします。
これは、オシロスコープで行うような断続的なモニタリングには適していません。オシロスコープへの入力が電圧と電流の場合、オシロスコープが電力レベルでトリガする必要があります。トリガ回路への入力としてリアルタイム計算を使用できるシステムは、ほとんどありません。
システムパラメータによっては、データ収集アプローチにも適さない場合があります。現代の電力システムは高速過渡現象によって損傷を受ける可能性があるため、高いデータ収集レートが求められます。しかし、このような電力システムは通常、長時間の連続使用を想定して設計されているため、システムの動作に信頼性を与えるために必要な監視時間も非常に長くなる可能性があります。これらの要因が相まって、データ量が非常に大きくなり、コストと複雑さが増大します。
カスタム・インストルメント・オン・チップのデプロイは完璧にフィットします。ChatGPTを使ってどのように構築できるか見てみましょう。
ChatGPT によるカスタム障害検出
まず、ChatGPTは非常に具体的な指示を与えられたときに最高のパフォーマンスを発揮します。大きな問題文をより管理しやすい反復に分解します。このように、ChatGPTは非常に人間的です！
次に、図 2 で障害イベントの数をカウントする VHDL エンティティを要求します。
図 2: ChatGPT に VHDL ベースの障害カウンターを要求するプロンプト。
次に、障害状態の合計時間を表すカウンターを追加します (図 3)。
図 3: ChatGPT にカウンターをプログラムに追加するように求めるプロンプト。
最後に、障害状態のしきい値をポートとして VHDL エンティティに追加することで、実行時に構成できるようにします (図 4)。最終的な MCC 実装では、このしきい値は制御レジスタに接続されるため、機器全体を再構築する必要なく設定できます。
図 4: ChatGPT にエンティティの変更を求めるプロンプト。
最終的なVHDLの全リストは、この記事の最後にあります。
入力の電力の計算にはまだ取り組んでいないことに注意してください。これは、電圧と電流の入力を VHDL エンティティに入力する前に単純に乗算することで実現できます。図５は、電力を入力として使用して、MCC でこのエンティティをインスタンス化する方法の例を示しています。
図 5: VHDLによる入力信号の電力計算
これにより、入力ポートの幅が 16 ビットから 32 ビットに増加することにご注意ください。ここでのインスタンス化では、下位 16 ビットを破棄するか (精度の損失が許容できる場合)、エンティティを更新して 32 ビット入力を直接受け取ることができます。いずれにせよ、尋ねるだけです！この記事の最後にあるプロンプトを参照してください。
要約: ChatGPTとMokuクラウドコンパイルを使用したカスタムの一時的な障害検出
これまで私たちは（直接測定できる量ではなく）計算された量のリアルタイム、高レート、デッドタイムのない故障検出を必要とする問題を抱えていました。たった３回のプロンプトで、ChatGPTは、FPGAでの高速データ処理用に特別に設計された言語であるVHDLでこれを実装するために必要なコードをすべて教えてくれました。単純なカット・アンド・ペースト操作と少しのグルー・コードで、Liquid InstrumentsのMokuクラウドコンパイルがカスタム測定器に変わり、Moku IoCにデプロイすることができました。１０分の作業としては悪くないのではないでしょうか！
ChatGPT を MCC で使用する例をさらに詳しく知りたい場合は、こちらのウェビナーをご覧ください: https://liquidinstruments.com/webinar-registration-moku-cloud-compile-and-chatgpt-essential-strategies-for-testing-smarter-with-ai/
MCCで開発したいカスタム機器に関する質問がありますか？support@liquidinstruments.com までご連絡ください。エンジニアが対応いたします。
付録 1: コードリスト
VHDL コード スニペット:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity RisingAboveZero is
Port (
clk: in std_logic;
reset: in std_logic;
in_value: in signed(15 downto 0);
threshold: in unsigned(15 downto 0);
out_value: out signed(15 downto 0);
out_cycle_count: out signed(15 downto 0)
);
end RisingAboveZero;
architecture Behavioral of RisingAboveZero is
signal counter: signed(15 downto 0);
signal cycle_count: signed(21 downto 0); -- Updated to 22 bits
signal previous_value: signed(15 downto 0);
begin
process(clk, reset)
begin
if reset = '1' then
counter <= to_signed(0, 16);
cycle_count <= to_signed(0, 22); -- Updated to 22 bits
previous_value <= to_signed(0, 16); elsif rising_edge(clk) then if in_value > signed(threshold) and previous_value <= signed(threshold) then
counter <= counter + 1; end if; if in_value > signed(threshold) then
cycle_count <= cycle_count + 1;
end if;
previous_value <= in_value;
end if;
end process;
out_value <= counter;
out_cycle_count <= cycle_count(21 downto 6); -- Output the 16 most significant bits
end Behavioral;
付録 2: ポート接続プロンプト
