It is important that you consider the following when applying modeling guidelines to a project:
Model design specification should be defined prior to reviewing the guidelines. Doing so makes the process of determining which guidelines to apply and the implementation of the guidelines more efficient.
For example, the analysis of a simple model can use function
sldiagnostics to investigate how often a specific block is used. Adjust the
operation rules list by specifying blocks that are frequently used and those that are not.
Furthermore, reusability at a later stage is improved by adding rules that:
Unify description styles
Anticipate in advance the man-hours needed to correct models
Measuring tendencies, such as where to place blocks that have feedback status variables (Unit Delay block), whether the Unit Delay block should be inside or outside the subsystem, or whether the Abs block should be set on the output side of the subsystem, and if it should process at the input side after receiving a signal.
At the start of the project, it should be determined which guidelines apply to each development process. The guidelines should be evaluated and applied so that they correspond with the development process. Considerations may include questions such as:
Will the guideline be applied only at the code generation stage?
Will the adopted guideline rule change for each process stage?
The field to which the guidelines apply must be determined. For example, guidelines can be:
Limited to a model that represents the AUTOSAR field of application
Applied to a general software field, such as where models implement interrupts (add processes that prohibit interruption during calculation).
Specific to fields where general engineers edit the models. The intention of these rules is to ensure that the models are easily understandable in those fields.
Specialized fields can be excluded from the constraints of these guidelines by limiting the scope and applying unique set of guidelines that are specific in this environment.
Specialized fields, such as those where modelers design custom library blocks, are not typically targeted by these guidelines.
Furthermore, when having a control model that is operated with Rapid Control Prototyping (RCP) , the entire model should not be set as a target; instead, the field needs to be limited. It is necessary to generate the code and review the areas that are implemented in the built-in microcomputer as well as the areas that are not. These guidelines do not apply to control models such as those scheduler models that are made solely for RCP and are not implemented, or for interface sections with blocks that correspond to drivers such as CAN and PWM signals for operating actual machines.
Guidelines should not be adopted as they are written without further evaluation.
Implementation of guideline rules and parameter recommendations should be evaluated to determine the impact on the project and the development processes being used. In addition, consideration needs to be taken as to the effect on other guidelines and how applying custom parameters can affect simulation or code generation.
At the beginning of a project, it is important to determine how and when the project will be evaluated to ensure adherence to the guidelines.
The decision whether to use an automated checking mechanism (third part or internal) or perform manual checks is very important. Also, the stage at which the checks occur, as well as developing a system for revising the check rule criteria, is important.
Automated checking can significantly reduce the time required for review. It is recommended that an additional, manual review also be performed by a skilled person, even if everything can be checked automatically.
The decision to apply a guideline or a rule can change. When doing so, it is important to specify a process and procedure for determine the root cause of the request and evaluate the potential impact the change can have on the project and the organization.
When evaluating the change request, first listen to the needs of the modeler and determine the root cause of the request. When the request is based on the user not understanding block usage or a guideline rule, training should occur instead of revising the rule.
The procedure to relax the rules as needed should be implemented when there are restrictions due to company objectives and control specifications or hardware (such as microcomputers).