在之前的视频中，我们讨论了系统工程如何通过提供一种形式化的方式来思考和记录程序需求，从而帮助我们定义我们试图解决的问题。在一个项目的时间轴上，我们倾向于首先定义问题，包括需求和要求等等，然后过渡到定义的执行，在那里我们完成详细的设计和构建东西。当然，有比这两个阶段更多的阶段，但在这一集视频中，我想集中在这里。
我们已经介绍过，在项目的定义阶段花费时间，并在此阶段构建模型可以使执行阶段更有效。不幸的是，程序阶段往往比这张图显示的更混乱，阶段重叠，有时你必须回溯，所以它不像从一个阶段转移到另一个阶段那么简单。所以，在这个视频中，我想讲的是，基于模型的系统工程如何帮助你消除所有的混乱，让你从定义到执行更加无缝。我希望你能坚持下去。我是Brian，欢迎来到MATLAB技术讲座。
让我们从描述这个过渡时期开始，这样我们就能理解是什么导致了混乱。您可能会认为系统工程只负责将涉众的需求分解为系统是什么的完美描述。从定义到执行的过渡只是把需求和预算以及所有的东西扔给工程领域的专家，作为他们必须遵循的某种规范。
事实几乎肯定不是这样。还记得上个视频中的烤面包机例子吗，需求分解(定义的一部分)需要对实现进行假设。如果没有领域专家进行贸易研究，确定什么是可行的，并最终帮助选择最佳的实施方案，就无法实现这种程度的专一性。如果没有利益相关者在出现问题时细化他们的需求，如果没有管理层权衡对成本、风险和进度的影响，这也是不可能完成的。
因此，与完成定义的一次性移交相比，这个过渡更像是一个模糊的渐变，所有参与的人都慢慢地从主要的定义过渡到主要的执行。
此外，这张图给人的印象是整个项目同时在过渡。但复杂的工程是混乱的，往往某些组件开始详细设计，而其他组件还没有真正考虑太多。这可能是因为一些组件自然更简单，所以你可以更早地投入到设计中，或者它可能会有意地在计划中提前，因为在采购某些部件方面有一个已知的长期领先优势，或者一个组件有很多未知，如果你不专注于为该组件找到解决方案，整个项目的可行性就会处于危险之中，所以你必须更早地开始开发。
不管原因是什么，这个简单的渐变实际上是许多不同的渐变，它们代表了系统的每个主要组件或部分的过渡。
更复杂的是，在进行详细设计和构建之前，并不总是先定义组件的功能。有时，您从一个或多个现有组件开始，并且必须弄清楚如何使它们符合定义。例如，您可能正在重用以前项目中的软件或硬件。这在汽车行业很常见，同一台发动机、变速器或其他部件用于多个车型。在这种情况下，组件是完全开发的，您必须定义系统的其余部分，以便与组件一起工作。
现在，一个真正快速的题外话，如果你完全通过重用现有的部分来构建一个系统，你不知道你想要最终的系统做什么，这是一个自下而上的工程方法。这就像从收集乐高积木开始，然后把它们拼凑在一起，看看你能做出什么。你对最终产品没有一个宏伟的想法，你只需要看看可用的部分会产生什么。另一方面，自顶向下的方法将从您想要创建的内容开始，然后确定您需要哪些部分来完成该任务。
然而，通常情况下，我们做的是某种折衷的方法，其中一些组件可能已经完全充实和设计好了，您必须将它们与其他尚未构建的组件结合起来，以满足整个项目的需求。因此，在定义阶段，你必须确保你提出的设计与这些现有组件有兼容的接口，流入组件的项目存在于你的系统中，该组件的需求被纳入需求层次结构中。
好了，回到这个过渡。希望您能明白，这比一次性的定义转换要复杂得多。这是一个随时间推移而发生的过程，使用异步组件时间线，涉及不同的人员组，并且具有不同成熟度级别的组件。这是一个过渡，在这个过渡中，人们仍然将系统分解为功能、组件和编写需求，同时尝试执行业务研究并做出设计选择。系统工程的目标是确保所有的人员，组件和系统设计保持相互兼容和一致在整个过渡过程中，它们仍然继续满足整个项目的需求。
而这正是基于模型的系统工程可以大放异彩的地方。模型是有价值的，因为我们可以执行它们，并且比使用必须手动更新和解释的静态文档更快地了解系统。而在项目初期的混乱阶段，快速准确的信息对决策的影响是巨大的。
通过扩展本系列前面的简单烤面包机示例，我们可以大致了解模型的好处。一个系统工程团队，与管理层和涉众一起工作，已经将高层规划需求分解为一个可执行的功能体系结构。但是为了进一步分解加热功能，并为其编写较低级别的需求，领域专家需要参与进来，并开始交换可能的实现。使用这样的模型，他们可以从函数定义本身开始。通过这种方式，领域专家得到了一些可以开始的东西，这些东西将确保该功能的接口之类的东西与系统级的需要一致。然后以此为基础，他们可以建立他们认为可以满足加热需求的不同实现的物理模型。因此，通过这种方式，模型以一种方便的方式提供了接口、需求和所有进入定义的东西的定义，但它也提供了领域专家可以围绕其完成设计的结构。
但这只是一个组成部分。与此同时，其他成分股也在经历类似的交易。它们中的每一个都处于不同的成熟水平，因为它们以自己的速度从主要是定义发展到主要是执行。当然，如果我们正在重用组件，而这些组件已经创建了模型，那么我们只需按原样将这些模型拉进来。
在整个过程中，我们监控界面违反或约束违反或任何其他不匹配的设计。如果有任何违规，我们可以在进一步深入设计并更改组件或实现以解决它之前捕捉到它。
除了在创建组件模型时检查这种违反之外，我们还可以模拟系统级模型来验证性能度量是否得到满足。因此，基于模型的系统工程和基于模型的设计可以一起工作，以提供一个测试框架，该框架可用于各个组件和完整的系统验证。
还有一件事我想快速提到的是，我们在定义系统时建立的模型——尤其是基于软件的系统——可以成为实际的实现。因此，模型可以不仅仅是一个定义或实现的起点，它们可以是实现。例如，状态机定义了系统的不同状态，以及系统如何在这些状态之间转换。定义内置于此表示中。有人可以根据状态机的定义为它编写代码。但是我们也可以直接从模型生成状态逻辑的生产代码。因此，定义状态及其转换的人类可读图是代码本身的来源。
现在，在基于模型的工程中有这样一个梦想，一个单一的建模生态系统可以捕捉涉众的需求、需求定义、组件定义和实现，然后提供一种方法来通过模拟和测试验证系统，然后甚至在运行期间使用模型作为数字双胞胎来进行预测控制或预测维护。由于在这个建模生态系统中，所有的东西都是在整个项目中联系在一起的，所以所做的一切都有可跟踪性。但是，即使您没有得到完全的基于模型的端到端方法，希望您可以开始看到采用该过程的某些部分仍然有价值。
好了，在结束这个视频之前，我想回顾一下我认为的要点。复杂的工程问题造成了混乱的时间表。系统工程是在所有这些混乱发生时，将项目需求牢记于心的过程。对于复杂的系统，很难理解每个决策将如何影响最终的系统。这就是为什么我们将系统分解成更简单、更容易理解的组件，为什么我们将抽象的想法提炼成具体的需求，为什么我们管理接口以确保所有这些组件(可能是由不同的团队设计和构建的)都仍然适合在一起。这就是系统工程，基于模型的系统工程就是把所有这些东西都放到模型中，我们可以用它们来更清楚地交流想法，并允许在定义阶段进行早期验证和验证，并为交易不同的实现提供一个框架。所有这些都可以帮助我们理解混乱的过渡阶段。
好了，这节课就讲到这里。如果你不想错过任何未来的Tech Talk视频，不要忘记订阅这个频道。另外，如果你想看看我的频道，我还会介绍其他控制理论的话题。感谢收看，我们下期见。
