摘要
本文介绍了一种使用标准化的、分等级的功能作为一个单一的层级来描述电气、电子和软件内容的车辆系统设计方法。然后在一个合成过程中生成特定域的执行层级，并使用适当指标进行评估。重点是快速的迭代优化和对跨域架构的评估和验证。
基于功能的系统工程
用功能性方法来介绍和开发系统架构通常是基于如EAST-ADL或SysML等UML (统一建模语言)衍生的特定域的语言。同时， 用各种形式和抽象层级(例如功能、活动、序列和/或状态图)来介绍将要被开发的系统的技术内容(组件)，然后为了执行进行适当的映射。
SysML图类型(分类法)， 来自维基百科。
使用这种方法需要做大量的工作，不太适用于架构评估，更适用于详细的归档。事实上，为了能够对整体系统架构进行有意义的技术和财务评估， 必须非常详细地明确每个单个层级直到到达足够程度的细节。在随后的映射中，工作量会按细节程度的平方数增加：例如，在单个层级中的工件数量。
如果计算相应的指标不够敏捷，就无法及时地对功能分配的变化进行评价，也就无法为每个单个的将要被评价的选择提供真正有意义的结果，例如一个具体控制单元的软件组件。
总体而言，这极大地影响了架构的研究。在某些情况下提供必要的数据和计算想要的指标所需要的时间可能比整个项目原计划的时间还要多!
功能模型
本文介绍的另一种方法使用了在一个单一层级上结合了标准化的、分等级的功能模型来描述系统架构的技术内容。在本文中，标准化的功能模型指可从它们最终作为硬件、驱动器和软件组件执行中分离出来的单个功能。不再在多个(在某些情况下是多余的)层级上分发模型，取而代之的是单个的特定域的描述可以与一个单个的功能抽象结合，从而消除了冗长的映射过程。通过可以被标准化(变成软件、电气或总线信号)的信号实现单个功能间的通信。所有的工件都可以与一组来自详细的选项/变型模型的规则有关。硬件、软件和电子&网络通信的组件模型可以因此而集成在一起，并且使用设计规则检查(DRC)来同时检查和验证他们的语义依赖关系。
通过这种方式可以早在功能抽象层级捕获下游执行域(硬件、软件、网络和电气)的技术、变型推动的内容，并在所有变型中验证该内容。
特定域流程和上游功能架构设计。
功能设计。
为了说明这种方法，图3展示了许多功能块。软件功能(SW)、驱动器组件(D)，传感器(S)和执行器 (A)在一个单个的抽象层级被描述和显示。功能间的信号根据它们需要执行的颜色显示：红色(SW)、绿色(PCB上的电子信号)、橙色(线束上的电子信号)和蓝色(网络上的信号)。
标出各种功能、选项分配和外部功能块或信号参考的功能图。
在图4中，单个类型的分配与下游平台的执行要求一致。如果一个功能是属于软件类的，这意味着该功能在平台上在下游分配中被视为SW组件：它应被分配到控制单元，而不是一个单纯的电气组件。注意，一些功能和信息是可选的，与选项/变型模型呼应。
关于不同软件类功能的图。
功能可以按等级组织，功能信号既可以参考它们的原始功能(如果从外部功能设计开始)，也可以通过一个信号库进行跨平台和项目使用。
逻辑平台
如果功能设计被如上所述所捕捉，那么就可以自动创建下游执行(硬件和软件、串行总线系统和电气分布)，并且总是会尊重选项/变型的关系。
要做到这一点，首先定义一个逻辑平台。这可以由一个3D模型以物理拓扑的形式得到，但是也可以从一个抽象的逻辑网络拓扑开始。通过向一个选项/变型模型分配单个功能组件，逻辑平台可以包括(以汽车工程为例)一辆单个的车、一系列的车或一个汽车平台所有可能存在的衍生物，包括软件、电气系统、网络和硬件的变化形式。同样的原则也适用于卡车、越野车车辆、飞机和复杂的机电设备，如工业打印机和医疗设备。甚至，一个像防空系统这类经过扩展的系统也可以用这种方式建模。
拥有标准化功能容器(资源)和连接通路(载体)的平台架构。
平台的单个节点作为资源被标准化：电子控制单元(ECU)或线路可更换单元(LRU)、电气总成、电力或接地导体。它们可以通过电气或总线系统(CAN、LIN、Flexray、Ethernet(以太网)、ARINC 429等)，或通过光学或电波连接耦合。这些通信通路被称为载体
合成
功能随后被分配到逻辑平台中。这可以手动或利用规则自动完成。执行的过程中将按功能的类型询问功能。例如，从SW类型中创建一个软件组件，然后被分配到控制单元。功能之间传递的信号将在逻辑平台上分为软件、电气或网络信号向载体分配。
分配功能的规则。
分配功能和信号的规则。
由此产生的合成是集成地执行功能描述的四类域(硬件、软件、网络通信和电气)。利用设计规则检查、任何必要警告或生成的错误消息来实时分析语义的一致性。
指标
技术评估指标早在合成过程中就可以计算。可以通过设定让这些指标显示各种信息。例如，对于多路传输网络而言有意义的指标包括负荷、容错和开销。电气域的指标包括电线、焊接点和连接器数量、电线长度、线束直径。控制单元的指标包括设备重量、CPU负荷、RAM、ROM、FLASH/EEPROM的要求、印刷电路板(PCB)面积和单位体积功率，和热耗散。按与功能、资源和载体有关的参数计算指标：往往可以从先前的执行中详细了解这些参数。
如果一个值大于一个特定的水平，例如，如果预测内存的要求超出微处理器提出的预算，这一情况将通过设计规则检查发送警报或直接发布到平台架构师的图形显示器上。这帮助工程师保证设计的可行性。
而且可以计算的不仅仅是技术指标。通过扩展计算，还可以计算成本、重量、富余、可靠性或再利用等这类项目目标。
指标样例：目标数量、CPU利用率、网络负荷和任务调度。 评价和优化
因为使用这些指标进行评价是实时完成的，即当做出设计决定或改变时，这一过程与评估替代执行(架构)或者实际修改功能内容非常匹配。指标立即反映出这些变化，并且随后可以进行替代策略的研究。
按对象计数、技术评估、CPU和网络流量测量值比较不同的扩展和优化阶段。
因此可以迭代和交互地解决优化功能分区、电气优化、成本和运行时间优化问题。
经过最后的评价，逻辑平台合成的结果以每个特定域的形式(如ARXML、FIBEX或 KBL)被输送到下游详细的设计过程中。架构研究阶段的结果可以被重新用作未来平台的执行建议。在一个集成设计环境中，数据当然可以直接被传递给相应的应用程序。
总结
本文介绍的方法在一个单一层级上使用了功能抽象来整合不同的电子/电气域。这反过来允许对执行其它方案进行快速评估，同时为详细设计准备数据。
因为对技术工作和知识的要求较高，现有基于UML或类似SysML元模型的方法对于这样的架构评估与验证不太适用。相关的复杂性导致在可用的时间内几乎没有可能提供综合评价所需的充分或必要的细节。
符合本文描述的原则的商业软件可在Mentor Automotive Capital®产品套件中找到。
功能架构设计和评估，及下游设计流的后续执行方案。
相比之下，所描述的方法使用了一个功能抽象，其中执行相关的数据和工件整合入了标准化的功能模型中，而不是将它们分布到不同的(多数情况下是多余的)级层上。
早在自动向逻辑平台分配时，该模型可以被反复地验证执行可行性和得到相应的技术和商业指标的维护。架构过程的结果也是对软件、网络、电气系统和硬件的下游开发过程的执行建议。
