Paul F.Smith,Sameer M.Prabhu,Jonathan H.Friedman

The MathWorks

 

需谨慎管理向基于模型设计的过渡，不仅要展示其短期效益 ，还需建立能够完全实现此方法理论优点的文化。本文引入了基于模型设计的概念，突出了其中的一些优点，详细讨论了组织中采用基于模型设计文化的10个最佳策略。这些最佳策略从不同工业领域的公司中收集，包括向基于模型设计的成功或者不成功的过渡。

 

嵌入式系统的深入应用不断改变着汽车工业。在复杂的，板载的，和基于软件的电控使用中需对系统的性能，安全性，和维护的改进，从而引起汽车工业的变化。这种变化不仅仅在客车领域发生，在商务车领域也开始应用嵌入式系统。这里应用的嵌入式系统可用于液压系统的控制，而之前液压系统都是由机械系统控制，嵌入式系统的使得改进了机器的生产率，安全性以及维护等性能。这以上两个领域中，系统复杂度的增加给传统系统开发过程提出了很大的挑战，如满足程序时序，成本和质量等性能的度量上。为了应对以上挑战，主要汽车制造商的工程师跳过了手写代码进行系统设计的开发过程，直接过渡至利用图示化模型设计，分析及执行决定机器性能和行为的软件。

使用模型可以保证最终产品满足系统的需求。这些模型帮助不同专业的工程师一起高效工作，并可在设计过程的不同阶段进行交流；在设计的早期阶段发现并校正错误；自动生成实用，高效，及高质量的软件。软件工具卖家的独特视角可看出：基本原则的提炼可能保证基于模型设计的成功应用。这些基本原则的范围从与自动代码生成相关的特定策略到一些组织性的问题。我们需要对每个策略进行细节的检查。以上建议的“正确”综合以及基于模型设计需要依托的公司环境，在过渡时需由工程部经理进行仔细的选择。

 

在基于模型的设计中，开发的过程围绕着系统的模型—从需求的获取到设计的执行及测试。

图1：基于模型的设计

系统模型是可执行规范的核心部分。可执行规范需在设计流程中使用及精心开发。可执行规范还包括输入，期望输出或可接受标准，应用的环境，以及同需求之间的连接或相关[1]。可执行规范的目标是明确的传达设计目标，同时通过仿真对需求进行可行性和兼容性分析。

当包括软件和硬件的执行需求时：如定点，或定时的行为，可以为嵌入式部署自动生成代码，同时创建测试台对系统进行检验，节省时间同时避免引入手写代码的错误。

使用基于模型的设计，工程师可以通过下列方法提高效率：

 

为什么公司都采用基于模型的设计？有时候通过战略计划驱动的自上而下的委托管理来部署一套常用的工具和进程，其他则是基层自主的方式，在大学中的工程师使用建模的方法并在现在工作中寻找工具来满足需求。在其它情况下，基于模型的设计能够将技术扩展至更积极的如6sigma或者系统工程中。无论向基于模型设计的过渡的推动力是什么，由于公司所见的回报，仍然在进行努力。回报以以下几种形式体现：

另外，工程师通常在选用正确的工具时，工作的会更有乐趣。

 

智慧是数年学习的积累

聪明的组织从自己犯的错误中吸取教训，而智慧的组织则是从他人犯的错误中学习新的东西。多年来同很多公司和政府机构一起工作，当这些组织向基于模型设计的过渡中，我们看到了很多成功之处，也有少量的挫折。我们收集了下列最有代表性的最优策略，这样我们的读者可从其它人身上学习很多东西，避免向基于模型设计文化过渡时遇到的一些常见的错误。

考虑到向基于模型设计过作为一种开发嵌入式计算系统的方法时，需要着重考虑文化，工具，处理器，组织以及战略等方面。

首先，组织必须建立起衡量模型和仿真开发和使用的文化，将其作为一个核心的工程活动。

需要易于获取工具，同时使得基于模型的设计可以改进生产效率。

需要易于获得工具，同时能够广泛运行，从而获得基于模型设计的生产率的提高。

在定义的进程的界限内使用工具。每个公司或者政府部门在设计过程中有不同等级的形式，这些形式是由文化，规定，最优策略，最新的趋势以及在其中工作的人决定的。但采用基于模型的设计时，同其他技术一样，需要建立有效一致环境处理过程。

可能需要改变或者弃用传统的组织模型，从而支持基于模型设计的工作流程。在内部小组之间传递工作成果，同时设计者和执行者由于基于模型的设计界限变得模糊。一个有着愿竟式领导的有效组织机构是成功的必要条件。

向基于模型设计的过渡需有一个明确定义的目标和支持的战略。过渡需要逻辑顺序，这根据组织的不同而不同。这种战略需要建立在现有的优势上，同时支持设计过程中的弱点。高层管理者需要深刻理解这些战略，同时针对计划对工程师进行管理。

 

在发生任何进程的改进前，需要更深一步理解现有的组织机构和进程中相关的优势和弱点。需要有支持这些理解内容的衡量方法。对于没有合适的衡量标准项目的组织，使用最佳策略#0建立这样一个项目。一个医生在弄明白病的实质和病人用药史前不能开出精确的治病处方。这同样适用于基于模型设计的采用。在现代嵌入式系统开发过程中有很多子元素不能有效运行，举例如下：

每个采用基于模型设计的组织需要发现现有过程中存在的弱点，为了解决该弱点需要付出的代价，以及首先要解决的问题。

在解决首先解决什么问题时，同样需要知道解决该问题所需花费的时间。总经理需要对该工具投资以及授权技术的回报有自己的见解，从中选出一部分向赞助商说明投资的回报。

 

为了过渡至基于模型的设计，我们需要对工具，培训以及组织性等方面进行变革从而适应该过渡过程。为了获取以上投资的最少可接受的回报，生成的模型需要可用于至少两种以上的应用中。举例来说，模型需要用于在仿真中验证需求，同时生成文档资料。同时可选择的应用：定义和开发在快速原型时的控制算法，及为产品控制器自动生成代码。

两个过程元素的选择需要使用最佳策略#1进行慎重考虑。这样做的目的为获得投资的最大回报。不同设计阶段的模型重复使用功能是获取最大回报的必要条件。

追求一次性模型的组织可能获得成功，但易于发现采用新技术的负担，他们很难获得时间和资金投资的收益。     

 

组织不断通过软件来实现硬件的共用，也就是说，为了保证同样的基础硬件能够实现不同的功能，可以通过改变控制该硬件的嵌入式软件。这样节省了制造商在硬件上的规模，同时使得产品仅仅通过改变嵌入式软件就可以满足顾客自定义的需求，满足了产品自定义同大批量生产两个看上去相互矛盾的目标。毫无疑问，嵌入式系统软件正快速取代着机械硬件的使用，成为决定产品性能特性的关键因素。同时，嵌入式系统软件控制着汽车的主要系统，因此从实际来说，汽车的“行驶”需要依靠软件。讨论了嵌入式软件的重要性之后，则可以很自然的将之前所提到的“规则2”扩展至模型的一个使用：自动生成嵌入式软件，

使用模型保证设计能够满足相关系统的需求，同时在设计的早期发现设计错误，从而使得纠正错误付出的代价最小化。代码生成技术的最新发展可以从模型中自动生成产品级嵌入式软件[11]。当模型能够自动生成软件时，整个测试基础可重用于测试模型，因此可以检验生成的软件及可能发现的错误，同时及早纠正。同时，如果需要改变需求及设计，则需将他们做成模型，这样可以重新高效的从模型中生成软件，大大缩短了软件跟上需求或者设计的改变所需的反应时间。

从模型中自动生成嵌入式软件需要组织文化的转变。在过去，控制设计师为他们的设计创建模型，软件工程师则基于这些模型的规范手动开发嵌入式系统。有了嵌入式软件的自动生成，软件工程师的关注点发生着变化，从每次设计或者需求改变时重新花费时间写算法代码到花费更多的时间将算法代码同嵌入式系统的其他部分集成，同时也适用于说明和设置基础结构。这是一个重要的转变，使得衡量软件工程师工作效率的指标也随之改变。另外，模型使得控制工程师和设计工程师之间的关系更为紧密，消除了工作之间传统的障碍。组织的领导者需要鼓励和支持这种做法，从而得到基于模型设计的所有优点。

 

除了遵从“规则2”和在开发过程中使用模型实现多重目的得到的优点外，基于模型设计的一个很重要的优点即建立的模型可在多个项目中重复利用。模型属于组织的知识产权（IP），可以在很多项目中重复使用，因此IP可以发挥协调作用使得项目在质量和时间上大大提高。但是，这种优势只有在模型中包含真正的IP才能获得。

本最佳策略和最佳策略#3的逻辑扩展即模型是同嵌入式系统相关的真理的唯一来源。模型中自动生成的嵌入式软件只能让汽车“行驶”。如果在试生产汽车的最后检验和测试中发现算法错误或者针对需求进行最后微小的改变，则倾向于“修正”嵌入式软件本身来避免对自动的嵌入式软件生成和一体化进程重新检查。但若软件工程师使用了这种试探性的方法，会停止模型软件的同步，模型也不包括真正的IP。因此，如果在不同的项目中重复使用该模型，则需要在项目中重复面对及处理算法错误或需求的不一致。

该部分同最佳策略#3讨论的一样加强了组织的含义。控制和软件工程师需要合作从而保证任何最终很小的改变都确实融入至模型中。组织的领导者需要支持和鼓励这种做法，同时强调这样做的需要及好处。如果不是这样，控制和软件工程师很容易发生分歧，从而防碍了基于模型设计的所有优点。实际上，组织者需要有严格的纪律来使用和促进模型，使其成为嵌入式系统唯一的设计语言。

 

有时候，从传统的开发过程过渡至基于模型的设计会有些徘徊。但是，组织者遵从最佳策略#1，同时通过过渡的过程进行自我学习，这对他们长期的成功非常有益。这种自我反省可对现有的过程，以及自己的优点和弱点有清楚根本地认识，同时对组织的核心竞争力有更深的理解。有了这些深入的信息，组织可以更好的完成向基于模型设计过渡的任务。

在向基于模型设计过渡的过程中，一种常见的试探性的做法既“外包”至第三方。虽然外包本身不是坏主意，但仍然需要正确的判断，同时目标领域是组织的非核心竞争力部分。如果将现有的IP至基于模型的环境的过渡进行外包，则组织也失去了重新检查这些IP的机会，同时也无法质疑IP的哪一部分需要真的变化，或者修正可能存在IP内的错误和BUG等等。因此，效率不高的外包很容易浪费改进产品质量的很重要的机会。组织需要确认能从第三方得到帮助，这些帮助需要集中在创建工具和效用上，简化向基于模型设计的过渡，同时提出基于模型设计的更好的过程等等。

另外一种试探性的做法即“快速转变”，彻底地向基于模型设计过渡从而获得所有的优点。这种做法也有很多缺点。首先，现有的开发过程或产品的某些组成部分效率较高，或者构造完善，在第一道关时不需要改变。丢弃这样优势会导致向基于模型的设计调整时不必要的重复性工作。一种更聪明的方法即批判性的选择开发过程和产品的组成部分，取其精华，去其糟粕。举例来说，识别当前开发过程或产品中的问题区域，在第一次循环中将基于模型的设计集中于该区域。第二步，了解当前开发过程或产品中包含哪些不需要向基于模型的设计过渡的部分，如低等级的设备驱动器，或者在未来产品中需要淘汰的性能等，这些都不需要过渡至基于模型的设计。对当前的开发过程进行深入的观察，识别其中最适合使用基于模型设计的区域，最小的中断开发过程，同时获得最大的收益。

当决定产品IP的哪一部分需要建模后，首先需要解决一些全新的控制特性。其次，着手解决设计中的问题部分，那些不断发生变化或者引起问题的部分。最后，如果时间允许，将更为稳定的控制系统的端口慢慢移植入该背景中。

 

有时候，引入基于模型的设计时，软件工程师会立即关注他们的职位是否受到威胁。然而，这种担心在设计小组发现软件工程师仍是基于模型设计中的一部分后消失了。但是软件工程师的角色也随之改变，从运行时代码编写的综合能动性过渡至在开发过程的初始阶段构建软件，同时不断完善可执行规范从而使得生成的代码更接近执行阶段。

举例来说，软件工程师需要开发一个灵活的机制，使得使用基于模型设计开发的新特性能够同原有代码集成。另外，软件工程师需要对生成的模型进行完善，保证其生成的代码能够在目标处理器中运行，如当算法模型作为浮点值创建时，目标处理器即为浮点的。

 

若有可支持的基础设施增强本文所提出的最佳策略，则基于模型的设计的应用会更流行。换句话说，要想取得成功，基于模型的设计需要是主流产品开发过程的一部分，而不是覆盖。

通常，需对现有的开发过程和衡量方法进行修改从而同基于模型的设计结合。举例来说，我们需要开发风格向导，并在合适的项目里程碑中回顾该风格向导以进行支持。我们需要涉及基于模型设计的加工品的配置管理。在以代码为中心的过程中，代码通常是主要的或者唯一人工可控的部分。在基于模型的设计中，控制的人工部分包括测试向量，期望成果，模型组成以及使用的建模环境的版本[6]等等。同样，需求管理和验证过程及工具需同基于模型设计工具相集成。传统方式中，软件需求一般不进行校验，除非有可用的可执行硬件。但是，引入基于模型的设计后，仿真验证可在硬件验证之前进行。

必须建立细节的，不间断的培训以及能力开发计划。这些计划包括一般的产品培训和自定义的特定过程的指导和规定。

最后，可能也是最重要的，需要更新评估项目状态的衡量方法，从而完成向基于模型设计的过渡[8]。举例来说，在传统的开发过程中，一个人可能对每天生成的代码行数进行计数从而评估项目的“健康度”。但当所有行的代码在“一个按钮按下时”可全部生成，这种衡量方式失去了意义。

 

成功过渡至基于模型设计的大部分的组织通常选择了一个有力的，有经验的同时受尊敬的领导者。有时候这个领导者需要是善于促成共识的人，有时候也是仁慈的独裁者。

这个人通常很有资历，有着证明其曾经协调过体系变革的历史纪录。这种空降兵被某些人所惧怕，同时被其他人拥戴。胜利者需要鼓励那些希望用新方法做事的人，同时也要安慰（或者消除）那些不希望用新的方法做事的人的恐惧。

胜利者需要同是被同级，上级以及下级的人所尊重。如果胜利者所处的政治前景明显或不明显的破坏着过渡过程，则整个的过渡过程面临风险，而同技术或开发过程无关。

这个人需要进行直接的预算控制，或者有着高级赞助商的支持。人力，资本或者培训的投资是整个基于模型设计的部署和投资期望回报（ROI）的函数。这些投资对于组织来说非常重要，同时预算的处理也是胜利者的一个重要特质。

 

向基于模型设计过渡需要一定的时间。对于交通业，建筑设备，或者空防等从零开始的工业组织中，中等大小的嵌入式系统的设计和开发需使用年来衡量过渡的时间，而不是用月。ROI可在第一个模型建立，仿真及消除设计缺陷后，同时在变成代码或硬件之前取得。获得全部的优点则需花费一定的时间。

很多组织试图跟上潮流是常见的事情，他们希望在3到6个月内将他们的开发机构过渡至基于模型设计的概念或者技术的机构，这是非常不现实的。可能有着少量生产线的小型全套装备以及5-20个开发者可以在一段较短的时间内完成过渡。进行基础研究的小组进行得更快些，这是因为他们不易被原有代码所累（但是相应的ROI较低）。较大的组织更容易被原有开发过程的组成部分所累，同时“粘合”任何商业工具至开发过程也占用了相当多的时间。需要考虑包括如何结合基于模型的设计同原有的系统和开发过程在内的一些因素，这样做为了：

（注：这不是一个详尽的列表）

长期的工作需要耐心和深思熟虑。拥有一个管理计划，不停的完善。庆祝过程中小的胜利，同时如果环境变化也需考虑适当改变计划。使用上面列出的其他最佳策略，慎重选择使用策略的顺序，用于将基于模型设计概念应用于说明价值提升的一系列命令（以及承诺提供保持过渡所需的资源）

大部分工程师都会在过渡的开始立即发现一个优点：工作中有了更多的乐趣。大部分人，尤其是工程师-喜欢使用强大的工具，这样可以保持较高的速率以及提升工作的满意度。

 

如本文开始部分所述，聪明的组织从自己的错误中吸取教训，而明智的组织则是从其它人的错误中学习新的东西。由于工具供应商在组织向基于模型设计的过渡中扮演了重要的角色，需紧密的加入支持过渡的过程中，因此，他们积累了关于大量组织在管理成功的（或不成功的）过渡时需要处理的情况和方面等重要经验，。在自己组织的过渡过程中使用工具供应商积累的经验可以很大程度上降低著名的学习曲线的陡度。这样组织能够更快体会到基于模型设计的好处，因此也使得投资回报率（ROI）盈亏平衡点更为提前，不仅仅降低了学习曲线初始加速的坡度，同时及早在组织中使用工具供应商收集的经验可以减少保持基于模型设计所需的努力。因此，同工具供应商密切联系，将他们包括至过渡计划，有效利用他们的经验，避免常见的错误，同时合作获得一个成功的过渡。

 

结论

基于模型设计的应用为开发嵌入式控制系统，如应用于汽车动力传动或者经典控制中的系统，提供了一个健全，成熟以及高度精炼的策略。通过多年观察及参与不同组织的过渡过程，这些过渡包括大的小的，商业的或者政府的，交通，通信，以及其它嵌入式控制开发等，从中提炼了上述最佳策略，同时和大家分享。这些策略不是固定的准则，不能在每个仿真中应用。每个组织在向基于模型设计的过渡阶段需要退一步来省视自我。只有明智的选用这些最佳策略才会给使用中的嵌入式控制开发过程现代化所需要的人力和技术投资带来最大的回报。