5.状態遷移表
出力のデータ型を設定せずに信号の追加をされていましたが、実際の開発現場では暗黙キャスト扱いになるので、明示的な対応が必要と思いますが、認識あっていますでしょうか？
C言語などでも最近は暗黙キャストを嫌う傾向にあり、特にハードウエアを扱う組込みシステムでは大事な問題です。
全部の変数を明示的に扱うと数値の精度に起因する不具合は防げますが、開発の簡易性は失われます。
トレードオフなので、私は必要に応じて明示するのが良いと考えています。
今回は、説明を簡単化するために変数の型は明示していません。
数値の精度を意識しないで済むアルゴリズムでの例題としたためです。
Example-3でご指摘の信号の追加の場合、エクスプローラ（モデルエクスプローラ）で変数を確認すると、下図のようになっています。
例えば、In は、チャートに繋がるSimulink側の信号の型に自動的に合わされています。
これは、プルダウンメニューで明示的に変更することもできます。
型を意識しなければ開発が簡易になることもありますが、どこで数値の精度を保証するかも大事となります。
特にハードウエアが係るところでは、変数の型が大事とります。
そのため、Simulinkでも下のような型変換（キャスト）を行うブロックも用意されています。
さらに、どこで数値の精度を保証するかも大事となります。
例えば、Simulink Support Package for Arduino Hardware にある PWM の
ブロックでは、下図のようにブロック内で、ハードウエアにデータを渡す直前で
uint8（符号なし8ビット整数）にキャストを行っていますが、普段は隠蔽されています。
結局、簡易性と厳密性のバランスかと思っています。
一つの方法として、特に意識が必要な個所を除き、型を意識せずに開発を行い
MILS/HILSでの動作検証で不具合を検証する方法もあります。
6.Stateflowの高度な使い方
今回パラレルステートの説明いただいた際に、Check でイベントを管理し、トリガー条件としてLight側が動くというつくりでしたが、各々干渉しないつくりも実現可能ではないかと思いますが認識あっていますでしょうか？
例：片側では、定周期のトリガーイベントを作成し、もう片側では割り込みイベントを生成し、後段のあるファンクションコールに接続することが可能。
はい。私どもと同じ認識です。
今回は、イベントを用いた同期をテーマとしたので、このようなつくりとなりました。
是非、色々な設計を試してください。
hasChanged**はどの位置づけになるのでしょうか？entryなどのアクション関数としての位置づけと一緒でしょうか？
明確なドキュメントは見つけれていないのですが、遷移に関連する条件やイベントのような位置づけと考えています。
アクション関数は状態に関連するものなので、別と考えています。
全体を理解のためにサブチャート化を教えていただきましたが、システム開発では全体を見えないと思うのですが、サブチャート化は必須なのでしょうか？
また、サブチャート間での接続はJMAABでは推奨されていませんが、サブチャートの用途が薄いと思いますがどのようなお考えでしょうか？
必須ではありません。
ご指摘のように、サブチャート化することで全体が見えなくなることもあります。
特に、チャート内の状態が少ないとき、あるいは、サブチャート内の状態から別のサブチャート内の状態に遷移するような場合は、サブチャートを用いない方が良いと思います。
一方で、一目で理解できる要素数は7個くらいまでともいわれます。
そのため、説明したい内容に応じて適度な粒度でサブチャート化することは有効と考えています。
参考：https://monoist.itmedia.co.jp/mn/articles/1602/01/news007_2.html
さらに、「文化」も大事です。
開発メンバーが同じ認識を持っていることが大事なので、無理にサブチャート化を進めるものてもありません。
私の方でJMAABで推奨されない理由が理解できていないのですが、おそらく、安易にサブチャートを用いると、そのサブチャートの間違った理解によってシステムに不具合が生じるのを防ぎたいのだと思います。
ご参考になれば幸いです。
haschanged**でのイベント発生条件が≠→＝や＝→≠になっておりますが、入力が量子誤差が乗った場合は、判断できるのでしょうか？またオートコード化するとマイコン依存の量子誤差が乗ってしまうと思いますが、haschanged**は使用可能なのでしょうか？
ご指摘のとおりね変数が実数だと、量子化誤差で不具合が生じる可能性があります。
可能であれば、整数値のみで使用するのが良いと考えています。
Stateflowの扱いを学ぶにはどのようにしたらいいでしょうか？
MathWorksのHPでトレーニングとかは受講済みですが、今回の内容はありませんでした。
なにか良い教材等がございましたらご教授お願い致します。
状態遷移をテーマにした参考書は、あまり無いようです。
次が参考になるかと思います。
参考書（図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
7.MBD開発プロセス
一度にすべてを実機に置き換えるのではなく、各要素ごとに機能確認をしていく重要さを再認識した。またHILSとMILSの用と目的の違いについても理解できた。
HILS検証において、２つ以上の機能組み合わせによる動作検証を実施したい場合、検証項目が膨大になってしまうと考えられるが、適切なテスト項目の選び方などの知見があれば知りたい。
HILSに限らず、システムが大きくなると検証項目が膨大になる傾向があります。
適切なテスト項目の選び方は、V字プロセスの右バンクをいかに作るかということでしょう。
単純にすべての組み合わせを考えると膨大になります。上位の要求（右バンク上の方）を満たすために下位（V字の付け根側）の要求（何ができればよいか）を検討し、重要度の高いものやリスクが高いものを優先に検討することが考えられます。
以下、直接の回答ではありませんが。ご参考まで。
結合テストにおける複雑さ問題は、ソフトウエア開発では以前より問題にされており多くの知見があります。
「ソフトウエアテスト」、「結合テスト」などで調べてみると良いと思います。
状態遷移に対するテストについて次の記事があります。
Qiita : UMLステートマシン図を用いた状態遷移テストの注意点
https://qiita.com/ToshiManaPlus1/items/be8b698772ea3a42058b
その他
HILSimulator または ControllerModel をマイコンに書き込もうとすると、エラーが生じ書き込めません。
次を試してみてください。
その１：
【HILS動作確認（DCモータ制御システム）】 内の「 HILシミュレータ動作確認手順書（DCモータ）_R2019a以前.pdf」のうち、
P.8 からの「 エラー対応について 」を試してみてください。
その２：
PCに登録されている COM ポートが多くなりすぎている可能性があります。
次の手順で削除してください。
①Arduino をUSBポートから抜く
②スタートでマウスの右ボタンから、デバイスマネージャを開く
③デバイスマネージャで、「表示」 > 「非表示のデバイスの表示」にチェックを入れる
④「 ポート（COMとLPT） 」にたくさんのArduino があると思います。
アイコンが鼠色の Arduino DUE と Arduino Mega 2560 の COMポート（右図の赤色の部分）を、
ひとつずつすべてについて、ポートを選択してマウスの右ボタンから「デバイスのアンインストール」を選択し、
アンインストールする
