Configuring Code Interfaces

Configure how model elements map to generated code — storage classes for elements in models configured with data interface configuration, and service interfaces for elements in models configured with service interface configuration.

Prerequisite: For full functionality of the skill (such as function mapping, specifying the deployment type, and using service interface configuration), the model needs to be configured with the ERT system target file (SystemTargetFile = "ert.tlc", or an ERT-based derivative such as ert_shrlib.tlc or a vendor ERT target). When the model is configured with the GRT system target file (SystemTargetFile = "grt.tlc"), only basic configuration operations such as specifying the storage class of model elements are supported. To configure the model with the ERT system target file, use the neighboring skill simulink-configure-model-for-code-generation.

Requires:

• For models configured with the GRT system target file, a Simulink® Coder license is required.
• For models configured with the ERT system target file, an Embedded Coder® license is required.

When to Use

• When setting storage classes for inports, outports, states, or parameters through code mappings. If the project assigns storage classes through data objects instead (such as Simulink.Parameter or Simulink.Signal), that is a different workflow — see references/code_mapping.md, which also covers the one case that must be configured on the object.
• When specifying the code representation of signals, states (such as values that Unit Delay and Integrator blocks hold between steps), parameters, or data stores. For example, when mapping a model element in this category to a global or extern variable, or when placing its declaration in a designated .h or its definition in a designated .c file. These requests map model elements to storage classes even when the user never explicitly says "storage class" or "code mapping".
• When making a parameter tunable in the generated code (a global parameter that the rest of the software can read and update).
• When mapping function names. This happens when the user explicitly names generated entry-points or any other type of generated functions. For example: "make the startup routine be called mFunctions_startup".
• When specifying data defaults or function defaults for code generation.
• When configuring the model with either data or service interface configuration for code generation.
• When linking a shared Embedded Coder dictionary to a model.
• When configuring sender-receiver or client-server interface patterns.
• When setting deployment types and function prototypes for generated code.
• When inspecting or verifying the current model interface. For example: "is this model set up for data interface or for service interface?", or "did my dictionary link take effect?"

When NOT to Use

• When configuring non-mapping-related aspects of the model for code generation (such as specifying the target platform, hardware, or objective). For these purposes, use the skill simulink-configure-model-for-code-generation.
• When opening, editing, or building a model or its structure. For these purposes, use the skill building-simulink-models.
• When customizing the exported A2L (ASAP2) calibration file — COMPU_METHODs, GROUPs, STD_AXIS→COM_AXIS, BIT_OPERATIONs, or VARIANT_CODING. For these purposes, use the skill simulink-customize-a2l (coder.asap2.*). This skill owns the model-side calibration attributes that code mappings carry (Export, CalibrationAccess, BitMask, CompuMethod, DisplayIdentifier, Format) and that the A2L export then reads; it does not edit the A2L file.
• When the code generation target is not C/C++ through Simulink Coder or Embedded Coder. For example, when it is one of these:
  • HDL Coder, which uses hdlcoder.* APIs and generates VHDL/Verilog.
  • Simulink PLC Coder, which generates IEC 61131-3 Structured Text.
  • MATLAB Coder or GPU Coder, which generate C/CUDA code from MATLAB functions (these do not generate code from Simulink models).
• When using an API surface that does not rely on coder.mapping.* or coder.dictionary.*. The generated code is still C or C++, but uses different mapping APIs. For example, when the API surface is one of these:
  • AUTOSAR Classic or AUTOSAR Adaptive (autosar.api.*). For authoring a Classic AUTOSAR software component — including its port, data, and service interface configuration — use the skill simulink-author-classic-autosar-swc.
  • DDS (Data Distribution Service) code mapping
  • C++ class code interface packaging (SystemTargetFile = "ert.tlc" and CodeInterfacePackaging = "C++ class").
• When deploying the generated code for Embedded Linux.

This skill covers C Data Interface configuration when using Simulink Coder or Embedded Coder. The skill also covers C Service Interface configuration when using Embedded Coder.

Critical Guardrails

• Read-only inspection needs no permission — run it. Queries that do not modify the model or dictionary — introspect_api, find(cm,...), model_read/model_query_params, getModelParameter/getDeploymentType/getDataStore, coder.dictionary/coder.mapping getters — are safe. Run them freely to diagnose, detect mode, and verify; never stop to ask before a read. The confirmation gate below applies only to writes (save_system, slbuild, addEntry/set(entry,...)).
• Call introspect_api (in scripts/) BEFORE assigning any storage class, service, deployment type, or per-element property. It returns allowed values, valid properties, and the current mode (DataInterface vs ServiceInterface). This is a required first step — do NOT discover valid values by trial-and-error or repeated probing calls. Enumerate first, then set the value you learned is valid.
• NEVER save or build the model on your own — always ask the user first. Do not call save_system or slbuild (or set GenCodeOnly and build) without explicit user confirmation. Saving overwrites the user's model/dictionary on disk; building can be long-running and writes generated code. Configure the mappings, report exactly what you changed, ask, and wait for a yes.
• STOP before creating any dictionary entry — do not write addEntry/set(entry,...) until the user provides the actual values (pragmas, storage classes, interface entries encode project intent).
• Link a shared Embedded Coder dictionary through EmbeddedCoderDictionary only, and only through model_edit (a configure op on config:<ModelName>). Never set DataDictionary to bring in a coder dictionary — it fails silently, leaving the model resolved to DataInterface. Do not reach for set_param/get_param on either parameter. See references/coder_dictionary.md.
• NEVER edit generated code — it is overwritten every build. All changes go to the model, code mappings, or dictionary.
• Do not manufacture configuration the user did not ask for. A Data Interface model builds from a default code interface with no code mapping object; create mappings only to override defaults.
• Configuring a parameter's storage class — pick the mechanism by where the parameter lives. Model workspace → always code mappings (setModelParameter), even on GRT; never set .StorageClass on the object. External parameter object (base workspace or data dictionary) → .StorageClass on the object; setModelParameter cannot address it. See references/code_mapping.md.
• Confirm any model-design or configuration change that a requested interface change depends on — before making it. Some code-interface configurations cannot be applied on the model as-is and require a prerequisite change to the model's design or configuration (for example, switching GRT→ERT for function mapping, deployment types, or Service Interface; requiring a fixed-step solver; converting to an export-function model). Such a change can alter or prevent code generation. Do not apply it silently — explain what the interface change requires, why, and wait for the user's yes.

Reference Files

• references/simulink-configure-code-interfaces.md — mode selection, per-mode workflows, deployment types, per-model mappings in a model-reference hierarchy, and the end-to-end "fresh model → generated code" spine
• references/code_mapping.md — coder.mapping.* API: storage-class mechanisms, port/state mapping, function naming/prototypes, silent-failure detection and verification patterns
• references/coder_dictionary.md — coder.dictionary.* API: creating/linking dictionaries, entries and their properties (getAvailableProperties), communication methods

---

Copyright 2026 The MathWorks, Inc.

---