What causes this error:
This error indicates that there are two objects in the model that match in a way that, given the way the model is configured, will generate invalid code due to clashing identifiers. This happens as names for elements in the Simulink model may become their identifiers in generated code. For example, if you have two "Simulink.Parameter" objects that would have the same name in the generated code, Simulink will throw the error "potential conflicting usages of identifier" when generating code.
Context to Consider:
In order to approach resolving these kinds of error, identify which elements need to have user-defined naming (e.g., data type, signal, etc.) and where they need user-defined naming (i.e., in the Simulink model or the generated code). For example, one may want to name a Simulink.Signal object for modeling purposes without the need for the corresponding variable in generated code to share the same name, or vice versa.
Also consider other needs in terms of how signals, types, etc. need to appear in generated code. For example, if one needs outports to appear with storage class ExportedGlobal, name mangling cannot create unique identifiers for these outports, so another solution must be considered.
Potential Solutions:
Allow for "name mangling" in generated code:
Name mangling is a process where Embedded Coder appends unique characters to the end of variable names to make them unique. This is a good option if the model needs to have user-specified naming but the generated code can have different naming. However, this does not support non-auto/default storage classes. For more information about name mangling, see "Avoid Identifier Naming Collisions":
https://www.mathworks.com/help/releases/R2023b/ecoder/ug/avoid-identifier-naming-collisions.html
There are ways that name mangling can be disabled, such as if a non-auto or non-default storage class is assigned. If name mangling isn't appearing as expected, confirm that the elements in question have a "Default" or "auto" storage class and that mangling is configured correctly within Configuration Parameters per the documentation link provided above.
Rename elements that are creating the naming conflict in Simulink.
If elements in Simulink are given unique names, it is unlikely that the identifiers in generated code will have conflicts.
Give a unique identifier (also called "alias" in older releases) to the element with the naming conflict:
Specifying a unique identifier provides fine control over the identifier of individual elements when using non-auto storage classes but may be impractical for large models. This will override any mangling, and Simulink will attempt to generate code with the specified identifier. The exact workflow will depend on what is being named in a model, the target language, and from what release this is being done. For example, a "Simulink.Signal" in R2022b may be assigned a user-specified identifier in generated code by using the Code Mappings Editor and opening the Signals tab. From there, select the "Simulink.Signal" of interest and click on the pencil icon to assign an identifier. For more information about the Code Mappings Editor, see the documentation for "Code Mappings Editor - C":
https://www.mathworks.com/help/releases/R2023b/rtw/ref/codemappingseditorc.html#responsive_offcanvas
