9. QGen Constraints on Input Models

9.4. MATLAB

9.4.1. MATLAB .p and .mat Files

MATLAB .p and .mat files are not supported.

9.4.2. MATLAB Code for Parameters in .m Files and Block Parameters

9.4.2.1. Dimensions of data

Scalars, vectors and two-dimensional data (matrices) are supported. Data with more dimensions is not supported.

9.4.2.2. Accepted Constructs

Only constant definitions are are accepted in .m files. The supported format is:

<identifier> = [<data type> (] <value> [)];

where

<identifier> := <constant name>[.<structure element name>]
<value> := <literal value> | <expression>

Datastructures are defined implicitly by assigning values for each structure element. There is currently no way to attach explicitly defined data type to a constant.

Values can be composed of literal values, references to other constants and expressions including of arithmetic operators and supported functions (see section “MATLAB functions” below).

Annotation delimiter is “%”.

Examples

% Constant definition, implicit data type
MyIntParam = 15;

% Constant definition, explicit data type
MyDoubleParam = double (100);

% Array with explicit data type
MyArrParam = double ([1 2 3]);

% Definition of a constant structure
MyStructParam.Elem1 = 1;
MyStructParam.Elem2 = [1 2 3];
MyStructParam.Elem3 = MyIntParam;

% Expression using other constants
MyIntParam2 = int8 (MyIntParam + MyDoubleParam);

9.4.2.3. Type Definitions

  • Type definitions are not supported in parameter .m-files. However, QGen supports several ways of using custom data types. See Custom Data Types for further details.
  • The only exception is an implicit type definition of a structure (record) parameter. QGen infers the type definition from the instance definition in the parameter file. See MATLAB Code for Parameters in .m Files and Block Parameters.

9.4.3. MATLAB Operators

The following unary operators are supported:

+ - ~

The following binary operators are supported:

+ - * .* / ^ < <= > >= ~= | || & &&

9.4.4. MATLAB Functions

The following MATLAB functions are supported in both .m files and Simulink block parameters:

abs, acos, asin, atan, atan2, cos, cosh, exp, log, log10,
min, max, mod, rem, round, sign, sin, sinh, sqrt, tan, tanh, transpose.

Explicit typing/casting expressions are supported for:

int8, int16, int32, uint8, uint16, uint32, single, double, logical

In addition to numeric literals, the following literals are supported as well:

INF, NaN

9.4.5. MATLAB Expressions

Expressions containing the colon operator can only be used to get a slice of a vector (without increment value):

mySlice = myVector(3:8);

The following expressions are not supported:

  • Matrix partial indexing:
myMatrix(:,1);
myMatrix(1:3);
  • Creation of row vector:
MyVector = [10:20];
  • Vector slice with increment value:
mySlice = myVector(1:5:20);

In case there is a need for using such subarrays, then you should do the slicing in MATLAB and feed an appropriate subrarray to qgenc.

For instance when myMatrix is a two dimensional array and a model contains block parameter with value myMatrix (:,1) (i.e. the parameter is a vector containing the first column from matrix) then:

  • the original matrix is
myMatrix =   [1 2; 3 4];
  • create a vector variable myVector1 in MATLAB
myVector1 = myMatrix(:,1);
  • copy the vector value to the .m file that is given as an argument to qgenc
myVector1 = [1 3];
  • replace the expression “myMatrix(:,1)” in model with “myVector1”
  • assign to a structure in array:
myVector1(1,2).member = 1;

9.4.6. MATLAB cell arrays

Cell arrays in MATLAB workspace are not supported. qgen_export_workspace generates warning and array is not exported. When the array is referenced from Simulink model then code generation fails.

9.5. Stateflow chart modelling rules

The following modeling rules for Stateflow Charts are enforced.

9.5.1. Event broadcast for local events shall not to be used

Description: Stateflow event broadcast mechanism for Stateflow local events shall not to be used. Dataflow shall be used for controlling the chart’s mode instead.

Note: An exception is broadcasting external events, i.e. events that are received by other parts of the (Simulink) model than the broadcasting chart itself. Such events do not directly affect the behaviour of the chart. The only affect is changing global data. This kind of broadcasting is allowed. Typically the trigger type of the event/port is in such cases “function call”.

Justification: Some forms of event broadcast can lead to non-termination. Broadcasting an event in a transition action is one case that can never lead to non-termination by itself. In other cases static checks could be used to detect potentially looping behaviour.

9.5.2. Input and output events of the chart shall have a “function call” trigger type

Description: The trigger type property of input and output events of a chart shall have a “function call” trigger type.

Justification: This ensures the kind of timing of execution that is required by modelling/coding practices by some of the end-users. Output events with edge trigger type can create confusing models, because an event can be triggered several times in Stateflow, but is seen once or not at all in the Simulink part

9.5.3. [REMOVED]

This constraint was applicable up to version 2.1.2 of QGen. It was removed in version 17 and is no longer relevant in subsequent versions.

This section is preserved for traceability of constraints across different versions of QGen.

9.5.4. [REMOVED]

This constraint was applicable up to version 1.0.1 of QGen. It was removed in version 2.0.1 and is no longer relevant in subsequent versions.

This section is preserved for traceability of constraints across different versions of QGen.

9.5.5. Transition actions shall not be used in graphical functions and pure flow-graph decompositions. Condition actions shall be used instead.

Description: Transition actions shall not be used in graphical functions and pure flow-graph decompositions.

Note

This rule applies to pure flow-graphs only. It does not concern OR compositions of states, where transition actions are very appropriate.

Justification: This is a robustness constraint against effectively dead modelling constructs. Transition actions are meaningless in the above-mentioned cases since they are executed only when there is a transition from state to state (some versions of Stateflow allow to specify such actions, but they are never executed). In flow-graph networks condition actions should be used instead.

9.5.6. An OR decomposition must always have an unguarded default transition

Description: An OR decomposition must always have an unguarded default transition. Exception: An OR decomposition with only one substate can exist without a default transition. However, when any default transitions are present, then at least one must be unguarded.

Justification: If this condition is not satisfied then a run-time error due to state inconsistency can result, when a decomposition is entered, since it means that a system is in inconsistent state. When the decomposition consists of one substate only, then there is no need for the default transition. However, default transitions might exist, with different transitions specifying different actions. In the last case one of them must be without a guard to avoid confusion reading the model, as in Stateflow the state is nevertheless entered.

9.5.7. [REMOVED]

This constraint was applicable up to version 17.1 of QGen. It was removed in version 17.2 and is no longer relevant in subsequent versions.

This section is preserved for traceability of constraints across different versions of QGen.

9.5.8. Boxes shall only be used for grouping functions

Description: Boxes shall only be used for grouping functions.

Justification: Justification: Using boxes around states or flow-graph networks creates strange and complex scoping. The logical scoping for executing the chart’s sections and the name scopes introduced by boxes do not match. Boxes are fine for grouping graphical functions and truthtable functions.

9.5.9. Only bounded flow-graph loops should be used

Description: Flow-graph loops can cause non-termination of the chart’s execution. The loops should be designed with care and preferrably use a simple for-style pattern.

Note

This rule is currently not checked by QGen.

9.5.10. The transition arc shall not leave its logical parent’s boundary

Description: The transition arc shall not leave the boundary of the logical parent of the transition (the lowest common ancestor of the source and destination states).

Warning

Stateflow issues a warning about such transition arcs when simulating the model. This rule is not checked by QGen. In case such arcs exist the behaviour in Stateflow can have some side-effects that are not taken into account by QGen.

Justification: This is an error-prone pattern. The detailed semantics for such transitions is complicated and unintuitive. Identical or similar behaviour can be obtained by more clear and explicit constructs.

9.5.11. Super step semantics shall not be used

Description: The Stateflow super step semantics is not supported. This option should be turned off in charts supplied to QGen.

Warning

This rule is currently not checked by QGen. The behaviour of simulation and code generated by QGen can be different.

9.5.12. Variable-size arrays shall not be used

Description: The variable-size arrays in Stateflow are not supported. This option should be turned off in charts supplied to QGen.

Note

This rule is currently not checked by QGen.

9.5.13. Only C action language shall be used

Description: QGen does not support the MATLAB action language.

9.5.14. Moore charts shall not be used for breaking data loops

Description: It is possible in Simulink/Stateflow to use Moore charts for breaking causality of data feedback loops (algebraic loops). This is currently not supported in QGen.

If a Moore chart is used in a data feedback path make sure there is also some non-direct feedthrough block, such as Unit Delay on the same path.

9.5.15. Truth tables shall not be used

Description: Truth table functions are currently not supported by QGen. Similar functionality can be modelled with graphical functions.

9.5.17. History junctions shall not be used

Description: History junctions are not supported by QGen. Their use is also deprecated by the MISRA AC SLSF guide (rule 046) as it complicates interpretation of the model’s semantics.

The history can be modelled with an explicit local variable and transitions instead.

9.5.18. Temporal logic shall not be used

Description: The Stateflow temporal logic operators and events are currently not supported by QGen.

9.5.19. Change detection functions shall not be used

Description: The Stateflow change detection functions: ‘hasChanged’, ‘hasChangedFrom’ and ‘hasChangedTo’ are currently not supported by QGen.

9.5.20. ‘in <state>’ operator shall not be used

Description: The ‘in <state>’ operator is currently not supported by QGen.

9.5.21. Data stores shall only be accessed through chart’s I/O

Description: Defining or accessing data stores directly from Stateflow chart is not supported. If referring or modifying a value of a Data Store is needed in Stateflow, create resp. Data Store Read and Write blocks and connect them to the chart’s I/O.

9.6. Target Languages

9.6.1. Ada / SPARK

QGen generates Ada code compliant with the Ada 83, Ada 95, Ada 2005, Ada 2012 and SPARK 2014 standards.

Generated code might be non-compilable when the source of a Merge block is an atomic subsystem. This limitation will be fixed in a future QGen release.

9.6.2. MISRA-C

QGen generates C code compliant with the C89 ANSI standard and MISRA C:2012 guidelines.

9.7. XMI Support

The XMI importer has the following limitations:

  • The xsi:type of an object is specified using the fully qualified name:

    <?xml version="1.0" encoding="ASCII"?>
    <geneauto.emf.models.gacodemodel:GACodeModel ...>
       <elements xmi:type="geneauto.emf.models.gacodemodel:Module" ... />
    <geneauto.emf.models.gacodemodel:GACodeModel>
    
  • The xmi:id attribute is used to resolve references to elements and is always required for every node. XPath expressions are not (and will not be) supported. For example, the following XMI is acceptable:

    <expressions
        xmi:type="geneauto.emf.models.gacodemodel.expression:VariableExpression"
        xmi:id="830" ... variable="404"/>
      ...
      <variables
          xmi:type="geneauto.emf.models.common:Variable" xmi:id="404" ... />
    

    Where the variable attribute in the first node references the xmi:id of the second node.

  • If two features are one the eOpposite of the other, the values for both need to be included in the XMI file.

These limitations are not planned to be alleviated.