标签: 基于模型的开发

前言 在汽车与自动化行业，基于模型的开发过程中，从业者希望能够在保证建模效率的同时确保模型质量。此时，合理使用建模工具变得尤为重要。合适的工具不仅能够通过建模规范检查分析测试模型的质量，还能根据分析结果对模型进行自动改进。本篇文章为您介绍广受业界认可的静态测试工具MES Model Examiner® (MXAM) 。从MXAM在静态测试中的应用角色到实际演示与10.0版本功能更新，本文带您透彻了解MXAM如何能轻松帮助您实现优质建模。 基于模型的开发中静态测试的应用与MXAM MXAM是用于对Simulink®、Stateflow®、Embedded Coder®和TargetLink®模型进行全面静态分析的专业工具，主要应用于软件V型开发流程的左侧设计阶段，覆盖从架构到单元设计和实现的全过程。 基于模型的开发(MBD)依赖基于需求的，测试驱动的工作流来持续地确保质量。软件V型开发流程由左侧的设计阶段和右侧的测试阶段组成。功能质 量和功能的适用性是右侧测试阶段的主题，而设计的适用性和设计质量则是设计阶段关注的重点。设计质量和功能质量同样重要，因为模型设计的适用性能够有效促进功能的适用性。 那么，模型设计质量应如何保证? 模型静态测试能够帮助工程师保证模型设计的适用性：不仅可以改进已在开发过程中的模型，还可以通过质量保证前置帮助模型在代码生成前确保质量,生成代码的质量得以有效提升。 实际应用中，MXAM支持高度自动化的静态分析并致力于Simulink和TargetLink模型的可读性，鲁棒性，避免模型错误以及改进生成代码。 图1是一个Simulink模型的次级子系统。可以看出，模型目前存在违背建模规范的多项错误。例如第1处，模块命名应位于模块下方，而不是上方。再比如第2处，对于常值模块而言，其命名不应使用具体的、非0和1的数字，而应当设置为参数进行表示。对于模型的可读性来说，图1的信号流未对齐（第3处）。模块的命名应当被清晰识别，而第4处显然不符合建模规范的相关要求。第5处的输入端口隐藏在了系统布局内。此外，出于避免模型错误的出现，第6处的乘积模块不应存在超过两个输入端口…等等，这些问题严重影响了该Simulink模型的可读性和设计质量。图2展示了该模型经过MXAM修改优化后的结果：所有在之前讨论过的错误都被一一准确修正，模型的可读性得到了显著提升。 由此可见，评估模型的建模规范合规性在保证模型质量的实际应用中至关重要。此环节主要评估模型的布局，数据和控制流，数据类型，及其配置情况。模型的布局要求确保模型元素之间的关系和连接方式符合设计规范。模型的数据和控制流要求检验可能的逻辑错误及路径偏差。模型中的数据类型定义必须正确且一致。模型的配置情况则要求模型的配置参数符合设计规范。 这样的评估需要遵循相关的模型设计原则或标准，例如MISRA，MATLAB Simulink，或相应建模规范文件等等，设计原则的具体应用主要通过对根据相应规范而设置的模型指标的检验评估实现。例如汽车功能安全行业标准ISO 26262 – 6: 软件级别产品开发中对汽车软件架构所提出的具体建议和原则。其中，模型的复杂度，大小，和非相干度是检验模型是否符合相应建模规范的重要指标。模型的复杂度分析旨在发现模型中可能导致问题的复杂结构或关系，及时优化并简化模型，确保模型合规。模型的大小意在评估模型子系统，接口等等的规模，确保模型的可理解性和可维护性。模型的非相干度要求减少模型中的非相干性，以此确保模型各部分之间的关联适度。 模型指标的检验分析可以通过静态测试的方式在模型开发中及早实现，提高模型的质量，并保证软件系统运行的稳定性和安全性。在模型开发过程的敏捷工作流中，建立模型之后，根据建模规范或行业标准的要求分析模型指标，再生成清晰且全面的分析报告，并根据报告结果对模型进行修复，最终实现并输出优质的模型。 在模型开发过程中执行静态测试，可通过敏捷工作流实现。如图3所示，敏捷工作流中，首先建立模型，再根据业界标准和建模规范进行模型分析，得出清晰全面的分析报告，最后根据分析报告的结论快速解决和修复模型遇到的问题，最后实现质量门的通过，轻松实现优质建模。在这一过程当中，MXAM和MoRe (MES Model & Refactor® (MoRe), 现已集成在MXAM中) 两大工具，分别在敏捷工作流的不同阶段为建模工作提供有力支持。 图3：MXAM与MoRe为模型开发过程中敏捷工作流的不同阶段提供支持 通过启动模型分析，MXAM可以向用户展示模型根据建模规范一致性的分析结果报告，如图4所示的分析结果视图。 图4：MXAM分析结果视图 从展示形式来说，如图5所示，MXAM中的报告视图可展示为不同的导览方式，如规范文档导览(Document Navigation)和模型工件导览(Artificial Navigation)。规范文档形式下，在报告和文档的每个级别都显示聚合的分析结果：模型名称、分析完成的时间。在工具栏中，还可以通过选择树查看分析结果。工件导览是以模型结构树的形式显示相应系统或子系统对应的模型聚合分析结果。 图5. MXAM报告视图的不同导览方式 内容而言，图6显示了模型的合规报告视图右侧显示了模型的合规分析结果列表(Findings)，模型架构分析的相应指标(Metrics)，模型合规性的注释列表(Annotations)，模型分析的配置详情(Analysis Configuration)和模型分析指标的摘要(Metrics Summary)。 图6. MXAM合规分析结果 用户还可以通过菜单(Menu)或过滤选项(filter)选择并查看相应的分析结果。分析结果的详细信息可以在详情结果视图(Finding Details)查看。如图7所示，用户可以查看到违反相关建模规范的详细信息和结果描述。 图7. MXAM违规项的详细信息 比如出现错误的具体路径(Path)和具体模块(Name)，和出现这条错误报告的具体原因。用户可以通过路径及模块名称上的超链接直接到达模型中该错误所在的位置。修复选择(Repair Finding)可以帮助用户一键修复错误。 对于建模规范来说，此处以建模规范mcheck_misra_slsf_030_c为例，在详情页中(如图8所示)可以找到关于这一建模规范的详细描述，包括检查项通过该建模规范或不通过的评判标准(Pass-Fail Criteria)，以及相应的解决方案(Solution)和修复的具体描述(Repair Action)。 最终的检查报告可以HTML-、 PDF-、 EXCEL-、XML-以及MXAM自带的mxmr格式快速导出。 图8. MXAM建模规范详情页 MXAM v10.0: MoRe的集成与功能升级 MoRe现已成为MXAM的一部分。 在前文中已提到，MXAM能够在模型敏捷开发流程的多个阶段提供强有力的支持:加速模型分析流程，快速生成报告，并辅助自动修复。同样来自MES模赛思的MATLAB Simulink扩展建模辅助工具MES Model & Refactor® (MoRe)能够为敏捷开发流程中的建模和修复提供高效帮助。 MoRe能将您日常建模中的步骤自动化，省去大量重复单调的操作，帮助您在建模时专注于重要步骤，节约时间，全面提高工作效率。现在，在MXAM全新版本v10.0之下， MoRe已集成在MXAM中。MXAM的功能变得更为全面，全力支持您基于模型的开发过程。 如图9所示，这是普通的MXAM安装程序。用户可以在此处选择许可证文件，而MoRe的标志已在此标注。接下来用户可以继续正常的下载步骤，MoRe的下载会自动随MXAM同步进行。 图9. MoRe的安装已集成在MXAM下载器中 进入MATLAB界面后，MXAM和MoRe即可马上使用。如图10中的Simulink 模型所示，"MES MoRe"选项已经显示在菜单中，可以直接调用MoRe的相关功能。 图10. MoRe的轻松调用 MoRe最新版本的所有功能均包含在内，集成在MXAM中和MoRe独立工具使用的体验相同。不仅是自动布局，MoRe同样可以从多角度帮助模型进行快速优化。不论是从将Goto/From模块转换为信号线，或是命名问题， MoRe都可以辅助您改进模型，并节约大量时间。 新增可选扩展全局参数及建模规范。 新版本中，MXAM 对Embedded Coder AUTOSAR运行实体中的参数进行了扩展。在使用Embedded Coder进行模型开发时，如果静态测试包括了自动生成的模型部分，则会导致大量的时间和资源浪费。MXAM v10.0对分析参数进行了扩展（见图11）。如果将此参数设置为“True“，那么MXAM只会对运行实体子系统中的模型元素进行分析。 图11：MXAM v10.0新增参数: "Global.AnalyzeAutosarRunnablesSubsystemsOnly" 在开发AUTOSAR模型的过程中，工程师一般通过ARXML文件开始进行模型生成和框架的构建，因而模型会自动生成很多层级以及其他文件。而模型的自动生成部分并非必须进行静态测试，因其必须遵循AUTOSAR提供给您的内容，模型结构固定，对固定部分进行静态测测试会耗费大量不必要的时间和精力。这个新的全局参数能够帮助工程师实现只分析 AUTOSAR运行实体中的模型和函数，这样开发工程师就可以将模型分析专注于实际应用和可以进行更新修改的模型部分，从而节约大量时间。 而对于建模规范而言， MXAM新版本的更新完全围绕主题“ 功能安全 “展开。 建模规范mes_slsf_1500: 确保可重用模型组件具有已解析并启用的链接。本建模规范完全专注于功能安全。在工程师应对可重用模型组件时，应当确保所有链接已解析，如果其中有尚未解析的链接，将模块用未启用的链接进行连接可能会导致潜在的问题。使用本建模规范可以确保模型引用可用且已更新，同时提高了可测试性，确保模型在进入下一个质量保证阶段前一切就绪。 另一项更新来自mes_slsf_2200: 避免舍入模式(Rounding Mode)。绝大多数 Simulink中的计算模块都可以设置特定的舍入模式。此时，确保代码生成的舍入模式都被明确定义十分重要。本建模规范能够避免模型将舍入模式设置为“Simplest”，并且对应的MES检查项中也有对应的检查参数可供使用。 本次更新还包括建模规范mes_slsf_3500: 禁止在Stateflow图中使用用户定义的事件。基于事件的建模可能会导致模型难以维护，出现隐藏控制流和可能的无限递归。同步问题也可能发生，且Stateflow的早期返回逻辑可能导致不良后果。此建模规范可确保模型不会在Stateflow图中使用用户定义的事件，从而防止隐藏控制流出现在模型之中。 除此之外，新版本还添加了对三个版本的TargetLink用户的相应变量类别和全新的MES检查。 如您想了解并体验MXAM v10.0全新版本，欢迎您申请免费试用，了解更多。

在基于模型的开发中，优质的模型架构是生成优质代码的必要前提。静态模型分析对于模型的质量保证有着至关重要的作用，同时建模规范已在业内有着广泛而成熟的应用。然而建模规范并非模型设计原则合规性的唯一考量标准，仍有许多方面，需要根据具体的模型属性加以改善。模型结构质量作为反映建模质量的重要方面，可通过一系列模型指标（ Model metrics ）对模型结构质量进行综合分析。本文我们将向您展示模型指标的概念、原理、方法、模型指标应用和模型重构的最佳实践，并向您展示这些操作具体如何提高模型结构质量。 什么是结构质量 首先来看模型质量的概念。在基于模型的开发（ M BD ）中主要考虑模型软件质量保证问题。 ISO26262 中关于软件产品开发的参考阶段给出相应设计原则、软件设计和验证的规范要求。按照 ISO 26262 中软件开发的 V 模型（如 图 1 ），各阶段涉及不同的主题活动，从安全需求到软件架构设计、软件单元设计和实现，以及软件单元验证、软件集成和验证，到嵌入式软件系统的验证。这个开发过程分为两个阶段：在 V 模型的 左侧，按照软件需求，我们设计 构建 模型；在 V 模型的 右侧，在相应阶段验证我们的模型或软件是否按预期的需求和架构设计工作。与此同时，此 V 模型 同步 涉及 质量保证活动的各个阶段。一方面我们关注模型的结构质量，另外一方面考虑模型的功能质量。结构质量方面我们 关注模型 结构质量相关属性或设计的适用性，分析模型结构相应于设计的适用性，考虑设计能否适用于实现软件的需求。功能质量方面我们注重功能质量，验证软件的功能是否 符合模型设计，并能够按照需求 正确运行。 图 1 . 软件开发与软件质量活动流程 那究竟什么是结构质量呢？ 首先让我们来谈谈模型的结构属性。结构属性反映软件设计在多大程度上适用于需求？设计属性的符合程度如何？根据 ISO26262 关于质量保证的典型设计特征和特性描述，设计或实现的目标要达到的目标包括一致性、简单性、可理解性和可读性、模块化和封装性、修改的适用性、设计的鲁棒性、可验证性、可测试性和可维护性。 因此，典型设计特征首先从软件架构看要实现软件单元接口的一致性。其次，设计要容易理解和审查。例如，设计的模块化程度如何？设计的修改方便吗？设计是否足够稳健？是否应用了行业最佳实践或范式进行建模？这样的设计方便测试吗？这样的设计后期方便维护吗？ 为了实现这些属性，参考 ISO26262- 6 在软件设计和实现的设计原则建议，事实上对应标准中的三个表格，这三个表格专注于设计建议和结构质量条款，分别是表一，表三和表六，包括建模和编码指南应该涵盖的主题，软件架构设计的原则，软件单元设计和实现的设计原则。这些原则主要通过静态分析和在基于模型的开发中应用建模指南来实现。与此同时，我们可以从软件架构设计原则中得到一些具体的操作建议，比如软件设计原则中提到的低复杂度执行，限制 组件大小 ，组件的强内聚性，组件间的松散耦合等等。对于这些建议的实施，首先我们需要详细了解相关的模型属性，而对于这一点，模型指标可以为我们提供关于模型属性的详细信息。 结构质量相关模型指标 既然模型指标可以表示软件模型的相关质量属性，让我们先了解一下模型指标具体包含哪些指标，如何反映模型的结构质量。 通常，指标是软件模型具有某些属性的程度的度量（对于模型度量也是如此）。因此，我们通过度量来评估模型的某些属性，然后将这些属性映射到某些具体的数值，帮助我们建立对该属性客观的认识和理解。模型指标的示例包括模型的复杂度、组件大小、模型的非内聚度、功能组件的比例、接口大小以及克隆组的使用等等。 接下来，我们来详细地介绍这些具体的模型指标，并对各项模型指标给出合理的解释，各模型指标的影响因素，以及从这些模型指标如何反映结构质量。另外，针对各项指标给出行业最佳实践做法。 模型复杂度 首先介绍复杂度。当谈到复杂度时，我们首先谈到的是可读性的复杂度，这是对子系统级别建模应用风格的理解。因此，我们先来看子系统的局部复杂度。让我们从一个典型的子系统 图 2 开始。 图 2. 子系统的局部复杂度 在此处可以看到，示例的子系统由一些输入端口和输出端口和另外两个子系统组成。在当前结构层，我们只关注两个子系统模块，而忽略关注子系统中包含的内容。即当前子系统具有输入端口和输出端口以及两个模块。这里要理解结构层次的概念，主要是因为在结构层面，我们需要了解信号流的来源、走向和信号的目标，以及它们之间是如何相互连接的，也就是我们在这里看到的当前层的结构布局。因此，为了从结构上理解这种局部复杂度，我们不需要知道设计中做了怎样的计算，我们暂忽略里面的内容，只考虑这些典型的模块。在当前模型层级评估这个系统的局部复杂度，可以计算得出一个具体数字，考虑可见的所有这些元素在内，我们得出好比这里给出的 33 的一个数字，以此来表征子系统的局部复杂度。 那么为什么要计算局部复杂度呢？事实上我们希望确保在特定的模型层只关注某些模型相关的重要特征信息，应用适当的层次结构，使模型表示的内容更容易阅读和理解，即增强模型的可读性。同时关于模型表达的所有其他信息，我们在当前层级省略并把它放在模型结构的不同层级。合理的复杂度的子系统布局可提升结构质量，提高模型软件的简单性、可读性，减少审查和维护方面的工作。现在，如果这个数字表示不能告诉我们关于复杂度的更多的信息，不用担心，让我们来看下面的示例如 图 3 。 图 3. 复杂度 : 低复杂度 vs 高 复杂度 如 图 3 左侧部分，像这样的一个小规模的子系统，基本上只包含简单的几步计算，如果我们应用相同的局部复杂度计算方法计算得到一个数字，显示其复杂度数值为 6 0 。相比之下，对于 图 3 右侧 一个更大的子系统，我们看到它具有更多的计算。因此，我们第一印象 右侧 这个子系统更复杂。现在的问题是，它究竟有多复杂？能否给出某种数字来比较它比这个数字大多少或复杂多少？因此，应用局部复杂度的运算，我们得到其复杂度数值为 600 。好的，那我们说这个右侧大的子系统大约比这里的这个小的子系统复杂十倍。 那么 接下来 我们研究一下这个具有相当高复杂度的大型子系统（参看 图 3 右和 图 4 ），一般来说 6 00 显示其复杂度 不是很高，但也是中高范围。对于这样的一个子系统，如何提高可读性？整体看，我们会发现这里包含某种并行计算，有些信号流不是很明确。我们可以尝试将局部复杂度限制在某阈值内， 600 已经有点过大了。于是我们查看此处的子系统并进行模型重构。 容易看到 模型 基本上分为了上下两个部分。我们在本层结构中上下部分分别创建一个子系统使部分计算包含在下面的模型层，重构后的局部（参看 图 5 ）复杂度显著减小为 4 0 ，更重要的是重新布局的子系统，对于理解信号流、数据流和计算更为清晰简单，增强了可理解性和可维护性。 图 4 . 复杂系统的布局与复杂度（局部复杂度 ~ 600 ） 图 5. 复杂系统重构后的布局与复杂度（局部复杂度 ~ 40 ） 通过计算局部复杂度，我们可以查看模型组件的大小，或者子系统的复杂程度。从子系统重新开始，现在我们扩展到更大范围研究模型系统或子系统的全局复杂度，以了解模型系统的实现规模。因此，对于同样的模型系统或子系统如 图 6 , 子系统由输入端口 , 输出端口和两个子系统模块。但现在我们考虑子系统中的所有内容，子系统内部所有实现，如一些计算或更深层级的子系统中包含的内容，如 图 6 在模型浏览器中我们所看到的那样。现在对模型子系统中包括的所有内容计算所有子系统的复杂度并加和，得到系统的全局复杂度为 352 。这个模型复杂度的计算考虑了我们在这里看到的所有内容。因此，我们看到当前结构层的全局复杂度不仅包括局部复杂度 33 ，还包括其下各子系统层次结构贡献的局部复杂度。 图 6 . 全局复杂度 那么为什么要统计全局复杂度呢？原因在于通过全局复杂度的指标度量确保我们的单元或组件的不至于变得过于复杂。即确保单元和组件的可读性。同时我们还希望保持单元组件可度量，特别是对于审查和测试工作。因此，我们实际上可以将这个数字与审查和测试的工作量联系起来，这意味着数字越大，需要审查和测试的工作量就越大。 因此，全局 复杂度大小 等同于工作量多少，这正体现了对结构质量的影响。保持单元的小规模的同时提高可读性，模块化和可测试性，提升实施效率。如果对于某项功能需求，我们可以两种不同的方式实现它们，并且在功能上它们都可以完全正常地工作。但是当你计算它们的总实现的全局复杂度大小时，发现它们之间有很大的差异，然后你就知道全局复杂度较小的一个实际上是更高效的实现。因此 全局复杂度不一定 对功能质量产生影响，但它会对结构质量产生影响，表示我们的建模效率如何。 那么，全局复杂度在建模实践中怎样帮助我们改善和提高建模效率呢？我们以 Mat lab/Simulink 中的一个典型示例模型为例 加以说明。首先根据全局复杂度的指标，可以衡量并限制模型组件的整体大小，降低模型组件的复杂程度。其次，提供可测试性指标。例如通过采用库或模型引用（ 图 7 ）的方式，将文件分拆成单独的模型组件，提高组件的模块化和可测试性。最后，提供模块化指标。合理划分模块，达到模块复用或者单独测试的目的。模块化的设计与您的软件架构设计保持一致，关联重点需求和测试。模块化带来灵活地加载和编译，在不同的工程模型中重用，而不必在全局范围内重复的评审和测试某种结构类型的组件。 图 7. 复杂模型系统的重构 - 库 / 模型引用 模型指标非相干度 前面我们已经讨论复杂度的概念，如何了解组件的大小和复杂度。现在，我们进一步了解此组件本身的协同工作情况，如计算或计算之间是否彼此关联。为此，我们研究组件内不同组成部分的关联程度， Matlab/Simulink/Stateflow 中我们使用内聚度 【 1 】 和非相干度来表示。中心思想是子系统中的每个模块直接或间接地影响子系统中的其他模块，并且本身直接或间接地受到子系统中其他模块的影响。因此，对于每个模块 b ，计算受模块 b 影响或影响模块 b 的所有模块的数量，包括模块 b 本身，即通过 b 的路径上的模块总数（简记为 bop ）。高内聚的子系统的 bop 接近子系统的总模块计数；低内聚的子系统的 bop （ b ）与总模块计数相比会很低。例如 图 8 中的模块，我们可以找到模块旁边标注每个模块的 bop 值。 图 8. 子系统中通过每个模块的路径上的模块数示例 然后，汇总子系统中所有块的 bop 值，进行规范化，获得子系统的内聚值。因此，具有模块 Bs 的子系统 S 的内聚度的计算公式为： 内聚度： 进一步，我们定义非相干度为： 非相干度： 对于 图 8 中的子系统，内聚度和非相干度值代入相应计算公式得到： 内聚度： 非相干度： 子系统中的进行模块计算或结构的设计时，我们希望相关功能组合在一起，分组到一个子系统中。但是我们不希望对彼此不关联的功能进行分组，以此来提高可理解性。如果所有模块都只致力于一个功能或计算，那么就更容易理解。因此，我们希望确定并行组件的任何部分，或单独的组件，进而进行模型重构，实现模块化和封装性，提升可测试性和可维护性典型的质量指标。 那么，非相干度如何帮助我们重构操作呢？我们可以将非相干度解读为子系统中分离组件的粗略估计。例如 图 9 参与计算部分的所有模块都在一条路径上，这是最简单的情形，经过计算其非相干度为 1 。 图 10 类似前面的示例，如果子系统中有某种拆分路径，我们得到的非相干度是一个分数，在本例中是 1.3 。而如果在 图 11 这里进行并行计算会发生什么呢？此时多了一组单独并行的组件，实际上增加了不相干的组件数量，计算得到非相干度为 2 。由此看出，非相干度的数值的整数位可以让您大致了解子系统中有多少并行或分离的组件。 Incoherence = 1.0 图 9. 非相干度示例 1 Incoherence = 1.3 图 10. 非相干度示例 2 Incoherence = 2.0 图 11. 非相干度示例 3 让我们来看一个复杂的例子如 图 12 。我们现在可以使用 非相干度 来识别具有高复杂度和高度不相干的子系统。如 图 12 子系统的局部复杂度已经大到 1 104 ，导致可读性和可测试性方面非常大的困难。根据模型的非相干度指标值约为 5 ，表明大约可划分为 4 -5 个独立的组件。因此，我们对模型进行重构，可将模型重构为 4 个更大的分离组件。当然根据需要划分为 5 个也是完全可以的。像这样重构后，得到类似 图 13 的新结构，形成新的结构层，使整个模型更容易理解。首先，清晰地显示哪些输入信号对应于整个子系统单元的哪部分功能或运算，对相应功能信号的评估很重要。其次我们还可发现，非相干度大致保持不变，但是局部复杂度数值显著降低，提高了该层级模型的可理解性，当前模型层引入了结构层而不是功能和结构的混合。 Incoherence » 5, Local Complexity 1104 图 12 . 高复杂度和高度不相干的子系统示例 Incoherence » 4, Local Complexity 194 图 13 . 基于非相干度 Simulink 模型指标的模型重构 模型指标非相干度值除了帮助我们进行粗略的分离组件的估计，还能帮助我们避免隐式数据流的设计。我们来看看 图 14 这个例子。子系统由很多单独的图表组成，主要信号数据流被 goto/from 模块隐藏，很难理解信号的属性和流向。统计显示子系统具有非常高的局部复杂度，可读性差。但是同时我们又注意到，非相干度数值只有 3 ，意味着 goto /from 模块的使用在观感上分隔了功能组件，但 实际上它们可以简化为三个主要的功能组。而重构后的模型 图 15 表明，到结构层的子系统及数据信号流等方面得到更清晰的呈现，同时也显著降低了局部复杂度。 Incoherence » 3, Local Complexity 1673 图 14. 具有隐式数据流和高度不相干子系统的示例 Incoherence » 3, Local Complexity 111 图 15. 基于非相干度 Stateflow 模型指标的模型重构 结构和功能元素 如何理解实现结构和功能的分离？如 图 16 的 Sim ulink 的 子系统为例，我们把输入端口和输出端口称为中性块，因为在大多数情况下都必须存在。在子系统内部，没有任何计算在这里进行，只有两个子系统。我们称这样只包含子结构模块的子系统为结构子系统。 图 16. Simulink 演示模型 fuelsys 中的结构子系统示例 再如 图 17 这样的子系统，除了输入和输出端口，其余的模块都也是数学、逻辑或位运算或函数等功能性运算。我们称这样只包含功能运算模块的子系统为功能子系统。 图 17 . Simulink 演示模型 fuelsys 中的 功能子系统示例 如何识别模型的功能和结构水平？为此，我们引入子系统级别上 功能模块占比 这一模型指标， 指标 功能模块占比 表示子系统中功能模块与功能模块和结构模块之和的百分比。因此，度量值为 0% 意味着子系统除了中性块外，仅包含结构模块，子系统是 0% 的功能和 100% 的结构。指标值为 100% 表示纯功能子系统，中间值表示相应的混合子系统。 参看 表 1 中以对功能模块和结构模块的统计和 指标 功能模块占比 ， 指标 功能模块占比 100% 表示纯功能子系统 , - 表示纯结构子系统； 还有可能是不中 1 00% 的 分数，但是，在建模实践中，我们强烈建议避免这些混合，这种混合子系统下同一子系统层上具有结构模块和功能计算模块，可能会影响可读性、可理解性，尤其是可测试性。因此，最好尽量让这些数字变大或尽可能小，而不是趋于中间傎。 表 1. 模型指标：功能模块占比 按照 I SO26262 架构设计的原则的 建议，创建子系统的适当层次结构。但什么是适当的呢？您可以在此处将适当定义为结构和功能层之间的专用差异化设计。将结构和功能元素分开，形成信号处理和结构、功能的层次结构架构设计的一致性，提高可读性，模块化，可测试性和修改的适用性等方面的结构质量。 这里我们给出推荐的模型架构设计 的最佳实践 。在软件开发过程的软件架构部分粗略地定义模型软件架构，同时根据以上我们谈到的相应的模型指标进行模型系统的设计和重构来确保模型系统或子系统符合行业最佳实践和初始的软件架构设计。在详细设计阶段，我们仍然需要注意避免在同一子系统中混合结构和功能模块元素，确保最终得到简易美观分层合理的模型结构。如形成类似 图 18 所示的适当分层的模型结构，由 SimuLink 根层作为顶层的系统结构布局，其下层如图中模型层 1 通过各级子系统实现 信号分配和软件架构层，然后其下层 模型层 K 的子系统作为软件架构设计的结构实现。然后，从某层如 模型层 m 开始，作为软件架构的结构层，或者实际功能计算的实现层，直到功能计算的最后一层。即在分层结构中，将结构子系统层保持到最后一层。建模过程中通过合理使用库链接或模型引用简化系统复杂度，最终形成简单易读、易测试、易维护的模型架构。 图 18. 模型分层设计的最佳实践 无效接口与接口大小 现在，在谈论子系统的层和结构以及模型分层架构时，我们当然还需要了解子系统之间和进入子系统的信号流和子系统的接口。 按照 I SO26262 关于软件设计的原则建议 ，接口大小应限制在合理范围，防止接口过大而导致系统变得难以理解。考虑接口大小限制时，一方面考虑子系统接口总数的限制和信号的总线化处理，另一方面我们需要更加注重的是接口信号的有效供给。也就是说，输入子系统的信号务必与子系统中的功能需求相关的有效输入，防止实质上无用信号的输入。为了更好的理解，让我们看下面 图 19 的例子。五个基本输入信号进入包含多级子系统和模型引用的子系统中。值得注意的是五个基本信号实际上只使用了两个，即信号 a 和信号 b 用于积运算 ，而其他信号 c ,d, signal1 是不必要的输入，因为它们事实上没有被后续用于某功能或运算过程。 图 19 . 未使用 的 基础 信号示例 但在某些情况下，如果我们不了解实际的信号流，如我们难以查看子系统的模型或了解所有模型引用的细节，则很难理解这些信号是否被实际使用。此外，典型的用例如 图 20 中，我们常常把整个总线馈送到子系统中，但是子系统中本身的功能实现只需求其中部分数量的信号，旁路信号实际上并未被子系统所使用 。 所以我们希望限制接口的大小，确保单元和组件是可重用性的同时，还要避免出现虚拟耦合。为此我们通常采用强制实施显式信号流，以此提高模型的可读性、模块化、可测试性、可维护性和修改的适用性。 图 20 . 未使用 的 旁路信号示例 对于接口大小方面的限制和信号的处理，有什么最佳实践操作呢？首先我们要注意单纯的限定输入输出端口为具体的数值是不合理的。另外，作为 接口操作的最佳实践如 图 21 ，我们可以将需求的信号按功能需求分类分组到总线中，最好明确为子系统所需有效信号的基础上，使这些信号流显式表示，如图 1 8 中的信号分组与提取过程 。因此，我们在子系统外部提取或修改必要的总线信号， 在信号 选择器上选择我们实际要使用的信号，并且在结构层上明确显示子系统必需的信号流。 图 21. 接口操作的最佳实践 克隆组件 现在假设我们已经有了一个很好的模型设计，结构质量各指标都已得到充分优化，我想把某个功能或算法复用到其他地方，这时我们的操作可能是对模块、组件或子系统复制粘贴。当系统中多处形成类似结构，如包含相同属性的子系统部件组，我们也称其为克隆组。关于子系统克隆与克隆组的操作，假设模型中存在一个小子系统，包含一系列运算模块，一些常量，呈现一定布局。作为复用组件，我们复制粘贴它到模型另外一个地方，并进行了一些布局和参数的修改，如 图 22 所示。可以预见，如果我们重复进行类似操作，模型的复杂度会快速增长，相应也会带来测试和审查的工作量。因此，为了简化设计， 降低模型系统的复杂度 ，可以把具有克隆组的模型作为单独的模型引用。如果某些子系统需要频繁多次在模型中使用，我们可以将其转换为库文件。转换为模型引用或模型库的方式，有助于减少模型的复杂度，减少模型测试和维护的工作量，最终也会减少代码量。 图 22 . 子系统克隆 因此，找到大量克隆和克隆组，并用库引用替换它们，是针对克隆组件的最佳实践。以便显着降低全局复杂度，这意味着大小和工作量。对一个不同类型大量模块构成的复杂模型系统， 通常各 模型模块分组分散开发，容易出现模型的复制粘贴和克隆组的情况，模型系统呈现相对较高的全局复杂度。以某项目在克隆组及复杂度方面的研究统计结果 【 2 】 为例（ 图 23 ），系统中包含了大量的克隆组件和重复的子系统。对克隆组及克隆子系统的优化，可实现 1 0% 左右的复杂度缩减 。 一般来讲，对于大型工程， 1 0% 的 复杂度降低意味着 10% 的评审测试工作的减少，意味着大量的人工和成本的节省。 图 23. 控制系统的克隆组检测结果统计 当我们研究一个典型的项目开发周期与模型全局复杂度之间的关联，从项目开始到功能完成再到缺陷修复到最后项目结束，我们可以看到全局复杂度在开始时增加很快，后期逐渐饱和，特别是在缺陷修复阶段。但是，如果我们应用模型指标分析并定期进行模型重构，那么模型的总体大小和复杂度会显著降低。也就是说，在整个模型开发周期内进行指标分析，克隆组检测并定期进行模型重构，可有效地降低全局复杂度，提高结构质量。 模型指标分析与模型重构的最佳实践 上面我们罗列了模型相关众多的结构性指标，如何获得具体的相应指标精确数值，为模型的设计和重构提供参考。为此，我们可以借助模型检查工具，比如市场上比较受欢迎的模型检查工具 M ES Model Examiner 。 M ES Model Examiner 不仅是一个模型规则检查工具，而且可以精确统计模型结构质量指标，例如全局 / 局部复杂度，分层深度和接口大小，克隆组，非相干度等指标等等作为检查实现，并将这些结构质量指标显示在专门视图（ 图 24 ）中。如图中显示有各子系统的局部复杂度，如显示红色的局部复杂度 806 ，它高于默认设置的局部复杂度为 750 的上限，于是模型对局部复杂度规则一致性检查的结果给出失败的结果。 图 24. MES Model Examiner 模型指标视图 对于复杂模型系统的重构问题，也可以借助工具简化建模和重构的操作。比如 M ES 的专用模型重构工具 MES Model R efactor 通过自动化连续建模步骤使特定功能目的的建模变得简单快速，达到模型组件的快速重构。 综上所述，对模型结构属性相关质量如模型子系统的复杂度 ( 局部 / 全局）、组件大小、非相干度、功能组件的占比、接口大小和克隆组的统计等结构质量的分析， 在开发过程中中应用模型指标并定期重构的最佳实践，有助于在模型软件开发阶段增强模型的可读性、可理解性、可维护性和可测试性，有效降低软件复杂度，实施模型组件和功能建模的设计和验证原则，提高模型的结构质量，从而总体上提高模型软件系统的质量。 关于 MES 模赛思：软件质量在控制之中 模赛思软件技术有限公司 (Model Engineering Solutions)，简称 MES) 是一家高科技软件公司，专为软件项目的质量保障提供解决方案。MES 为客户基于模型的软件开发提供技术支持，使其符合 IEC 61508、ISO 26262 或 ASPICE 等行业标准。 MES 模赛思成立于 2006 年，总部位于德国柏林。Hartmut Pohlheim 博士作为基于模型的开发领域最著名的专家之一，自 2008 年起任公司常务董事。MES 的主要客户包括整车厂如戴姆勒、大众、丰田和吉利等以及博世、西门子和三星等行业供应商。在汽车行业中，除少数几家公司外，全球数十家顶尖制造商及供应商均在他们的开发环境中使用 MES 的解决方案。为支持其全球客户，MES 已在美国和中国建立了子公司，并与全球分销商网络紧密合作。 MES 的产品包括 4 种质量工具软件：MXAM、MTest、MoRe 和 MQC，它们共同构成了一个工具链，全面保障基于模型的软件开发过程中所有阶段的质量。通过 MES Jenkins Plugin，该工具链也可以在持续集成环境中使用。工具链主要应用平台为 MATLAB® Simulink®。除了 MES 质量工具外，MES 测试中心和 MES 学院的专家们还为全球客户提供关于质量保证和开发流程优化的定制咨询服务及培训课程。 MES 是 dSPACE 公司的战略合作伙伴和 MathWorks 及 ETAS 的产品合作伙伴。MES 学院与 SAE International 有合作关系。 更多关于基于模型的开发，嵌入式软件相关信息、知识分享与在线研讨会，欢迎扫码关注 MES 模赛思微信公众号：

沃尔沃汽车公司（ VCC ）是世界上最知名与最受人尊敬的汽车品牌之一。 该公司在为全球客户提供最新技术和安全性能方面享有很高的声誉。 在瑞典哥德堡郊区的 VCC 研发中心里，数千名工程师组成的工作团队致力于为下一代乘用车创造新技术。无论是应用于电动、燃油还是混合式动力系统，沃尔沃汽车研发活动的重点是提高动力总成部件（发动机，动力传动系统，齿轮箱）的性能。 因此，汽车动力系统应用的控制软件起着至关重要的作用。 扩大沃尔沃汽车内部软件开发的规模 沃尔沃汽车公司（ VCC ）在大约 20 年前引进了基于模型的内部软件开发，主要用于发动机和动力传动系统的控制。 基于模型的开发的优点是，现场工程师的专业知识可以与自动化的高质量软件开发相结合。 未来控制软件的功能模型将由功能开发人员的人编写，他们是其各自领域的专家。 他们专注于机电一体化系统及其功能行为，在软件生成工具链的支持下创建易于阅读，可测试和可维护的软件模型，包括控制器代码。 VCC 驱动系统和动力总成部门始于 2002 年，当时有一个大约由 10 名软件开发人员组成的不大的团队和一个简单的基本流程。 当时手动批处理（ Bat ）文件被用于生成代码和软件建构流程中。 在过去的几年里，由于来自多种不同车辆项目的需求不断增加，如不同类型的动力传动系统和燃烧控制功能的扩展，控制器软件中加入了越来越多的功能。 所需功能的复杂性和绝对数量也呈指数级增长。 这导致越来越多的验证和确认步骤需要插入到开发链中。目前这个开发团队已发展成 100 多名行业专家和功能开发人员的团队。 随着团队规模的扩大，将不同的软件组件集成到一个工作系统中，并减少需要在软件存储库中进行跟踪的故障数量成为了一个挑战。 而新软件产品的每一个版本的发布也变得越来越具有挑战性。 当时 Apache SVN 被用作管理开发不同软件版本的主要工具。 沃尔沃汽车向持续集成的转变 2014 年，沃尔沃汽车的高层技术管理层决定引进先进软件行业的最佳实践、工具和方法。 在当今的软件行业里，持续集成（ CI ）和每日构建被用于将软件系统中的不同组件轻松集成到成熟的软件系统中，并使已有的保留功能不会被新的特征影响。 此外，每个开发人员会收到关于他们对软件系统的贡献的快速反馈，且资源密集型的测试过程能够一夜之间在一个更大的服务器上完成。 通过使用回归测试、每日构建和持续集成，人们可以有效地避免一场 “ 集成噩梦 ” ， 即要等到发布日那一天才能将其开发的各部分合并到预发布分支（ release branch) 上时的通常情况。 这些重要的 CI 原则被引入到 VCC 整个电子控制模块系列中。 2018 年，他们又额外引进了基于 OpenStack ZUUL 的新 CI 系统。 ZUUL 的座右铭是： “ 不要合并损坏的代码。 ” 因此，只有经过测试和分析的代码才被允许合并到主分支（ master ）上。 ZUUL 有许多优点，但最重要的一个是预测合并步骤，它允许大规模并行化。 ZUUL 建立在变更管理系统 GIT 的基础上，这是一种快速、可扩展的分布式版本控制系统。 此外， GIT 的插件 Gerrit 用来准备协作代码审查。 因此， ZUUL 是大脑， 它听取 Gerrit 里的事件并将任务分发给 Jenkins 。 这个最新引进的、基于 CI 的开发链被称为沃尔沃汽车 ECM CI 链。 从软件实现开始，每一个新的提交都会自动触发一组集成和回归测试。 开发人员提交的变更已通过运行对构建的自动测试进行了验证。 这种新的开发方法完全遵循项目前期加载质量保证流程的理念。 另外，将后期集成问题的数量降低到绝对最低值的主要目标也很快得到了实现。 沃尔沃汽车的工具软件部署 到目前为止， VCC 关注的重点一直是用于版本管理、代码生成和最终代码质量的主要技术。 但是，在基于模型的设计中，最终代码的质量取决于为自动代码生成提供基础的软件模型的设置。 功能模块是最核心的工件，而对软件模型的全面验证是保证最终代码质量的关键。 出于这个原因，沃尔沃汽车的动力总成部门开始寻找先进、实用的模型质量指标和质量工具，以弥补在这方面的不足。 2017 年， VCC 评估了一套由 Model Engineering Solutions ，一家位于柏林的软件模型质量专业公司设计的模型质量工具。 VCC 决定逐步将模型结构检查工具 MES MXRAY® 和建模规范检查工具 MES Model Examiner® 引入到现有的 CI 工具链。 MES 工具软件能够计算质量指标并分析每个通过 CI 工具链的模型是否符合建模规范的标准。 在开发流程中，收集的指标充当了质量门禁的作用，如果软件模型的质量指标未超过阈值，那么它只能由开发人员才能成功提交。 分析的结果将报告给各功能设计人员，他们对其模型的更改负全部责任。单击链接将会弹出更多的详细结果，高效地支持开发人员修复模型。 由报告生成的软件指标 在 MES 模赛思公司的支持以及 MES 专家的指导下， VCC 驱动系统和动力总成部门对他们的项目进行了调查并选出了合适的模型质量规范。 于是，我们按照相关的具体建模风格需求编制并测试了常规开发项目与沃尔沃汽车驱动系统中安全攸关项目的建模规范集。 在 ECM CI 链中，每次单个提交都会触发一组自动化测试，包括 MES MXRAY 的复杂性分析和 MES Model Examiner® 的建模规范合规性检查。 最后，例如建模规范合规性、复杂性、单元测试结果和代码审查结果会以汇总反馈的形式提供给开发人员，并提供详细报告的链接。 公司的总目标是建立一个学习圈，并在此过程中激励早期和自我问责的错误预防。 ECM CI 的设计涵盖了从模型的首次提交到自动生成代码的审查的所有流程步骤。 它还可以加入那些影响工具链中的检查、测试配置和工作流的配置设置。 使用 CI 驱动开发链取得的成果 尽管引入新的 CI 驱动工具链需要花费一些时间和精力，但它已经展现了许多优点。 首先，它显著改善了软件开发团队之间的协作方式。 验证和质量保证的主要目标得到了实现、提高了生产率，并且显著减少了繁琐的手工工作量。 最大的提升来自 MXRAY ，因为复杂性的降低有助于对功能的更好理解，进而可以快速稳健地进行动力系统的参数调优（校准）。 复杂性的降低会带来模型的重构，并使单元测试的编写更加容易。 根据沃尔沃汽车驱动系统的 ECM 软件架构师 Andreas Wikerstål 博士的说法， ECM CI 链 “ 为我们提供了必要的工具组合，以应对不断增长的基于软件的功能的数量，同时保证了软件的稳健性和质量不变。 在功能模型层级， MES 工具允许我们在开发流程的早期阶段进行度量并提高质量。 这为代码创建和集成的最后关键阶段节省了大量时间与金钱。 ” 向全集成 CI 链迈进 在未来几年，沃尔沃汽车的目标是逐步扩展其基于模型的设计流程，并覆盖所有的开发项目。 越来越多的用户将使用工具链，其中 MES Model Examinar® 和 MES M-XRAY 将发挥不可或缺的作用。 沃尔沃汽车将全面致力于 ECM CI 工具链的持续扩展，并使其剩余的半自动步骤完全实现自动化。 沃尔沃汽车驱动系统的 CI/CD 产品负责人 Johannes Foufas 自信地说： “ 我们目前正在研究向 ZUUL v3 的方向迈进 , ，因为该产品将为我们提供 in-repo 配置，实时配置更改，对多节点作业的本机支持以及 Ansible 工作内容。 我们还将努力移除所有手动步骤，并根据 GIT 标签仅保留同行评审，产品负责人批准和发布步骤。 如果可能的话，其它的所有步骤都应该实现自动化。 ” 未来，软件 CI 工具链的创建将自动触发工具链中的下一步，且不受任何用户的干扰。 此外，更加详尽的建模规范将被逐步引进，以进一步提升进度，提高建模规范的合规性。 关于 MES 模赛思 : 软件质量在控制之中 模赛思软件技术有限公司(Model Engineering Solutions GmbH, 简称MES)于2006 年在德国柏林成立，自2018年起先后在美国底特律和中国上海设立子公司。作为一家持续发展的高科技软件公司，自成立以来MES 模赛思致力于对基于模型的嵌入式软件提供质量保障，为客户基于模型的软件开发提供技术支持，使其符合IEC 61508、ISO 26262或ASPICE等行业标准。我们的产品为用于软件开发的质量工具，此外，我们还提供嵌入式软件基于模型开发领域的免费线上研讨会和付费培训课程。 MES 的主要客户包括整车厂如戴姆勒、大众、丰田和吉利等以及博世、西门子和三星等行业供应商。在汽车行业中，除少数几家公司外，全球数十家顶尖制造商及供应商均在他们的开发环境中使用 MES 的解决方案。 MES 的产品包括 4 种质量工具软件： MXAM 、 MTest 、 MoRe 和 MQC ，它们共同构成了一个工具链，全面保障基于模型的软件开发过程中所有阶段的质量。通过 MES Jenkins Plugin ，该工具链也可以在持续集成环境中使用。工具链主要应用平台为 MATLAB® Simulink® 。除了 MES 质量工具外， MES 测试中心和 MES 学院的专家们还为全球客户提供关于质量保证和开发流程优化的定制咨询服务及培训课程。