Large engineering organizations in automotive, aerospace, and other industries can amplify the benefits of Model-Based Design by implementing modeling standards across their teams. High-integrity guidelines, including IEC 61508-3 and MISRA-C AC, strongly recommend the adoption and enforcement of modeling standards because of their numerous advantages. Models built with well-defined standards have a consistent visual presentation that makes them easier to read and understand. Such models have uniform interfaces, reducing integration problems and making it easier to share designs. Modeling standards also help ensure consistent code generation, model behavior, and traceability.

This article outlines best practices for adopting modeling standards and deploying them across an organization.

Establishing a Modeling Standards Team

The successful adoption of modeling guidelines, like any process, requires a core group responsible for managing each phase of the process and seeing the work through to completion. An extended team reviews the core team’s recommendations, gathers metrics on the deployment, and reports on experiences with the process, both positive and negative, so that issues can be identified and resolved.

The ideal core team has at least three members and includes individuals from each engineering group that uses Model-Based Design within the company. It is best to select individuals who have at least five years of experience with Model-Based Design.

Selecting Guidelines

Begin the adoption process by reviewing the existing guidelines for Model-Based Design. The primary industry sources are the bat365 Automotive Advisory Board (MAAB) Style Guidelines, the NASA Orion Guidelines, and the Simulink Modeling Guidelines for High-Integrity Systems. Guidelines covering efficient code generation, the design of high-integrity systems, and standards such as DO-178B and IEC 61508 (ISO 26262) are available on bat365.

While the MAAB guidelines were developed by an independent board of automotive OEMs and suppliers, companies outside the automotive industry use them to improve collaboration among internal teams and with partners.

The Orion Guidance, Navigation, and Control MATLAB and Simulink standards were developed by a team of NASA engineers and contractors who updated and expanded the MAAB guidelines as needed for the NASA Orion program. The MAAB Style Guidelines version 3.0 incorporates a subset of the original Orion rules. Simulink Modeling Guidelines for High-Integrity Systems were developed to help engineers create Simulink^® models that are complete, unambiguous, robust, and verifiable.

Customizing Guidelines

Once you have selected a basic set of guidelines, the next step is to modify and extend them to fit the specific needs of your organization. You can customize the MAAB guidelines by selecting specific implementations when the MAAB guideline provides options (as in rule NA_0005) or by adding specific detail when the rule provides general guidelines (for example, by specifying a compiler for rule NA_0026). Customization also involves defining basic standards, such as where labels should be displayed on signals (as covered by MAAB rule na_0005). In addition, your core team can create new rules to address workflow issues not addressed by the industry standard.

Deploying the Guidelines

It is best to deploy your custom modeling guidelines in phases, incorporating feedback from a subset of users before deploying the standards to larger groups, as follows:

Phase 1: Trial adoption. A group of approximately six to ten people begins applying guidelines to their models. This small group monitors how frequently guideline violations occur and reports any difficulties encountered in conforming to the guidelines. This phase typically lasts from one to three months.

Phase 2: Adjustment. Based on the feedback from Phase 1, the core team updates the guidelines. Updates can include rewriting guidelines to improve clarity, changing the priority, and delaying deployment of specific guidelines. This phase can be started as soon as initial feedback is available from Phase 1.

Phase 3: First targeted deployment. After adjustment, the guidelines are deployed to a larger group and used by that group throughout the project.

Phase 4: Project evaluation. At the completion of the first project (or after one year of deployment) the core team performs a post-mortem on the deployment process, analyzing the number and type of violations detected and commonly encountered issues.

In addition to following this phased deployment approach, the core team must obtain buy-in from end users. Acceptance is most likely when the end users see value in using the guidelines and when the guidelines impose minimal disturbance to their normal workflow.

Your team will be better able to obtain buy-in and minimize workflow disruptions if they take the following steps:

• Provide background information for each guideline that explains the problem that the guideline is designed to address.
• Provide automatic tools wherever possible to reduce or eliminate the burden of guideline checking for end users—the Model Advisor in Simulink can be used to automate the checking of built-in guidelines, and Simulink Check™ can be used for custom guidelines.
• Enforce guidelines only in the relevant stage of development—enforcement should be more lenient during initial development, becoming stricter as the code nears on-target deployment.
• Provide an exception mechanism for use when deviation from a guideline is unavoidable or necessary—for example, allow engineers to use the Model Advisor Exclusion Editor to exclude individual blocks from specific guideline checks (Figure 1).

Enforcing Conformance to Guidelines

Conformance to guidelines can be enforced using an automated checking tool such as the Model Advisor. Enforcement is generally most effective if your organization requires guideline checks as a gateway for certain tasks in the development workflow—for example, if engineers are required to check their models for compliance before they check the models into a configuration management system or generate code. You may decide to relax enforcement of certain guidelines during initial development, requiring engineers to follow those guidelines only in later development stages. Enforcement of some guidelines may be stricter for fixed-point projects or high-integrity projects and more relaxed for projects that involve legacy modules.

Reports are the primary mechanism for enforcing guidelines. Reporting serves an immediate purpose in providing feedback to the engineer (Figure 2), and a long-term benefit in enabling the core team to determine which guidelines are causing the most problems. On high-integrity projects, the reports may be checked into the configuration management system with the model and maintained as a development artifact.

Acquiring Feedback

Soliciting and responding to feedback is essential to the successful adoption of modeling standards. Ensure that your engineering team has a simple way to provide feedback from the project evaluation phase on. There is no need for a formal evaluation process; a simple email or web form is often sufficient. Ideally, the core team responds to all feedback, either by adjusting the guidelines or by clearly explaining why the guidelines were left unchanged. The process of acquiring and addressing feedback should be repeated periodically to ensure continued improvement and ongoing compliance.