Mentor发布《汽车系统设计的整体解决方案》研究报告

用功能性方法来介绍和开发系统架构通常是基于如EAST-ADL或SysML等UML（统一建模语言）衍生的特定域的语言。同时，用各种形式和抽象层级（例如功能、活动、序列和/或状态图） 来介绍将要被开发的系统的技术内容（组件），然后为了执行进行适当的映射。

使用这种方法需要做大量的工作，不太适用于架构评估，更适用于详细的归档。事实上，为了能够对整体系统架构进行有意义的技术和财务评估 ，必须非常详细地明确每个单个层级直到到达足够程度的细节。在随后的映射中 ， 工作量会按细节程度的平方数增加：例如，在单个层级中的工件数量。

如果计算相应的指标不够敏捷，就无法及时地对功能分配的变化进行评价，也就无法为每个单个的将要被评价的选择提供真正有意义的结果，例如一个具体控制单元的软件组件。

总体而言，这极大地影响了架构的研究。在某些情况下提供必要的数据和计算想要的指标所需要的时间可能比整个项目原计划的时间还要多！

功能模型

介绍的另一种方法使用了在一个单一层级上结合了标准化的、分等级的功能模型来描述系统架构的技术内容。 标准化 的功能模型指可从它们最终作为硬件、驱动器和软件组件执行中分离出来的单个功能。不再在多个（在某些情况下是多余的）层级上分发模型，取而代之的是单个的特定域的描述可以与一个单个的功能抽象结合，从而消除了冗长的映射过程。通过可以被标准化（变成软件、电气或总线信号）的信号实现单个功能间的通信。所有的工件都可以与一组来自详细的选项/变型模型的规则有关。硬件、软件和电子&网络通信的组件模型可以因此而集成在一起，并且使用设计规则检查（DRC）来同时检查和验证他们的语义依赖关系。

通过这种方式可以早在功能抽象层级捕获下游执行域（硬件、软件、网络和电气）的技术、变型推动的内容，并在所有变型中验证该内容。

为了说明这种方法，图3展示了许多功能块。软件功能(SW)、驱动器组件(D)，传感器(S)和执行器(A)在一个单个的抽象层级被描述和显示。功能间的信号根据它们需要执行的颜色显示：红色(SW)、绿色（PCB上的电子信号 ） 、橙色（线束上的电子信号）和蓝色（ 网络上的信号 ） 。

标出各种功能、选项分配和外部功能块或信号参考的功能图。

在图4中，单个类型的分配与下游平台的执行要求一致。如果一个功能是属于软件类的，这意味着该功能在平台上在下游分配中被视为SW组件：它应被分配到控制单元，而不是一个单纯的电气组件。注意，一些功能和信息是可选的，与选项/变型模型呼应。

关于不同软件类功能的图。

功能可以按等级组织，功能信号既可以参考它们的原始功能（如果从外部功能设计开始），也可以通过一个信号库进行跨平台和项目使用。

逻辑平台

如果功能设计被如上所述所捕捉，那么就可以自动创建下游执行（硬件和软件、串行总线系统和电气分布 ） ，并且总是会尊重选项/变型的关系。

要做到这一点，首先定义一个逻辑平台。这可以由一个3D模型以物理拓扑的形式得到，但是也可以从一个抽象的逻辑网络拓扑开始。通过向一个选项/变型模型分配单个功能组件，逻辑平台可以包括（以汽车工程为例）一辆单个的车、一系列的车或一个汽车平台所有可能存在的衍生物，包括软件、电气系统、网络和硬件的变化形式。同样的原则也适用于卡车、越野车车辆、飞机和复杂的机电设备，如工业打印机和医疗设备。甚至，一个像防空系统这类经过扩展的系统也可以用这种方式建模。