Documentation

Modeling Style

hisl_0061: Unique identifiers for clarity

ID: Titlehisl_0061: Unique identifiers for clarity
DescriptionWhen developing a model:
AUse unique identifiers for Simulink® signals.
BDefine unique identifiers across multiple scopes within a chart.
NotesThe code generator resolves conflicts between identifiers so that symbols in the generated code are unique. The process is called name mangling.
RationaleA, BImprove readability of a graphical model and mapping between identifiers in the model and generated code.
References
  • MISRA-C: 2004 5.6

  • DO-331, Section MB.6.3.2.b 'Low-level requirements are accurate and consistent'

  • IEC 61508–3, Table A.3 (3) 'Language subset'
    IEC 61508–3, Table A.4 (5) 'Design and coding standards'

  • ISO 26262-6, Table 1 (b) 'Use of language subsets'
    ISO 26262-6, Table 1 (e) 'Use of established design principles'
    ISO 26262-6, Table 1 (h) 'Use of naming conventions'

  • EN 50128, Table A.4 (11) 'Language Subset'
    EN 50128, Table A.12 (1) 'Coding Standard'

Model Advisor Check
  • By Task > Modeling Standards for DO-178C/DO-331 > Check Stateflow charts for uniquely defined data objects

  • By Task > Modeling Standards for IEC 61508 > Check usage of Stateflow constructs

  • By Task > Modeling Standards for ISO 26262 > Check usage of Stateflow constructs

  • By Task > Modeling Standards for EN 50128 > Check usage of Stateflow constructs

For DO-178C/DO-331 check details, see Check Stateflow charts for uniquely defined data objects.

For IEC 61508, EN 50128 and ISO 26262 check details, see Check usage of Stateflow constructs.

See AlsoCode Appearance in the Simulink Coder™ documentation
Last ChangedR2015a
Examples

Not Recommended

In the following example, two states Scope_1 and Scope_2 use local identifier IntCounter.

The identifier IntCounter is defined for two states, Scope_1 and Scope_2.

Recommended

To clarify the model, create unique identifiers. In the following example, state Scope_1 uses local identifier IntCounter_Scope_1. State Scope_2 uses local identifier IntCounter_Scope_2.

The identifier IntCounter_Scope_1 is defined for state Scope_1. Identifier IntCounter_Scope_2 is defined for Scope_2.

hisl_0062: Global variables in graphical functions

ID: Titlehisl_0062: Global variables in graphical functions
Description

For data with a global scope used in a function, do not use the data in the calling expression if a value is assigned to the data in that function.

RationaleEnhance readability of a model by removing ambiguity in the values of global variables.
References
  • IEC 61508–3, Table A.3 (3) 'Language subset'
    IEC 61508–3, Table A.4 (4) 'Modular approach'
    IEC 61508–3, A.4 (5) 'Design and coding standards'

  • ISO 26262-6, Table 1 (b) 'Use of language subsets'
    ISO 26262-6, Table 1 (f) 'Use of unambiguous graphical representation'
    ISO 26262-6, Table 1 (h) 'Use of naming conventions'

  • EN 50128, Table A.4 (11) 'Language Subset'
    EN 50128, Table A.12 (1) 'Coding Standard'
    EN 50128, Table A.12 (2) 'Coding Style Guide'

  • DO-331, Section MB.6.3.2.g 'Algorithms are accurate'

  • MISRA-C:2004 12.2
    MISRA-C:2004 12.4

Last ChangedR2015a
Examples

Consider a graphical function graphicalFunction that modifies the global data G.

Recommended

Not Recommended

hisl_0063: Length of user-defined function names to improve MISRA-C:2004 compliance

ID: Titlehisl_0063: Length of user-defined function names to improve MISRA-C:2004 compliance
DescriptionTo improve MISRA-C:2004 compliance of the generated code when working with Subsystem blocks with the block parameter Function name options set to User specified:
A

Limit the length of data object names to 31 characters or fewer.

For this rule, Subsystem blocks include standard Simulink Subsystems, MATLAB® Function blocks, and Stateflow® blocks.
RationaleAFunction names longer than 31 characters might result in a MISRA-C:2004 violation.
References
  • MISRA-C:2004 Rule 5.1

Prerequisiteshisl_0060: Configuration parameters that improve MISRA-C:2004 compliance
Last ChangedR2011a

hisl_0064: Length of user-defined type object names to improve MISRA-C:2004 compliance

ID: Titlehisl_0064: Length of user-defined type object names to improve MISRA-C:2004 compliance
DescriptionTo improve MISRA-C:2004 compliance of the generated code, limit the length of data object names to 31 characters or fewer for:
  • Simulink.AliasType

  • Simulink.NumericType

  • Simulink.Variant

  • Simulink.Bus

  • Simulink.BusElement

  • Simulink.IntEnumType

RationaleThe length of the type definitions in the generated code name might result in a MISRA-C:2004 violation.
References
  • MISRA-C:2004 Rule 5.1

Prerequisiteshisl_0060: Configuration parameters that improve MISRA-C:2004 compliance
Last ChangedR2011a

hisl_0065: Length of signal and parameter names to improve MISRA-C:2004 compliance

ID: Titlehisl_0065: Length of signal and parameter names to improve MISRA-C:2004 compliance
DescriptionTo improve MISRA-C:2004 compliance of the generated code, limit the length of signal and parameter names to 31 characters or fewer when using any of the following storage classes:
  • Exported global

  • Imported Extern

  • Imported Extern Pointer

  • Custom storage class

RationaleThe length of the signal and parameter name might result in a MISRA-C:2004 violation.
References
  • MISRA-C:2004 Rule 5.1

Prerequisiteshisl_0060: Configuration parameters that improve MISRA-C:2004 compliance
Last ChangedR2011a

hisl_0201: Define reserved keywords to improve MISRA-C:2004 compliance

ID: Titlehisl_0201: Define reserved keywords to improve MISRA-C:2004 compliance
DescriptionTo improve MISRA-C: 2004 compliance of the generated code, define reserved keywords to prevent identifier clashes within the project namespace.
AIn the Configuration Parameters dialog box, on the Simulation Target > Symbols > Reserved names pane, define reserved identifiers.
BUse a consistent set of reserved identifiers for all models.
Notes

Simulink Coder checks models for standard C language key words. Expand the list of reserved identifiers to include project specific identifiers. Examples include target-specific clashes, standard and custom library clashes, and other identified clashes.

RationaleImprove MISRA-C:2004 compliance of the generated code.
See Also
References

MISRA-C:2004, Rule 20.2

Last ChangedR2011b

hisl_0202: Use of data conversion blocks to improve MISRA-C:2004 compliance

ID: Titlehisl_0202: Use of data conversion blocks to improve MISRA-C:2004 compliance
Description

To improve MISRA-C:2004 compliance of generated code, insert a data type conversion block when using signals of type single (real32_T) as inputs to the following blocks:

  • Math

  • Trigonometry

  • Sqrt

The data type conversion block to changes the data type to double (real_T)

RationaleImprove MISRA-C:2004 compliance of the generated code.
Notes

The function prototypes for many math functions require an input of type double. To accommodate the function prototype, you can add a data type conversion block. As an alternative to the data type conversion block, you could define a new function interface using the Target Function Library (TFL).

References
  • MISRA-C: 2004 Rule 10.2

Last ChangedR2012a
Example

Recommended

Add a data type conversion block to the input signal of the block. Convert the output signal back to single.

Was this topic helpful?