¶1 はじめに

この文書には、SUMO モデリング言語の要素が記載されています。単純ではありませんが、一度習得すれば、整然と文書化された形式で優れたモデルを作成できます。これ以降、このモデリング言語を SumoSlang と呼びます。

¶1.1 SumoSlang とは何か？

SumoSlang は、SUMO プロセスモデリングソフトウェアで使用されるモデリング言語です。プロセスユニットやプロセスモデルを含む非常に大規模なシステムのモデリングを念頭に置いて開発されました。また、エンジニアを念頭に置いても開発されており、Microsoft Excel という馴染みのある環境で方程式を記述できます。

さまざまな Excel ワークシート上での名前付け、テーブルとその内容の構成、および使用されるキーワードが SumoSlang として知られています。この言語の主な特徴は以下の通りです。

• 代入指向,
  • 代入: 方程式の左辺には 1 つの変数のみが許可される,
  • 書式付き方程式: 方程式の両辺に任意の書式（下付き、上付き、ギリシャ文字）を持つ記号が許可される,
• コメントやメモを簡単に追加できる,
• ドキュメントとコードが同じ場所にある,
• 代数計算,
• 動的計算

¶2 構造

SUMO プロセスモデリングソフトウェアには、プロセスコードの標準ライブラリが含まれています。このライブラリの要素は、ライブラリのソースコードを表す、前述の Excel ドキュメント形式のプロセスコードファイルです。プロセスコードには 3 つのタイプがあります。

• 一般設定群—指定ファイル名 systemcode.xlsx
• プロセスモデル—任意のファイル名（例: Sumo1.xlsm）（モデルファイルには通常、検証用のマクロが含まれるため、.xlsm 拡張子となります）
• プロセスユニット—任意のファイル名（例: CSTR with diffused aeration（散気式曝気） and input DO.xlsx）

SumoSlang はまず、いわゆる SUMO Model Translator（SMT）によって処理されます。SMT は SumoSlang を解釈し、さらなる処理のために中間 XML 形式へ変換します。この文書では、SMT の観点から SumoSlang の機能とルールを説明します。SUMO モデリングソフトウェアのグラフィカルユーザーインターフェイスは、プロセスコードに対して他の要件（例: SMT にとって無関係なデータを含むさまざまなワークシート）を課す場合があります。

標準ライブラリのソースコードは、次の図に示す特定のフォルダー構造に配置されています。図では、SUMO のインストールフォルダーが Windows エクスプローラーで開かれています。

Figure 1. - SUMO process code（プロセスコード） structure

SMT は、章の冒頭で指定されたプロセスコードファイル（設定、モデル、プロセスユニット）を、上記のディレクトリで検索します。標準ライブラリは変更しないことが良い慣行とされており、ユーザーコードは、Process Code（プロセスコード） と同じ内部構造を持つ My Process Code フォルダーに置くことが推奨されます。

次のセクションでは、さまざまなプロセスコードファイルの構造、その必須要素、およびプロセスコードの作成者が自由に選択できるものについて説明します。

¶2.1 一般設定群

SUMO の設定は、systemcode.xlsx という特別な名前の Excel ファイルに保存されます。このファイル名は必須です。
Figure 2 は、システムコードの最初のワークシートを示しており、SMT が必要とする他のワークシートが赤で強調表示されています。

• System settings（システム設定群）—システム全体のさまざまな設定と定数
• Functions—SMT によって認識される関数宣言
• Constants—計算に使用される科学定数
• Sumoconv—特別な（ギリシャ）文字を C++ コードへ変換するための辞書
• Species—化学種の辞書

Figure 2. - The systemcode.xlsx file containing systemwide settings. The worksheets highlighted in red are expected by the SMT.

¶2.2 プロセスモデル

モデルファイルには、シミュレーションで使用されるさまざまな科学的方程式、行列、およびパラメータ値が含まれています。プロセスユニットは 1 つ以上のモデルを参照でき、そのため参照されるモデルの変数や方程式がプロセスユニットの計算で利用可能になります。

Figure 3 は、よく使う用されるワークシートを強調表示したモデルファイルの例を示しています。

Figure 3. - Excel file containing model code. The worksheets highlighted in red are usually used in process unit calculations

ワークシート名の一部は必須で、他は任意です。必須の名前は、省略形シンボルが評価される際に SMT によって必要とされます（5.1 Expandable symbols の小節を参照）。
固定名は以下の通りです。

• Parameters—計算に使用される固定数値を持つパラメータのリスト
• Species—pH 計算に使用される平衡化学種の辞書
• Components—動的システムにおける状態変数、または代数システムにおけるモデル成分を含む（例: 調査対象の溶液の化学組成を決定する化学種: Ca2+, Mg2+ など）
• Calculated variables（計算変数群）—他の変数に依存する変数を計算する方程式を含む

その他、任意の名前を持つワークシートは以下の通りです。

• Model—いわゆる Gujer 行列（キネティック行列）を含む。これはプロセスユニットが生物反応速度を計算するために使用する表である。
• pH—pH 計算時に考慮される反応の平衡化学種群を計算するための情報をすべて含む。

モデルには、プロセスユニットコードで参照できる、他のユーザー定義ワークシートを含めることができます。参照方法については、セクション 5.1 Expandable symbols で説明します。

¶2.3 プロセスユニット

プロセスユニットに含まれるプロセスコードは、生物反応槽、流れの要素群、分離装置、その他のモデル化された要素の挙動を記述します。前述のとおり、プロセスユニットは 1 つ以上のモデルファイルから変数や方程式を「引き込み」、それらを計算に使用できます。

プロセスユニットは異なるモデルで動作できる必要があります。これはつまり、モデルを名前で参照することはできず、他のメカニズムを用いる必要があるということです。詳細については、再度セクション 5.1 Expandable symbols を参照してください。

Figure 4. は、よく使用されるワークシートを強調表示したプロセスユニットのコードを示しています。これらのワークシートの名前は必須です。

• Unit—プロセスユニット内で有効な属性（attribute）と成分の処理（handling）の辞書（セクション 5.2.1 Attributes および 5.2.2 Handlings を参照）
• Parameters—SUMO プロセスモデリングソフトウェアでユーザーが変更可能なシミュレーションパラメータを含む。これらはプロセスユニット内でのみ有効だが、モデルパラメータ群を「取り込む」ことができる。
• Code—プロセスユニットのプロセスコードを、いわゆるコードロケーション（code location）にまとめて含む（セクション 3.2.1 Table を参照）

Figure 4. - Process unit file with the commonly used worksheets highlighted in red.

SMT が利用できるその他の任意のワークシートを、プロセスユニットに追加できます。これらのワークシートも必須の名前を持ち、以下の通りです。

• Components—モデルの Components に似ているが、プロセスユニット内でのみ有効。モデル成分を上書きすることがある。
• Functions—systemcode.xlsx の Functions に似ているが、プロセスユニット内でのみ有効。
• Structure—複合プロセスユニットに存在する。成分のリストとそれらの間の接続、および外部との接続を含む。

¶2.3.1 複合プロセスユニット

プロセスユニットは、複数のサブユニットで構成される場合があります。その成分は、それぞれ独自のプロセスコードファイルを持つ別々のプロセスユニットです。それらを 1 つのプロセスユニットにまとめることで内部の複雑さが隠され、そのグループは外部との接続がわずかなブラックボックスのように振る舞います。

前のセクションで紹介した Structure ワークシートは、このグループ化情報を含みます。Figure 5. は、複合ユニットの Structure シートの例を示しています。

成分テーブルの列は、複合ユニットがその成分を制御する方法において不可欠な役割を果たします（セクション 2.4 Process unit hierarchy を参照）。

Figure 5. - Structure worksheet of a composite process unit showing three components, their internal connections and the external connections of the whole composite unit.

¶2.4 プロセスユニット階層

SUMO ソフトウェアでは、モデル化されたプラントはプロセスユニット階層として整理されます。ルート要素は、参加するプロセスユニットを成分として列挙する（人工的な）複合プロセスユニットです。これらのプロセスユニットもまた、単純または複合であり得ます。

前のセクションで述べたように、複合プロセスユニット（親）はその成分（子）を制御します。この制御は、いわゆる属性（attribute）、処理（handling）、パラメータを親から子へ渡すことで表されます（セクション 5.2.1 Attributes および 5.2.2 Handlings を参照）。

人工的なルート要素は、ユーザーがプラント全体のシミュレーションプロパティやパラメータを設定できるように、SUMO ソフトウェアによって提供されます。プロセスユニットの Unit および Parameters ワークシートには、そのプロセスユニットで有効な属性、処理、パラメータが含まれますが、これらの値はルート要素や（プロセスユニットがその一部である場合は）親の複合ユニットによって上書きされることがあります。

上書きの意図は、親プロセスユニットの Structure シートにある成分テーブルの列で宣言できます。Figure 5 では、Unit component テーブルに Label と Models の間に列があります。それらは属性名であり、各行の値が対応するプロセスユニットに渡されます。

同様に、Models 列より後の列は処理名を表し、各行の値が対応する成分に渡されます（この例にはそのような列は含まれていません）。

列のセルが空の場合、その成分ユニットには値が渡されないため、成分ユニット内で定義された値が優先されます。

Figure 6 は、モデル化された 4 つのプロセスユニット（PU₁, PU₂, PU₃, PU₄）の階層を示しています。ここで PU₁ と PU₄ は複合ユニットで、それぞれ 2 つのプロセスユニット PU_1,1, PU_1,2 および PU_4,1, PU_4,2 で構成されています。この例では、階層の左側で属性と処理が親から子へどのように渡されるかを示し、右側ではモデルパラメータ群を親から子へ渡す 2 つの方法を示しています。

Figure 6. - Simple process unit hierarchy. The dashed line between the Root and the Model means that the Root is not the parent of the Model, only uses it.

パラメータの受け渡しには、SumoSlang における特別な名称があります。パラメータ継承（parameter inheritance）です。これはセクション 5.2.1 Attributes で詳しく説明します。ここでは、継承が ON のときパラメータはプロセスユニットの親から来て、そうでなければモデルから来るということを理解すれば十分です。ルートプロセスユニットは常にモデルからパラメータを取得します。

¶2.4.1 プラント全体のコード

グローバル設定やプロパティは、いわゆるプラント全体のコードファイル（plantwide code（プラント全体のコード） file）で指定できます。これは SUMO ソフトウェアがモデル化されたプラントごとに提供するものであり、ソフトウェアに付属するプロセスユニットライブラリの一部ではありません。

プラント全体のコードは、ソフトウェアが人工的なルートプロセスユニットの一部の要素へのアクセスを提供するものと考えることができます。プラント全体のコードファイルは通常のプロセスユニットのように見え、Unit、Parameters、Code の各ワークシートを持ち、これらのワークシートに与えられたデータはルート要素に組み込まれます。ただし、ユーザーはプラント全体のコードを通じてルート要素の Structure シートにアクセスすることはできません。

複合プロセスユニットは、次のように変数の前に子ユニット名を接頭辞として付けることで、直接の子のパラメータやその他の変数群にアクセスできます。

ChildName..variable

プラント全体のコードは、この参照ルールの現時点での例外です。プラント全体の計算で子ユニット（直接の子、または階層の深い位置にある子）の変数が必要な場合、その変数は完全な名前空間の接頭辞で修飾する必要があります（7 Namespaces の章を参照）。

¶3 プロセスコードのレイアウト

Figure 2 は、典型的なプロセスコードを含むワークシートを示しています。プロセスコードの行は整然としたテーブルに配置されており、コードに整理された見た目と印象を与えます。テーブルは少なくとも 1 つの空白行によって区切られます。テーブルの見栄えの良い書式や色付けは、SMT がテーブルをどう認識するかには影響しないことに注意してください。たとえば、ユーザーがセル B8 にテキストを挿入した場合、SMT はそれを最初のテーブルに含めます。テーブルにはプロセスコードが含まれ、テーブルの外にあるものはすべてコメントと見なされ、無視されます。

¶3.1 テーブル構造

すべてのテーブルには次のものが必要です。

• descriptor—上記の例では B3:D3 の 3 セグメントからなるセル範囲
  • table type—セル B3。空でもよく、あるいは次のキーワードのいずれかを含むことができる
    • Array
    • if block
    • C++ code
    • Newton-Raphson—モデルコードの Calculated variables（計算変数群） ワークシートで使用
    • Port, Attribute, Model, Handling—プロセスユニットの Unit ワークシートで使用
    • SolverConfiguration—Equilibrium コードロケーションと組み合わせて Newton-Raphson テーブルタイプを置き換えることを意図している（9 Advanced topics を参照）
  • table name—セル C3。テーブル内容の意味のあるグループ化名を含む
  • table tag—セル D3。table type と同様に、空でもよく、あるいは次のキーワードのいずれかを含むことができる
    • Pure—システム設定群の Functions ワークシートでのみ使用
    • Type(arg)—モデルコード（Parameters, pH, Calculated variables（計算変数群））でテーブルをさらにグループ化するために使用
    • Codelocation(arg)—プロセスユニットの Code ワークシートで使用。引数は次のキーワードのうち 1 つ以上を取り得る: ZeroTime, DataComm, Integrated, Equilibrium
    • Scope(arg)—プロセスユニットの Unit ワークシートで使用
  • header—例では B4:J4 の範囲。列数は任意。列ヘッダー名の一部は固定（例: Symbol, Name, Value, Rule）で、他は任意。
  • body—テーブルにまとめられたコード行（body は空でもよい）。例の最初のテーブルではその範囲は B5:J7。

¶3.1.1 単純なテーブル

通常、テーブルの範囲は、次の図に示すように Symbol 列の内容とヘッダー行によって決まります。

Figure 7. - Table boundaries.

前のセクションで説明した descriptor、header、body などの主要要素は、Symbol セルを基準として相対的に決定されます。テーブルは、Symbol 行および Symbol 列に空でないセルがある限り、右方向および下方向へ拡張します。

一部のテーブルタイプはこの構造に従いませんが、それでも別の構造には準拠する必要があります。そのようなテーブルタイプは Array、if block、C++ code です。

コードテーブルの行は、a = b の形式、より正確には a ← b（b が a に入る）の形式で代入を表します。代入の左辺はテーブルの Symbol 列にあり、右辺は Value、Default、Expression のいずれかの列にあります。場合によっては、Expression 列が複数の部分に分割されることがあります（3.1.2 Array を参照）。

¶3.1.2 配列

配列はあらゆるプログラミング言語において基本的な要素です。SumoSlang では、3 つの方法で指定できます。1 つ目は、配列表記（例: var[]）でシンボルを記した行を含む単純なテーブルです。SumoSlang は、配列行の Rule 列に、[n] のようないわゆる配列ルールを必要とします。ここで n は配列のサイズであり、プロセスユニットファイルの Parameters シートで宣言されます。これらの例は Layered SBR with calculated DO.xlsx から引用されています。

Figure 8 は、配列サイズ定義の例を示しています。Parameters ワークシートでは、代入の右辺は Default 列または Value 列に含まれます。

Figure 8. - Dimension type variable definition in row 103.

配列サイズ定義には、それが配列の次元タイプ変数であることを指定する Dimension ルールが必要です。なお、SumoSlang は現時点では 1 次元の実数配列のみを扱うことに触れておきます。

Figure 9 は、さまざまなコードテーブルにおける単純な配列の例を示しています。

Figure 9 Array rows in two tables: rows 5, 17 contain arrays with their symbol ending in brackets and with [n] in their Rule column.

SMT は、配列行をループに展開し、そこで配列の各要素が Expression 列に含まれる右辺に代入されます。この例では n が 9 と定義されているため、ルール [n] を持つすべての配列は 9 個の要素を持ちます。たとえば、行 5 は次のように展開されます。

SV[1] = SV_0[1]
SV[2] = SV_0[2]
...
SV[9] = SV_0[9]

より正確には、これと同等のループに展開されます。式もまた配列表記、すなわちブラケットで終わることに注意してください。

配列を定義する 2 つ目のオプションは、テーブル記述子でテーブルタイプを Array に設定することです。SMT は、Expression 列が複数の部分に分割され得ることを想定しています。Figure 10 は、この配列タイプの例を示しています。