Manage Design Data

R2026b

Step 3 of 6 in Use Model-Based Design to Build a Battery Management System

• 2
• 3
• 4

This project stores all design data in Simulink^® data dictionaries. To change parameters for a component, open the associated data dictionary (*Data.sldd) in Model Explorer and edit the Design Data section.

For example, to adjust cell balancing thresholds, open CellMonitoringAndBalancingData.sldd. To change battery pack topology or initial conditions, open BatteryData.sldd.

In this section, you:

1. Understand why data dictionaries replace base workspace variables.

2. Organize dictionaries using the parent-reference pattern.

3. Define component port interfaces as bus objects.

4. Centralize configuration sets in a shared dictionary.

5. Store enumeration types as class files on the MATLAB^® path.

Why Use Data Dictionaries

Simulink models can store design data in the base workspace, a model workspace, or a data dictionary. Each option is suited to a different stage of development:

Storage	Best For	Tradeoff
Base workspace	Quick prototyping, one-off scripts	Data is lost when MATLAB closes; no version control
Model workspace	Self-contained models with few shared parameters	Data travels with the model, but sharing across models requires duplication
Data dictionary (.sldd)	Collaborative projects with shared parameters and explicit interfaces	Requires file management, but enables version control, traceability, and parallel work

This BMS project uses data dictionaries exclusively. For a large-scale collaborative project, data dictionaries store parameters, bus objects, configuration sets, and enumeration types separately from the models. This separation enables parallel work, explicit dependency management, and clear ownership of data. For more information, see Manage Configuration Set Stored in Data Dictionary.

Component Dictionary Organization

Rather than storing all design data in a single monolithic dictionary, the BMS project uses a component-based approach: each component has a parent dictionary that references separate referenced dictionaries for parameters and interfaces. A referenced dictionary stores a subset of entries that the parent dictionary can access without duplicating data. For more information, see Partition Dictionary Data Using Referenced Dictionaries.

Each component uses three dictionaries in a parent-reference pattern:

• *DD.sldd (parent dictionary) — Links to the model, contains no entries of its own, and references the other two dictionaries and SystemConfiguration.sldd.

• *Data.sldd (referenced dictionary) — Stores entries in the Design Data section: component-specific parameters such as tuning gains, thresholds, and limits.

• *Interface.sldd (referenced dictionary) — Stores entries in the Architectural Data section: Simulink.Bus objects that define port interfaces.

Parent (*DD.sldd)	Design Data (*Data.sldd)	Architectural Data (*Interface.sldd)
CellMonitoringAndBalancingDD	CellMonitoringAndBalancingData	CellMonitoringAndBalancingInterface
SystemControlAndProtectionDD	SystemControlAndProtectionData	SystemControlAndProtectionInterface
StateMachineDD	StateMachineData	StateMachineInterface
BatteryDD	BatteryData	BatteryInterface
BMSHarnessDD	BMSHarnessData	BMSInterface and BatteryInterface

All parent dictionaries also reference SystemConfiguration.sldd, a shared dictionary that prevents duplication of configuration entries needed by multiple components.

This partitioning provides these benefits:

• Separation of concerns — Parameter entries are in the Design Data section of *Data.sldd, port interface definitions are in the Architectural Data section of *Interface.sldd, and solver and code generation settings are in SystemConfiguration.sldd.

• Parallel development — Team members can modify component dictionaries independently without conflicts.

• Clear ownership — Each referenced dictionary has a single owner responsible for its entries.

To link a parent dictionary to a model, on the Modeling tab, click Design > Link to Data Dictionary and select the parent dictionary of the component (*DD.sldd). For example, link CellMonitoringAndBalancingDD.sldd to the CellMonitoringAndBalancing.slx model. The model then resolves entries from all referenced dictionaries through the parent.

Tip

To visualize the full dictionary reference hierarchy, right-click a dictionary in Model Explorer and select View Hierarchy. This opens the Dependency Analyzer, which shows parent-reference relationships across all dictionaries and models. Use the DataSource column in Model Explorer to confirm which dictionary stores each entry.

Define Component Port Interfaces

Define the data exchanged between components using Simulink.Bus objects stored in the Architectural Data section of *Interface.sldd dictionaries. Bus objects specify signal names, data types, and dimensions to maintain consistency across model boundaries.

The BMS project uses a hierarchical bus structure:

Data Dictionary	Bus Objects	Scope
BMSInterface.sldd	BMSCmdBMSPart, SensorsBMSPart, and BMSInfoBMSPart	BMS controller-level interfaces
BatteryInterface.sldd	BMSCmdBatteryPart and SensorsBatteryPart	Battery plant-level interfaces
CellMonitoringAndBalancingInterface.sldd	Component-specific buses	Between CellMonitoringAndBalancing and other controller components
StateMachineInterface.sldd	Component-specific buses	Between StateMachine and other controller components
SystemControlAndProtectionInterface.sldd	Component-specific buses	Between SystemControlAndProtection and other controller components

Buses cascade from component-level to system-level to battery-level. Each referenced dictionary defines the signals that the component produces and consumes in its Architectural Data section, following a single-element bus pattern (BusName.ElementName).

Centralize Configuration Sets

Store solver settings, code generation parameters, and other model configuration in the Configurations section of SystemConfiguration.sldd. Share this configuration across all models by using configuration references (Simulink.ConfigSetRef).

With a centralized configuration set, all models in the BMS project use consistent solver settings, sample times, and code generation options. When you change a setting in SystemConfiguration.sldd, the change propagates to models that reference it.

To use a shared configuration set:

1. Open SystemConfiguration.sldd in the Model Explorer.

2. Define the configuration set (solver type, fixed-step size, code generation target).

3. In each model, on the Modeling tab, click Model Settings. Under Configuration Reference, select the configuration set from SystemConfiguration.sldd.

Enumeration Types

The BMS project defines three enumeration types as MATLAB class files stored in Design/Dictionaries/:

• BMSStateEnum.m — BMS operating states (Standby, Driving, Charging, Fault).

• Contact.m — Contactor states (Open, Closed).

• StateRequestEnum.m — External state requests (Standby, Drive, Charge).

The project keeps enumerations as separate .m class files on the MATLAB path rather than as data dictionary entries. This design simplifies source control differencing and enables you to share the enumerations across multiple components without adding dictionary cross-references.