LI Modelling Rule Checks can be used directly from inside Simulink®'s Model Advisor™ or from m-script with results returned from the function call. Most rule checks can be custumised using configuration parameters to bet suit the needs of your company or project. All checks are at least compatible with release version R2010b and later.
LI Modelling Rule Checks are integrated to Model Advisor™, so once installed on your system successfully, opening the Model Advisor™ you should see an additional folder "LI MAB 5.0 Model Checks" on top level with subfolders for each of the standards check defining chapters for overall project and for Simulink®. Also in the "By Product" folder an additional subfolder of the same name should appear containing the flat list of the checks.
If you can't see the additional checks as described you might use Advisor.Manager.refresh_customizations or with less recent versions where this command is not available sl_refresh_customizations. Also check if the Matlab® path was set correctly.
For a step-by-step example to run a LI Modelling Rule Check see First Steps Using LI Modelling Rule Checks.
Most checks can be configured using check configuration parameters. To do so an m-script named lick_config.m must be present on the path exactly once. It must define a function with no input parameters and one output parameter, that is supposed to be a struct. Any struct member bearing the name of of a configuration parameter might be assigned in that function and will overrule the default.
The following example will overrule parameter bAllowMpSwitchEnum to allow enumerated signals of type Simulink.IntEnumType as control input for multiport switches and parameter bIterPosBtm to expect iterator blocks at the top of a diagram.
function sctCfg = lick_config() sctCfg = struct(); sctCfg.bAllowMpSwitchEnum = true; sctCfg.bIterPosBtm = false;
If you now run check jc_0630, the info section of the result will show your overriding value of parameter bAllowMpSwitchEnum and the check will be conducted respectively.
Take care to only use the pre-defined check configuration parameters and to use the type as described in the doumentation, otherwise check execution will stop with errors.
Checks can also be used from m-script directly. In the list of check implementation functions you will find many ending on _fetch. You can use these to run checks without Model Advisor™ according to the respective function documentation.
If you want to run check jc_0630 on a certain subsystem or model sSys, you must first compile the root system as desribed in the implementation functions documentation, and then hand in the respective handle or path string sSys and the rule string to the function implementing this check:
eval([sSys '([],[],[],''compile'')']); sctCkResMpSw = lick_cksigtypes_fetch(hSys, 'jc_0630'); eval([sSys '([],[],[],''term'')']);
After running all intended checks requiring compilation the respective system should be returned to its normal state using the term command. In this example the system to check is the root system itself for simplicity.
The returned structure sctCkResMpSw will contain two booleans and a HashSet, bAllowMpSwitchEnum, bAllowMpSwitchVecIdx and jExclLibs, that represent the check's configuration parameters used. The structure will also contain three ArrayLists jBadMpSwPams, jBadMpSwDatInCnt and jBadMpSwCtrlIn, where each contains all blocks offending the rules subid's a, b, and c respectively.
Most checks do not require compilation to be called from script, the implementation functions' documentation will tell you where to do so. Calls from Model Advisor™ are configured to handle respective checks automatically, anyway. So no special care is to be taken there, but all checks requiring compilation are marked by a leading ^ there.