specifying-mbd-algorithms

MBD アルゴリズム仕様

モデルベース設計向けアルゴリズムの構造化仕様です。specifying-software のテンプレートを MBD アルゴリズムの領域に適用します。

使用する場合

• コントローラー、推定器、信号処理器、診断ロジック、または監視ロジックのアルゴリズムを仕様化する場合
• アルゴリズムを Simulink、Stateflow、System Composer、または MATLAB Function ブロックで作成する場合
• アルゴリズムがモデルベース設計のワークフロー（シミュレーション、コード生成、またはその両方）の一部である場合
• アルゴリズム仕様書を作成、更新、またはレビューする場合

使用しない場合

• アルゴリズムモデルの構築 → building-simulink-models を使用してください
• 既存モデルのテスト → testing-simulink-models を使用してください
• プラント／環境モデル → specifying-plant-models を使用してください
• 従来型ソフトウェア（C、C++、Python、スタンドアロンの MATLAB スクリプト）→ specifying-software を使用してください
• 閉ループシステム全体 → アルゴリズム側にはこのスキルを、プラント側には specifying-plant-models を使用してください

出力規約

アルゴリズムごとに仕様書を保存します。すべてのファイル名の先頭にアルゴリズム名を付けてください：

docs/specs/algorithms/<algorithm-name>/
├── <algorithm-name>-system.md
├── <algorithm-name>-architecture.md
├── <algorithm-name>-implementation-plan.md
└── <algorithm-name>-test-plan.md

モードの選択

これは、動作モードが 3 つ未満でシングルレートの単一関数アルゴリズムであり、1 人の担当者／エージェントが構築しますか？

• はい → クイック仕様：2 つの文書（システム仕様とアーキテクチャ仕様を統合、実装仕様とテスト仕様を統合）
• いいえ → 完全仕様：4 つの個別文書

ワークフロー

ステップ 1：外部インターフェースの確立

このアルゴリズムの接続先を特定します。既存のシステムがある場合は、model_overview と model_read を使って読み取ります。新規に作成する場合は、要件に基づいて境界を定義します。

アルゴリズム境界を越えるすべての信号を分類します：

• 入力：計測値、コマンド、他のサブシステムからのバス信号
• 出力：アクチュエーターコマンド、処理済み信号、ステータス／診断フラグ
• パラメーター：調整可能（キャリブレーション可能）か固定（設計時）か

ステップ 2：アルゴリズムの目標の定義

アルゴリズムが達成すべき内容（追従性能、帯域幅、外乱除去、検出しきい値、処理遅延など）を確立します。これらは、アーキテクチャの決定とテスト計画の設計を導く受け入れ基準です。

ステップ 3：ドメインの検証（式、規格、またはドメインの規約を参照する場合）

web_search を使用して、仕様書で参照する主要な式、規格、または規約を確認します。確認済みの情報源を付録 B「調査メモ」に記録します。

次の場合は省略します：アルゴリズムが純粋なロジックベースである、ドメインがよく知られている、または式が関係しない場合。

ステップ 4：システム仕様書の作成

テンプレート：assets/system-spec-template.md

次に進む前のレビューゲート — 以下を確認してください：

• 定量的な受け入れ基準を含む、明確なアルゴリズムの目標
• 完全な外部インターフェース契約（単位と符号規約を含む、すべての入力、出力、パラメーター）
• 動作モードの網羅性 — 起動、故障、縮退モードを含むすべてのモードが定義されているか
• アクチュエーター／エフェクターのマッピングの正確性 — どの出力がどのアクチュエーターを駆動するか、符号は正しいか
• 境界での動作 — 飽和、ゼロクロス、有効化／無効化しきい値で何が起きるか

ステップ 5：アーキテクチャ仕様書を作成する

テンプレート：assets/architecture-spec-template.md

最終確定前のレビューゲート — 以下を確認します。

• 次元の整合性 — すべてのインターフェースを通して単位が一致していること
• フィードバックの極性 — 安定化ループでは負のフィードバックを使用し、ループ全体で符号が正しいこと
• すべての積分器について、アンチワインドアップとリセット動作が規定されていること
• モード遷移ロジック — バンプレス切り替え、モード移行時の初期化、ガードのない遷移がないこと
• レート遷移 — マルチレートのインターフェースが正しく処理されていること
• アクチュエーター出力とチャネルごとのレベルで、飽和と制限が行われていること
• 代数ループ — すべてのフィードバック経路に明示的な遅延要素があり、IC と DFT のステータスがコンポーネントカタログに注記されていること
• 該当する場合、コード生成の制約（データ型、スケジューリング、メモリ）が考慮されていること

必須： 近接するコードですでに使用されていない API、関数、またはブロックの動作については、API 検証を行います。evaluate_matlab_code、web_search、または既存のコードベースでの使用箇所を使って、実際のシグネチャと動作をテストします。アーキテクチャ仕様書の付録 B に記録します。

ステップ 6：実装計画とテスト計画を作成する

テンプレート：assets/implementation-plan-template.md、assets/test-plan-template.md

レビューゲート — 実装計画 — 以下を確認します。

• フェーズ 0 のインターフェース凍結によって、すべての並行作業が開始可能になること
• ビルド順序がデータフローの依存関係に従っていること（リーフコンポーネントから先に構築）
• 密接に結合したコンポーネントが同じエージェントに割り当てられるか、連携が調整されていること
• 各チェックポイントに具体的な検証手順（model_read、model_query_params、test）があること
• パラメーター表が出典を含めて完全であること

レビューゲート — テスト計画 — 以下を確認します。

• 段階的な検証：コンポーネント MIL → 統合 MIL → システム・イン・ループ MIL → ロバスト性 → SIL/PIL（コード生成の場合）
• 起動時と故障時を含む、すべての動作モードがテストされていること
• バンプレス切り替えの確認を含むモード遷移シナリオがあること
• 飽和とアンチワインドアップからの復帰テストがあること
• 各テストに設計根拠を伴う定量的な合格基準があること
• 入力信号の定義が各段階で再利用できること

実装を開始する前に、ユーザーの承認を得てください。

既存の仕様書の更新

仕様書を更新する際は、影響を受けるセクションを確認して更新し、「最終更新日」を更新して、他の仕様書との整合性を確認します。

ガードレール

必ず行うこと

• 制御ループのアーキテクチャを最終確定する前に、フィードバックの極性を確認します
• すべてのインターフェースを通して、単位と符号規約を確認します
• サブシステムの並行作業を始める前に、インターフェースを凍結します（フェーズ 0）

事前に確認すること

• システム仕様書にない動作モードの追加
• フェーズ 0 の凍結後のインターフェース信号の変更
• プラントまたはシステムのサンプル時間の整合からの逸脱

決して行わないこと

• 積分器のアンチワインドアップ／飽和動作を規定せずに制御を実装する
• 調整可能にすべきチューニングパラメーターをハードコードする
• マルチモードアルゴリズムのモード遷移の仕様を省略する
• 連続時間経路の代数ループを Memory ブロックで分断する（離散系では Unit Delay、連続系では時定数の小さい Transfer Fcn を使用する）

仕様書の種類

オプションの仕様書（詳細仕様書、コンポーネント仕様書）を作成するタイミングについては、references/spec-types.md を参照してください。制御則、ステートマシンの定義、またはインターフェース契約が原因でアーキテクチャの作成が進められない場合は、詳細仕様書を作成します。

参考資料

• assets/system-spec-template.md — システム仕様書テンプレート（対象と目的）
• assets/architecture-spec-template.md — アーキテクチャテンプレート（機能分解）
• assets/implementation-plan-template.md — 構築手順テンプレート
• assets/test-plan-template.md — 検証計画テンプレート
• references/algorithm-guidance.md — 任意のドメイン調査チェックリスト
• assets/detailed-spec-template.md — 制御則、ステートマシン、またはインターフェース契約（アーキテクチャの作成が進められない場合に使用）
• assets/component-spec-template.md — 複雑なコンポーネントの内部仕様（通常は不要）

---

Copyright 2026 The MathWorks, Inc.

---