もちろん、外向きではありません。
ラップトップと同様に、コントローラーにはCore i5プロセッサー、通常のDRAM（通常ECCのみ）、SSDドライブ、通常のイーサネットを搭載できます。 起動プロセスも同じです-BIOSがOSをロードします。 原則として、OS-RTOS。 ただし、Windowsでさえ発生する場合があります。 さらに、Windows Embedded Compact（以前のCE）であるとは限りません。 Windows Embedded 7も使用されていますが、これは完全な7です。 （Linuxも発生します）
生産ラインの運用中に解決される主な計算上の問題は、 CNCとSCADAです。
CADおよびSCADAの場合、x86のパフォーマンスが必要かどうか、およびそれが信頼性の高いプラットフォームであるかどうかの問題は、もはや解決されていません。
CNCはもう少し複雑です。 多くの産業用デバイスを制御するために強力な粉砕機は必要ありませんが、信頼性と保証された応答時間の要件はx86の能力を超える場合があります。 マイクロコントローラーまたは最も単純なPLCで十分です。
通常、GコードはCNCのプログラミングに使用され、x86の計算能力は必要ありません。 マシンがより複雑な場合は、PLCが使用されます。 PLCはどのようにプログラムされますか？ IEC61131-3標準があります。 これは、プログラミング方法を定義します。ILタイプの「アセンブラ」、およびペトリネット、ブロック回路、またはリレーロジックに基づくグラフィック図。
もちろん、リレーロジック、ACM、またはペトリネット上でこのような複雑なプログラムを作成することは非常に難しく、マイクロコントローラーの処理能力では実行できません。 しかし、ここで
このあまり知られていない言語のコードは次のとおりです。
ヴァール
arr1：実際の配列[1..4,1..4]。
arr2：実際の配列[1..4,1..4]。
arr3：実際の配列[1..4,1..4]。
i：INT;
j：INT;
k：INT;
END_VAR
FOR i：= 1から4 DO
jの場合：= 1から4 DO
arr3 [i、j]：= 0.0;
kの場合：= 1から4 DO
arr3 [i、j]：= arr3 [i、j] + arr1 [i、k] * arr2 [k、j];
END_FOR
END_FOR
END_FOR
何にも似ていませんか？ 20年前の学校でのコンピューターサイエンスの授業で、プログラマーがパスカルと構造プログラミングで武装していれば、プロセッサーの速度はあまり速くないことに気付きました。
場合によっては、PLCプロセッサの速度が速いほど優れています。数十個のセンサーの測定結果が、かなり複雑な計算の入力データとして使用され、データの周波数が数十キロヘルツであるアプリケーションがあります。 つまり、数十マイクロ秒の間、それらを取得し、複雑な浮動小数点アルゴリズムを実行し、コマンドを提供する必要があります。 ここでは、最新世代のx86プロセッサのみが内部ギガフロップの束を処理できます。
さらに、HMI（つまり、共通に変換するGUI）がPLCプログラムと同じハードウェアでスピンする場合に便利です。 そうですね、フィールドバス上の通信も同じ鉄片で制御されていたとしても、このようなワークロードの統合を開始して以来、すでにそこにあります！ 幸いなことに、1つのプロセッサに多くのコアがあり、マルチスレッドのリアルタイムアプリケーションを作成することは困難であり、仮想化は適切な分離を提供します（一般的なキャッシュとメモリコントローラーに関連するニュアンスを忘れない場合）
最後の段落では、新しい単語- フィールドバスを使用しました。 生産データ伝送システムの進化は、ITのテクノロジーが専門の恐竜を押し出している好例でもあります。 現代のフィールドバスネットワークProfinet、Ethercat、Sercos IIIはイーサネットに基づいており、Intelおよびおそらく他のベンダーが製造した通常のネットワークカードで動作します。
x86への完全な移行を妨げるものは何ですか？
問題は鉄の認証にあります。 もちろん、世代が毎年変化する複雑なx86プロセッサとチップセットよりも、何年も変わらずに製造された単純なマイクロコントローラの場合、対応する証明書を取得する方が簡単です。 しかし、これは、異なる メーカーの多くの一般的な PLCでIntelプロセッサが使用されることを妨げません。
しかし、リアルタイムはどうでしょうか？ ハードリアルタイムが必要です。ソフトリアルタイムは機能しません。そのため、99.99999％のケースで締め切りになったとしても、残りの0.00001％が1日に数回失敗する可能性があります。 もちろん、この場合にはすべての電源を切る安全機能が必要です。しかし、これを行うことはしばしばなんとなく楽しくありません。 複雑なOOOプロセッサとReal Timeは互換性のない概念であるという意見を何度も耳にしました。 結局のところ、マイクロコントローラーでコードを見て、ビートまで、実行にかかる時間を知ることができます。
だから？ だから、そうではない。 手を見てください！ たとえば、100マイクロ秒のサイクルがあるとします。 中断から始めましょう。 制御は、2の後、または（最悪の場合）8マイクロ秒後に割り込みハンドラーに到達できます。 受信した情報の読み取りにさらに10〜15マイクロ秒費やします。 その後、さらに50〜75マイクロ秒が処理されます（結局、予測不可能なキャッシュを備えたひどく予測不可能なスーパースカラープロセッサがあります！）。 合計支出は62〜98マイクロ秒です。 恐ろしいジッター。 不気味で、ハードリアルタイムx86には適合していません！ しかし、最悪の場合（10キロヘルツの周波数で数時間の操作で1回発生）、最大100マイクロ秒までクリーンアップします。
しかし、コアi3で受信したデータを処理する50マイクロ秒は何ですか？ これは100,000クロックサイクル、または完全に未解決のIPC = 1.2の約120,000命令です。 また、あまり効率的ではないPLCコンパイラも用意します。これは、各IL命令に対して平均で5つのx86命令を生成します。 つまり、サイクルで、24,000のIEC61131-3 IL命令を完了しました。
また、x86 PLCではなく、非常に高速で同じことを想像した場合はどうでしょうか？ データの読み取り中に中断するジッターはありません。24,000IL命令の実行にかかる時間を正確に事前に確認できます。 ビッグスリー（AB、シーメンス、三菱オートメーション）のPLCメーカーのドキュメントを見てみましょう。 1つのIL命令はどのくらい実行されますか？ 9.5ナノ秒。 24,000命令が228マイクロ秒で実行されます。 Rt
サイクルあたり24,000の処理命令が多すぎることに反対する場合は、次のように答えます。
上記はすべて、シングルコアのパフォーマンスに関連しています。 しかし、今ではそれらの多くがあります。 そして、それらを使用して、複数の機能やPLCを1つのデバイスに統合したり、制御プログラムを並列化したりすることができます。 VxWorks、Twincatなどの最新のRTOSバージョン マルチスレッドでサポートされるハードリアルタイムの保証を維持します。 しかし、これはOS、ハイパーバイザー、ライブラリの中核レベルにあります。 そして、アプリケーションレベルでは、核間同期の通常のプリミティブを使用して、リアルタイムを破ることは非常に簡単です。 残念ながら、この問題に対処するための一般的なレシピは私にはわかりません。
上記で、マルチスレッドプログラミングと仮想化の使用が業界で一般的になりつつあることを書きました。 つまり、ITには数年の遅れがあります。 数年後にはプライベートクラウドのようなものを実装し始めるでしょうか？ そして、誰もが聞いたことはあるが誰も見たことがないStuxnetに加えて、産業用ロボットを破壊し、自動化学プラントに適切な物質ではなく興味深い物質を合成させるマルウェアに対処する必要がありますか？