2023年6月23日に開催致しましたウェビナー「論理アーキテクチャの重要性と設計・検証実例のご紹介」には自動車OEM様、サプライヤ様を中心に100名を超える多数の方にご参加頂きありがとうございました。

当日はQ＆Aセッションを設け、視聴者様から頂いた質問に回答させて頂きましたが、時間の関係で当日回答できなかった分を含め、代表的な質問と回答を以下に公開させて頂きます。なお、回答にあたってはウェビナーでご紹介させて頂きました実例に取り組まれたサプライヤ様にもご協力頂きました。

■開発プロセスに関するQ＆A

【Q1】OEM自動車会社の要求仕様に基づいてTier１でモデルを作ったものをシミュレーションしたと思いますが、そもそものOEMからの要求仕様はどのような形でTier１に提示されたのでしょうか？

【A1】提示元によって、EXCEL、パワポ、ワード、EA等、インプット情報の種類と組み合わせはばらばらで、さらに要求、要望、仕様等の粒度もばらばらであるため、サプライヤ様ではその扱いや管理に苦労されているのが実情です。

【Q2】最初に論理アーキをつくるために、必要な機能、構造、振る舞いを定義するとあったが、それらを抽出するプロセスはなにかあるのか？具体的な事例はありますか？

【A2】SysMLを前提とするならMBSEのプロセスや方法論が参考になると思います。INCOSEが提供するものとして はOOSEM（Object-Oriented Systems Engineering Method）があり、書籍「システムズモデリング言語SysML」には事例とともに紹介されていますし、その他にもSysMLツールベンダが提供する各種方法論もあります。

ただし、それらを参考にしながらも実務のレベルでは各企業で独自のプロセスを構築する必要があると思います。

【Q3】論理アーキ・物理アーキの定義があまりわからず教えてください。

【A3】論理アーキは機能に着目し、理屈上でどう動くかを表現するものです。物理アーキはその機能をハードウェアとソフトウェアでどう実現するか、その境界とI/Fも含めて設計します。ハードウェア設計ではどういうチップを選択するかまで考えます。例えば国別、車種別、グレード別に異なる要件を満たすためには幾つかの種類（バリアント）を考える必要があります。

【Q4】論理アーキから物理アーキへの展開、ツール間のモデル変換はどのように行えるのでしょうか？

【A4】今回紹介した実例では、論理アーキはEA（SysMLモデルベース）で構築し、DynaSpecで検証しました。検証済の論理アーキをINPUTとして物理アーキ（例えばMATLAB/Simuklinkモデル）を構築します。ただし、ツール間のモデル自動変換については今回紹介した弊社ソリューションでは提供していません。

■ツール／モデル化／検証に関するQ＆A

【Q5】MATLAB / SImulink / Stateflow でも昔から同じことができると思いますが、このツールでやる利点は何でしょうか？

【A5】MBSEの標準言語として認知され、組織内外での共通言語になり得るSysMLでモデリングし、それを直接検証できることがEA&DynaSpecを採用するメリットになります。

【Q6】検証結果のレポート機能とERR発生時のERRのみの再現を簡単に実施することはできますか?

【A6】シミュレーションモードでの出力情報はアニメーション可能な遷移ログで、ASSERT違反が発生すればその時点で停止し、そこまでの遷移ログを出力します。

モデル検査時モードでエラーが発生しなければ探索した状態数やメモリ消費、実行時間等の情報が出力されます。ASSERT違反が検出されればその時点で網羅的な振る舞い探索ロジックは停止し、上記の情報に加えて違反が発生したケースの初期状態から違反発生までの遷移ログを出力します。

出力された遷移ログを元にアニメーション表示が可能です。

【Q7】モデルの動作時間は実物の動作時間とどのように一致性を保証できるのでしょうか？（モデルの動作時間はPCの性能で決まると思いますので質問しました）

【A7】今回紹介したソリューションはリアルタイムシミュレーションで動作させるものではないので、時間進行はモデル上の仮想的なものです。PCの性能で実行時間は変わりますが、モデルで表現される動作時間の評価には影響しません。

【Q8】あらかじめアクティビティの動作時間を設定するとのことですが、物理が決まっていない中、どのような考え方でこの時間を決めるのでしょうか？

【A8】例えば「バックギヤに入れてリヤカメラの画像を出すまで２秒以内（米国の法規）」「電源を入れて音が鳴るまで５秒以内（顧客の性能要件）」等、守るべき制約が存在します。この制約を満す設計がなされているかを論理の段階でおおまかにでも検証できるのが望ましいです。

設計が守るべき時間制約を満たしているかを検証するには、該当する処理シーケンスで工程毎に想定される処理時間（許容できる時間）を予め大まかにでも想定しておくことで検証が可能になります。（通信工程なら通信規格により通信時間を求めておく等）

【Q9】割り込み問題で、数十ｍSecで問題が発生するケースがありますが、本システムではどのように網羅的にそのタイミングを特定することができますか？

割り込み条件や異常状態（瞬断等）ですべての条件を網羅する必要がありますが、その点で本システムでのメリットはありますか？

【A9】論理の段階で時間精度をどこまで詳細にモデル化するかという問題はありますが、例えば外部環境モデルにおいてイベント発生時刻を特定せず非決定性を持たせることで、モデル検査では起こりうるあらゆるタイミングで自動的にイベントを発生させて検証することができます。これによりタイミングによる微妙な差異で不具合が発生することを検出することができます。

【Q10】形式検証には、モデル検査以外にも、定理証明があると思います。SysMLと定理証明との連携に関する事例やツールサポートなどはあるのでしょうか？

【A10】今回の取り組みで実施した形式検証は、DynaSpecが採用しているSPINによるモデル検査のみです。定理証明は自動証明が困難で数学的知識が必要となり、現場への導入ハードルが高いと考えており、弊社では現時点ではモデル検査のみをサポートしております。

【Q11】どの程度の規模(オブジェクト数）のモデルまで検証が可能でしょうか？

”ツールの制約”と”人間の理解ができる範囲”の2つの観点で教えていただきたいです。

【A11】規模に関する制約はツール側には特にありません。実行するPCのメモリ環境等に依存します。検証可能なモデル規模は、オブジェクトの数のみではきまらず、それぞれが何状態を取るか、どういう条件で遷移するかにもよります。システム全体のある静的状態を1状態とし、それが変化した状態数として数千万～1億程度の状態は目安として検証可能です。メモリ消費するのはモデル検査実行時ですので、モデル構築とアニメーションをPC上で行い、負荷のかかるモデル検査のみを大容量メモリ（例えば1TB等）のクラウド環境で行うこともできます。

これらの膨大な状態を人間が考えて網羅テストすることは困難ですので、ツールに任せて不具合が検出された時に対処するのが現実的です。

【Q12】EA自体が持つJavaScriptを使ったシミュレーション機能と共存できますか？（両方で使えるモデルを作れますか？）

【A12】現時点では実績がないため、明確な回答はできません。

■その他のQ＆A

【Q13】主に対象が製造業の制御系や組み込み開発だと思いますが、例えば金融や流通の情報系やエンタープライズシステムの上流工程における品質確保（シフトレフト）に対しても、今回ご説明頂いた手法やツールは有効なのでしょうか？具体的な導入・適用事例はありますでしょうか？

【A13】弊社ではそれらの業界における具体的な適用事例はございませんが、対象は製造業や組み込みシステムに限定しません。

【Q14】EAでソフトウェアの設計情報をUMLで表す際や状態遷移のシミュレーション方法などを紹介している資料があれば展開していただきたいです。

【A14】弊社の資料としては、今回一部をご紹介したガイドラインの他、DynaSpecのチュートリアル等のドキュメントがありますが、（試用も含めて）ユーザ様向けのため一般公開はしておりません。

Enterprise Architectの公式サイトには各種ドキュメントライブラリが公開されています。

以上

より詳しいご説明を希望される場合は、以下のアドレスにメールでお問合せください。

メールアドレス：aor-bizdev@kke.co.jp（担当　太田）