直交状態（Orthogonal States）は、複数の独立したサブ状態が並行して動作することを指します。本事例では、「洗浄状態」と「フラッシュ状態」が並行して管理される典型的な直交状態の例となっています。
　一般的な、実装方法としては、
　　・　リアルタイム性が求められる場合 → 割込み
　　・　単純な処理で十分な場合 → ポーリング
　　・　複数の処理を並行で管理する場合 → 時分割（OSタスクスケジューリング）
が、挙げられます。
　この温水洗浄便座の事例では、「洗浄」「フラッシュ」それぞれが独立した動作をするため、割込み+ポーリングの組み合わせ が有効と思われます。特に、ボタン押下は割込みで処理し、定期的な動作はポーリングまたは時分割で管理するのが適切です。

　MATLAB & Simulink の Stateflow では、直交状態（Orthogonal States）を扱う際に、内部では イベント駆動型のスケジューリング に基づいた状態遷移の管理が行われているようです。具体的には、「スケジューリング（イベント駆動モデル）」、「ポーリング」、「割込み」の3つの処理方式が組み合わされていると考えられます。
　実際の動作の流れとして、
　　１．Simulink の時間ステップ が進むたびに、Stateflow のエンジンが現在の状態を評価。
　　２．ポーリング処理 で状態の変化を確認し、遷移条件が満たされれば次の状態へ。
　　３．直交状態（並列サブ状態） がある場合、それぞれのブロックが独立して評価される。
　　４．割込み処理（外部イベント） が発生すると、優先的に処理される（特定のリアルタイムターゲットの場合）。
となっていると、思われます。

ご推察のように、表現するのに適した状態遷移図/表が例によって異なると思います。
そのため、どちらも使いますが、「好み」でもあります。

一方、表現したいことも複雑化・高度化するので、ハレル・チャートなどより発展した表記法も使われます。
しかし、これらも状態の考え方はミーリ・チャート、ムーア・チャートが基本となるため、講義ではこれら２つの考え方の説明を行っています。

Stateflowでは、ハレル・チャートが基本とし、ミーリ・チャート、ムーア・チャートのみで記述することもできます。
講義・演習では、特に気にせず使用しています。

C言語などでも最近は暗黙キャストを嫌う傾向にあり、特にハードウエアを扱う組込みシステムでは大事な問題です。
全部の変数を明示的に扱うと数値の精度に起因する不具合は防げますが、開発の簡易性は失われます。
トレードオフなので、私は必要に応じて明示するのが良いと考えています。

今回は、説明を簡単化するために変数の型は明示していません。
数値の精度を意識しないで済むアルゴリズムでの例題としたためです。
Example-3でご指摘の信号の追加の場合、エクスプローラ（モデルエクスプローラ）で変数を確認すると、下図のようになっています。
例えば、In は、チャートに繋がるSimulink側の信号の型に自動的に合わされています。
これは、プルダウンメニューで明示的に変更することもできます。

型を意識しなければ開発が簡易になることもありますが、どこで数値の精度を保証するかも大事となります。

特にハードウエアが係るところでは、変数の型が大事とります。
そのため、Simulinkでも下のような型変換（キャスト）を行うブロックも用意されています。

さらに、どこで数値の精度を保証するかも大事となります。
例えば、Simulink Support Package for Arduino Hardware にある PWM の
ブロックでは、下図のようにブロック内で、ハードウエアにデータを渡す直前で
uint8（符号なし8ビット整数）にキャストを行っていますが、普段は隠蔽されています。

結局、簡易性と厳密性のバランスかと思っています。
一つの方法として、特に意識が必要な個所を除き、型を意識せずに開発を行い
MILS/HILSでの動作検証で不具合を検証する方法もあります。

①への回答
SST→状態遷移図の自動変換はできないようです。

②への回答
お気づきのように、状態遷移図に比べて状態遷移表,状態遷移マトリクスは漏れが起きにくくなることが期待できます。
一方で直感的な理解は状態遷移図の方が優れているので、状態遷移表,状態遷移マトリクスは詳細設計時、状態遷移図は概略設計・確認・説明用と使い分けも考えられます。
使い分けるときの注意点は、相互に間違い・漏れがないことです。
①と関連しますが、自動変換は人が変換するのに比べて間違い・漏れは少ないことが期待できるので、上手に使うと良いと思います。

はい。私どもと同じ認識です。

今回は、イベントを用いた同期をテーマとしたので、このようなつくりとなりました。
是非、色々な設計を試してください。

明確なドキュメントは見つけれていないのですが、遷移に関連する条件やイベントのような位置づけと考えています。
アクション関数は状態に関連するものなので、別と考えています。

必須ではありません。
ご指摘のように、サブチャート化することで全体が見えなくなることもあります。
特に、チャート内の状態が少ないとき、あるいは、サブチャート内の状態から別のサブチャート内の状態に遷移するような場合は、サブチャートを用いない方が良いと思います。

一方で、一目で理解できる要素数は7個くらいまでともいわれます。
そのため、説明したい内容に応じて適度な粒度でサブチャート化することは有効と考えています。
参考：https://monoist.itmedia.co.jp/mn/articles/1602/01/news007_2.html

さらに、「文化」も大事です。
開発メンバーが同じ認識を持っていることが大事なので、無理にサブチャート化を進めるものてもありません。

私の方でJMAABで推奨されない理由が理解できていないのですが、おそらく、安易にサブチャートを用いると、そのサブチャートの間違った理解によってシステムに不具合が生じるのを防ぎたいのだと思います。

ご参考になれば幸いです。

ご指摘のとおりね変数が実数だと、量子化誤差で不具合が生じる可能性があります。

可能であれば、整数値のみで使用するのが良いと考えています。

状態遷移をテーマにした参考書は、あまり無いようです。
次が参考になるかと思います。

参考書（図1）
組込みエンジニアのための状態遷移設計手法
－ 現場で使える状態遷移図・状態遷移表の記述テクニック－
久保 孝行 (著)
出版社 ‏ : ‎ TechShare (2012/11/30)
ISBN978-4-906864-03-4
https://techshare.co.jp/company/business/other/techshare-education/publishing/

すでに参考にされているかもしれませんが、MathworksのHPに次があります。（図2）
https://jp.mathworks.com/help/stateflow/getting-started.html

ソフトウエアやシステムズエンジニアリングにおいても、状態遷移図が用いられます。
例えば、UML や SysML があります。
UMLは主にソフトウエア、SysMLは主にシステムズエンジ人リングで用いれています。
例えば、UML2では、次のように定義されます。
https://www.omg.org/spec/UML/2.5.1/PDF　　P.305：14 StateMachines 

実装については、次の記事が参考になるかと思います。
Monoist :状態遷移表からの実装：状態遷移表による設計手法（5）
https://monoist.itmedia.co.jp/mn/articles/1211/07/news003.html

HILSに限らず、システムが大きくなると検証項目が膨大になる傾向があります。

適切なテスト項目の選び方は、V字プロセスの右バンクをいかに作るかということでしょう。
単純にすべての組み合わせを考えると膨大になります。上位の要求（右バンク上の方）を満たすために下位（V字の付け根側）の要求（何ができればよいか）を検討し、重要度の高いものやリスクが高いものを優先に検討することが考えられます。

以下、直接の回答ではありませんが。ご参考まで。

結合テストにおける複雑さ問題は、ソフトウエア開発では以前より問題にされており多くの知見があります。
「ソフトウエアテスト」、「結合テスト」などで調べてみると良いと思います。


状態遷移に対するテストについて次の記事があります。
　Qiita : UMLステートマシン図を用いた状態遷移テストの注意点
　https://qiita.com/ToshiManaPlus1/items/be8b698772ea3a42058b

左下の矢印は、そのブロックはマスク化されていることを示しています。

モデルベース開発では、開発したモデルを再利用することで開発期間を短縮します。
Simulinkで作成したモデルの再利用を行うとき、サブモデルの構造を隠蔽して不用意に変更できなくし、
パラメータのみを変更できるようにする「マスク化」を行うことがあります。
この処理は本講義の枠から離れるので、説明なしで使いました。
（別講義、「MBD_プロセス研修プロセス研修」で学べます。）

マスク化されているブロックの中は、右下図のようにマウス操作で見ることができます。

さらにマスク化したブロックは、ライブラリ化することでさらに再利用しやすくなります。
Simulinkライブラリブラウザーでライブラリ化されている様子がわかります。

詳しくは、MATLAB ヘルプ センターも
参考にしてみてください。

https://jp.mathworks.com/help/simulink/ug/block-masks.html　

次を試してみてください。

その１：
【HILS動作確認（DCモータ制御システム）】 内の「 HILシミュレータ動作確認手順書（DCモータ）_R2019a以前.pdf」のうち、
P.8 からの「 エラー対応について 」を試してみてください。

その２：
PCに登録されている COM ポートが多くなりすぎている可能性があります。
次の手順で削除してください。
①Arduino をUSBポートから抜く
②スタートでマウスの右ボタンから、デバイスマネージャを開く
③デバイスマネージャで、「表示」 > 「非表示のデバイスの表示」にチェックを入れる
④「 ポート（COMとLPT） 」にたくさんのArduino があると思います。
　アイコンが鼠色の Arduino DUE と Arduino Mega 2560 の COMポート（右図の赤色の部分）を、
　ひとつずつすべてについて、ポートを選択してマウスの右ボタンから「デバイスのアンインストール」を選択し、
　アンインストールする

＜方法①＞マウスとキーボード操作で出陸信号を設定できます。
正規の説明ではないですが、次がご参考になります。
備考：SignalEditor ブロックは、SIgnalBuilderブロックの後継です。

YouTube　：　Signal builder block in matlab simulink　：
https://youtu.be/5Y2eoJNDIgc?feature=shared

YouTube　：　Signal Editor Usage in MATLAB 2023 | Signal Builder use in MATLAB Simulink | PV irradiation curve  ：
https://youtu.be/eUU1qU3jKt0?feature=shared

MATLAB ヘルプ センター　：　SignalEditorについて　：　
https://jp.mathworks.com/help/simulink/slref/signaleditorblock.html

＜方法②＞Etudes の「応用演習A」または「応用演習B」のページより、設定済みのSignalBuilderブロックをお使いください。

これらのブロックはテキスト P.112 の方法で作成して保存しています。

手順 ①　：　出力信号を設定済みのSignalBuilderブロックが含まれるファイル（ SignalBuilderForExamAB.slx ）をダウンロード

手順 ③　：　ダウンロードした SignalBuilderForExamAB.slx を開く

次のArduinoを使用しています。
仕様の詳細は、リンクをご参照ください。

コントローラ　：　Arduino Mega2560　　https://docs.arduino.cc/hardware/mega-2560/
HILシミュレータ　：　Arduino DUE　　　　https://docs.arduino.cc/hardware/due/
実機（動画のみ）　：　　Arduino Mega2560

コントローラとHILシミュレータで別型を使用している理由は次の通りです。
・　コントローラの制御周期に比べてHILシミュレータではモデルの計算を十分短時間で行う必要がある
・　HILシミュレータにはアナログ出力が必要であり、DUE にはアナログ出力出来るDAコンバータがある。一方、Mga2560にはPWM波による疑似的なDAコンバータしかなくアナログ出力ができない。