Managing Simulink Projects

MATLAB projects coordinate Simulink workflows, they manage the MATLAB path (which Simulink uses to resolve model references, data dictionaries, and requirements), track file membership for source control, and provide label-based automation for selecting targets in CI/CD pipelines.

When to Use

• Creating a new MATLAB project for Simulink models
• Adding models, data dictionaries, or requirements to an existing project
• Configuring project paths so Simulink can resolve references
• Setting up labels for automation (test selection, code generation targets)
• Configuring source control and cache folders
• Diagnosing broken model references, missing dictionaries, or failing project health checks

When NOT to Use

• Building or editing model structure (blocks, connections) → use building-simulink-models
• Writing or running tests → use testing-simulink-models
• Drafting requirements content → use generate-requirement-drafts
• Running simulations for analysis → use simulating-simulink-models

Mental Model

Four principles that prevent the most common failures:

1. Registration ≠ path. addFile registers a file with the project for source control tracking. addPath puts a folder on the MATLAB path so Simulink can resolve artifacts by filename. These are independent operations, you almost always need both.

2. Filename-only resolution. Data dictionaries (set_param(...,'DataDictionary',...), addDataSource), model references, and requirements all resolve via MATLAB path using filename only, never full paths. The containing folder must be on the project path.

3. addPath is not recursive. Each subfolder containing resolvable artifacts needs its own addPath call.