なぜプロセス制御はアルゴリズム以上に構築と運用が難しいのか

process controlの差はalgorithmだけでは決まりません。量産では、工程ごとのlogicを構築し、適用前に検証し、変化やexceptionに対応しながら運用し、その方法を次のproduct・tool・processでも再利用できることが重要です。

control equationやmodelは短くても、production systemではdata、trigger、validity、safety bound、missing data、rollbackまで扱う必要があります。

3つの方式はengineering burdenを置く場所が違います

legacy rule-based制御、custom code制御、Amfibianを、構築のしやすさ、customization、量産運用、拡張・再利用、事前検証で比較します。

fabの既存platform上で動くlegacy rule-based制御、engineerが直接分析・実装するcustom code制御、Amfibianの構築・運用特性を概念的に比較した図です。

Legacy rule-based制御：量産運用は強い一方、表現できるlogicに限界があります

多くのfabではAPCやR2R platformがすでに稼働しており、engineerはその中で四則演算、条件式、limit、ruleを組み合わせて次のrecipeを計算します。data接続やexecution timing、権限、運用手順が整っていることは大きな強みです。

一方、非線形な多変量関係、Virtual Metrology、anomaly gating、複数modelの組み合わせなどはrule中心のplatformでは表現しにくくなります。弱点は量産運用ではなく、複雑なlogicを作るflexibilityとdevelopment speedです。

Custom code制御：legacyの制約を超えられますが、systemまで人が作る必要があります

process engineerやdata scientistがdataを分析し、PythonやRなどでmodel、calculation logic、exception handlingを直接実装します。自由度は高い一方、data integration、trigger、safety、validation、monitoring、update、rollbackもteamが持つ必要があります。

Amfibian：柔軟なcontrol logicと量産operation workflowを
共通化します

Studioでmodelとcontrol logicを構成し、Digital Twinで事前検証し、Runtimeでproduction dataへ接続して運用します。特定algorithmの優劣ではなく、build・validation・deployment・operation・change managementを共通化することが中心です。

量産で難しい仕事はcontrol valueを計算した後から始まります

version、valid condition、missing input、safe bound、drift、rollbackを継続的に扱う必要があります。

legacy platformはoperationに強い一方で複雑なlogicの表現に制約があります。custom codeはその制約を減らしますが、buildとoperationの負担が人に戻ります。Amfibianは新しいmodelやcodeのflexibilityをproduction-gradeのvalidation・operation structureへ接続することを目指します。