The ParameterID is a toolbox to identify common permanent magnet synchronous motor parameters based on different code-generated Stateflows. This page explains the general structure of the ParameterID. To set the ParameterID up in the UltraZohm software, see Setup and functions of the ParameterID. For further information visit, Structs for ParameterID_Data, Change control algorithm for ParameterID, Custom uz_GUI for ParameterID and Guide to create a new ID-state.


Figure made with TikZ

Fig. 60 Schematic overview of the ParameterID signal flow

The ParameterID encapsulates a ControlState and all subsequent Identification-states (short ID-states). The ControlState is the brain of the ParameterID and controls the system by determining which ID-state is entered next, based on the user-request and the acknowledgment flags of other states. The individual ID-states are completely independent of each other. They only directly communicate with the ControlState. The uz_ParameterID_Data_t struct is used to communicate with the ParameterID. It includes all necessary in- and outputs. The ParameterID operates independently of an underlying control algorithm and therefore is indifferent to what specific type the controller is. This means that the ParameterID outputs reference values, which the controller can use to control the hardware. On top of that, the ID-states inside the ParameterID are separated into two different groups:

  • OfflineID states

    OfflineID states represent identification Stateflows, which are to be used before the general operation of the motor is started. They can not be executed parallel to the general motor operation because they take active control of the machine. They, for example, tell the external control algorithm which reference currents or speeds it is supposed to target. Thus only one OfflineID-state can be active at the same time.

  • OnlineID states

    OnlineID states represent identification Stateflows, which are used during the general operation of the motor. They are designed as an observer of some sorts of the machine. This means they use all existing measurements during normal operation and identify their parameters this way. They, therefore, don’t have to actively control the machine. Thus, they can operate parallel to the general operation of the motor.


All states have been configured in such a way that they are independent of the sampleTime. This works if the sampleTimeISR member of the Global config struct equals the sampleTime of the function call. This has been confirmed for an ISR-frequency of 10kHz and 20kHz.

Signalflow in the ParameterID

Figure made with TikZ

Fig. 61 Schematic overview of the ParameterID

The ParameterID has three global structs (highlighted in orange), which are shared inputs for all identification states. For detailed information about these structs, click on the appropriate hyperlink. These are the following:

On top of that, each unique ID-state has its own individual structs and signals:

  • uz_StateIDConfig_t (i.e. for ElectricalID uz_ElectricalIDConfig_t), which is meant for all configuration values, which are unique to this specific ID-state.

  • uz_StateID_state_output_t (i.e. for ElectricalID uz_ElectricalID_state_output_t), which is meant for the identified output variables and supporting variables.

  • enteredStateID flag for OfflineID- and OnlineID-states, which signals that the state has been entered.

  • finishedStateID flag for OfflineID-states, which signals that the ID-state is finished and another can be started.

OnlineID-states do not necessarily have a finishedStateID flag, since they can be designed as an infinite loop.

Further information

General information & explanation

Further documentation which explains the structure of the ParameterID in detail.


Listed are the individual states which are part of the ParameterID.