Accelerating the pace of engineering and science

Accelerating Model Verification with Model Advisor

By Nishaat Vasi, MathWorks

As systems and software designs become more complex and design teams more geographically dispersed, there is an increasing need for consistent modeling. A different team is often responsible for each component in the system, and these teams may not be located in the same city, or even in the same country. Modeling standards enable geographically dispersed teams to collaborate effectively on the design of complex models. In addition, OEMs often require suppliers to use a particular modeling construct or terminology for algorithm development to ease model integration and certification. Finally, consistent modeling procedures help design teams comply with specific practices recommended in industry standards such as MAAB style guidelines, ISO 26262, IEC 61508, and DO-178C.

The Model Advisor in Simulink Verification and Validation supports modeling standards by analyzing a Simulink® model for inconsistencies and providing detailed recommendations for resolving issues. Even with automation, however, running these checks on large systems can take considerable processing time and effort. For example, to ensure that the model components fit well together, an organization may require every subsystem to pass a specific set of Model Advisor checks. If one subsystem fails a check, work on the other components may be halted as well.

One solution is to limit the scope of the Model Advisor analysis to certain elements of the model. Using an automobile system model as an example, this article shows how the exclusion and highlighting functionality within Simulink Verification and Validation can reduce the time taken to analyze and fix inconsistencies in models.

Running Checks on an Automobile System Model

Let’s say we are developing a Simulink model of a car that includes subsystems for transmission control, engine, and gear shifting logic (Figure 1). Our team is responsible for designing and testing the gear-shift algorithm. The teams responsible for the other components are located in separate cities. Each team has access to the complete system model.

Figure 1. Automobile system model.
Figure 1. Automobile system model.

We have modified our shift_logic Stateflow® chart, and want to submit the changes to the central repository. Using Model Advisor we run modeling standards checks on the entire sf_car_demo model. Model Advisor returns a warning: “The following discrete controllers contain prohibited blocks: sf_car_demo/vehicle/wheel_speed” (Figure 2).

Figure 2. Model Advisor report with warning message.
Figure 2. Model Advisor report with warning message.

Having a warning message in the report prohibits us from submitting our modifications to the central repository, and forces us to investigate further. The warning points to a block within the Vehicle subsystem, but since we do not have write-access, we cannot modify this component. On one hand, we may have unearthed a serious design issue. On the other, the designers of the Vehicle subsystem might have included this functionality intentionally, as part of a requirement. If the errant block is a requirement, we could continue working on the error-free components if we exclude the errant block from our Model Advisor analysis. Model Advisor would then generate a report that is free of warning messages.

Using the exclusion capability in Model Advisor we can do this in three steps:

  1. Select blocks for exclusion
  2. Capture the rationale for exclusion
  3. Rerun the analysis

Selecting Blocks for Exclusion

To select the model element or subsystem that we want to exclude, we right-click sf_car_demo/Vehicle/wheel_speed and select the option to exclude this particular block from all Model Advisor checks (Figure 3). Model Advisor also gives us the option to define the scope of the exclusions.

Figure 3. Selecting model elements to exclude from Model Advisor analysis.
Figure 3. Selecting model elements to exclude from Model Advisor analysis.

Capturing the Rationale for Exclusion

We define the scope and operation of the exclusion and explain the rationale for the exclusion within the Model Exclusion Editor (Figure 4). The rationale will be copied into the automatically generated Model Advisor report. The exclusions are stored in an XML file (in our example sf_car_demo_exclusions.xml), and remain associated with the relevant model. We have the option to change the name and location of the XML file in the Exclusion Editor.

Figure 4. Model Advisor Exclusion Editor.
Figure 4. Model Advisor Exclusion Editor.

Rerunning the Analysis and Highlighting the Results

On rerunning the Model Advisor analysis, we find that the Integrator block "wheel speed" is highlighted in gray, indicating that it is excluded from the analysis. With Model Advisor we can highlight the analysis results on the model, giving us a model-centric view of how blocks, charts, subsystems, and other model elements performed in the checks. The Model Advisor reports the fact that the Integrator block "wheel speed" was excluded from the analysis (Figure 5). Since the report now contains zero warnings, we can submit the model to the repository.

Figure 5. Model Advisor analysis results.
Figure 5. Model Advisor analysis results.

Extending Exclusions to Other Workflows

The Model Advisor exclusion capability saves time that would be spent on sorting out known issues, and further promotes a component-based workflow. In our example we excluded a single block, but there is no limit to the number of elements that you can exclude from the Model Advisor run. An immediate benefit is faster analysis time, with verification effort focused on the Simulink and Stateflow model components most relevant to your team. Another benefit is shorter compilation time for large models. Generally, the more complex the model, the longer it will take to compile. Having the ability to selectively check parts of the model can lead to faster execution of the Model Advisor analysis engine. An additional benefit is the ability to exclude protected intellectual property, such as a plant model developed by an external vendor. If a protected model failed the analysis, the in-house design teams would be unable to fix the problem. With that model excluded from the analysis, they can continue working on the relevant system components.

Published 2013 - 92073v00

Start a new search