Main Content

プロジェクトへのガイドラインの適用に関する考慮事項

モデリング ガイドラインをプロジェクトに適用するときには、次を検討することが重要です。

ガイドラインを適用する際のモデル解析プロセスの使用

ガイドラインを確認する前に、モデル設計の仕様を定義する必要があります。この作業を行うことで、適用するガイドラインや、ガイドラインの実装を決定するプロセスが効率化されます。

たとえば、単純なモデルの解析では、関数 sldiagnostics を使用して、特定のブロックの使用頻度を調査します。頻繁に使用するブロックと、使用しないブロックを指定して、運用ルールのリストを調整します。

さらに、後半の段階における再利用性は、次のルールを追加することで向上します。

  • 記述スタイルを統一する。

  • モデルを修正するために必要な工程数を事前に予測する。

  • フィードバック ステータスの変数を持つブロック (Unit Delay ブロック) を配置する場所、Unit Delay ブロックをサブシステムの内側または外側のどちらに配置するか、またはAbsブロックをサブシステムの出力側に設定するかどうか、および信号を受信した後に入力側で処理するかどうかなどの傾向を評価する。

ガイドライン ルールの採用とプロセスの設定

プロジェクトの開始時には、各開発プロセスに適用するガイドラインを決定しなければなりません。ガイドラインを評価し、開発プロセスに合わせて適用する必要があります。次の質問を考慮します。

  • ガイドラインはコード生成の段階にのみ適用しますか。

  • プロセスの各段階でガイドライン ルールの変更を採用しますか。

ガイドライン ルールの適用分野の設定と除外条件の明確化

ガイドラインを適用する分野を決定しなければなりません。たとえば、次のようなガイドラインにします。

  • AUTOSAR 応用分野を表すモデルに制限する。

  • モデルが中断を実装する場合 (計算中の中断を禁止するプロセスを追加する) など、一般的なソフトウェア分野に適用する。

  • 一般的なエンジニアがモデルを編集する分野に固有なものにする。これらのルールの目的は、該当する分野でモデルを分かりやすくすることです。

    メモ

    特殊な分野は、範囲を制限し、この環境内で固有の独自のガイドラインを適用することで、これらのガイドラインの制約から除外できます。

モデル管理者がカスタム ライブラリ ブロックを設計するような特殊な分野は、通常これらのガイドラインの対象になりません。

さらに、ラピッド制御プロトタイピング (RCP) で動作する制御モデルがある場合は、モデル全体をターゲットとして設定できません。代わりに、分野を制限する必要があります。コードを生成し、組み込みのマイクロコンピューターに実装される領域、実装されない領域を確認する必要があります。これらのガイドラインが適用されない制御モデルは、RCP 用にのみ作成されているが実装されていないスケジューラ モデルです。また、実際のマシンを操作する CAN や PWM 信号などのドライバーに対応するブロックをもつインターフェイス セクションにも適用されません。

ガイドラインのパラメーターの推奨事項

ガイドラインは、その後の評価なしで記述されているとおり採用すべきではありません。

ガイドライン ルールとパラメーターの推奨事項の実装を評価して、プロジェクトと使用されている開発プロセスへの影響を判断しなければなりません。さらに、他のガイドラインへの影響や、カスタム パラメーターの適用がシミュレーションまたはコード生成に与える影響も考慮する必要があります。

ガイドライン準拠の検証

プロジェクトの開始時には、ガイドラインに確実に準拠するために、プロジェクトを評価する方法とタイミングを決定することが重要です。

自動のチェック メカニズム (サードパーティまたは内部の) を使用するか、手動のチェックを実行するかの判断は非常に重要です。また、チェックが行われる段階に加え、チェック ルール基準を見直すシステムの作成も重要です。

自動化されたチェックは、確認に必要な時間を大幅に削減します。すべて自動でチェックできる場合でも、スキルのある担当者が追加で手動確認を実施することをお勧めします。

ガイドライン準拠の変更

ガイドラインまたはルールの適用に関する決定は変更することができます。変更する場合は、要求の根本原因を判断し、変更がプロジェクトと組織に与える潜在的な影響を評価するプロセスと手順を指定することが重要です。

変更要求を評価する場合は、最初に、モデル管理者のニーズを聞いて、要求の根本原因を判断します。要求が、ブロックの用途やガイドライン ルールを把握していないユーザーが原因の場合は、ルールを修正するのではなく、トレーニングを実施しなければなりません。

会社の目標や制御仕様またはハードウェア (マイクロコンピューターなど) による制限がある場合は、必要に応じてルールを緩和する手順を実装しなければなりません。