沃尔沃车身结构解析（沃尔沃汽车的经验）

汽车架构框架：沃尔沃汽车的经验

Patrizio Pelliccione a∗, Eric Knauss a, Rogardt Heldal a,c, S. Magnus Agren ˚ a,

Piergiuseppe Mallozzi a, Anders Alminger b, Daniel Borgentun b

a Chalmers University of Technology | University of Gothenburg, Department of Computer Science and Engineering, Sweden

b Volvo Cars, Sweden

c Bergen University College, Norway

关键词

架构框架

软件架构

汽车领域

体系（SoS）

持续集成和部署

汽车生态系统

摘要

汽车领域正处于一个极具挑战性的历史时刻，许多新兴的业务和技术需求令其震惊。电气化、自动驾驶和联网汽车是这个不断变化的领域的一些驾驶需求。汽车正日益成为软件密集型的复杂系统，汽车行业的大部分创新都是基于电子和软件。现代汽车可以有100多个电子控制单元（ECU），这些单元都是小型计算机，一起执行数十亿字节的软件。ECUs通过车辆内部的几个网络相互连接，车辆与外部的联系日益紧密。这些创新要求改变软件的设计和生产方式，并对汽车的电气和软件架构进行颠覆性的革新。在这篇论文中，我们描述了沃尔沃汽车目前的研究，以创建一个架构框架，能够应对当前和未来汽车的复杂性和需求。具体地说，我们提出了描述架构框架需求的场景，并介绍了在未来的架构决策中需要考虑的三个新观点：持续集成和部署，生态系统和透明度，以及车辆是一个体系（SoS）的组成部分。我们的结果是基于来自不同公司和大学的汽车工程和架构专家的一系列焦点小组。

1.引言

今天的汽车工业所关注的，远不止传统观点所认为的由人控制的用于交通运输的组装机械部件。在过去的20年里，车辆变得越来越像机器人，解释和利用来自各种传感器的输入来做出（半自主）决策，并最终执行以前由人做出的动作。

因此，软件的作用是不断变化的。最初，它被引入汽车以优化发动机的控制。从那以后，汽车内软件的增长每年都呈指数级增长，今天没有哪一个功能是没有软件参与的。汽车工业中80%-90%的创新是基于电子[1]，正如Robert Bosch GmbH的工程副总裁Peter van Staa在2014年6月[1]欧洲技术大会上提到的那样。电子产品的很大一部分是软件。

软件的相当一部分是安全强相关的，如果系统不能按预期运行，则会危及人的生命。因此，重点逐渐从人对机械的控制转移到支持决策甚至接管控制的软件和电子设备。这一发展与更为普及的飞机发展史以及自动驾驶和“线飞”的发明有相似之处，但也有一些显著的不同。车辆行驶所处环境的复杂性大大降低了车辆自动控制的发展速度。最先进的汽车比战斗机拥有更多的软件，或者至少是相当数量的软件。汽车的产量也高于飞机，这对技术成本提出了更高的要求。

汽车工业的这种演变给电气和软件架构的开发和维护带来了新的挑战。现代汽车的架构必须处理大量的问题，包括安全防护（safety & sECUrity）、变型管理、网络、成本、重量等。此外，越来越多的人参与到软件开发项目中，这给架构团队带来了额外的挑战，因为开发和设计在字面上不能被一个单独的团队控制，甚至不再能被一个单独的团队详细地理解了（设计链条长、人员/团队多，能够全盘了解的几乎没有很少。冷酷的冬瓜注）。开发不可避免地并行化；这显然也适用于大量的外部开发的软件，它们被集成为黑盒功能。重要的集成工作由开发人员和测试团队以迭代的方式完成，首先关注重要的系统，然后逐步建立各种功能。架构师可能不参与集成，但是，架构师肯定会影响集成。

在这篇论文中，我们报告了一个当前沃尔沃汽车革新电气架构的新方案。这项工作是瑞典Vinnova公司FFI项目的一部分，该项目名为“下一代电气架构”（NGEA，Next Generation Electrical Architecture），工作内容主要集中在以下几个方面：（i）持续集成和部署；（ii）汽车作为体系（SoS）的组成部分；（iii）通过允许确认的关键功能在域控制器节点上实现的架构来减少ECU的数量；和（iv）改善汽车生态系统的策略，以便能够与供应商快速沟通和灵活开发。NGEA项目选择这些主题的原因是，它们对汽车行业具有重要的战略意义，找到处理它们的方法很重要。在这篇论文中，我们很大程度上超越了一篇简短的论文[2]：[2]中的论文只是概述了初步结果。

在这个项目中，我们正在研究创建一个沃尔沃汽车架构框架的可能性。我们相信一个架构框架[3]，连同它的多个观点，是管理日益复杂的现代车辆的工具。它的目的是确保对车辆架构的描述可以跨不同的车型项目、开发单元和组织架构进行比较和关联，从而增加灵活性和创新性，同时减少开发周期和降低风险。然而，架构的定义和描述需要人力和财政方面的成本。此外，有时在正确定义和描述架构上投入精力和资金并不会在开发的后期节省资金。例如，正如本文后面所描述的，我们确定了预期的架构和实现的架构之间的差异（预期的架构和实现的架构之间有差异，佐证了‘...投入精力和资金、并不会在后期节省资金’的观点。冷酷的冬瓜注）。这推动了向即时架构、持续集成和部署的转变。

我们在汽车领域的现有架构框架上进行搭建，即[4，5]，并且我们的工作基于ISO/IEC/IEEE 42010：2011标准[3]提供的概念基础。该标准对架构进行描述，即记录软件、系统和企业组织架构的实践，以便能够理解、记录、分析和实现架构。

论文结构如下。第2节介绍了架构框架的概念，并解释了记录架构框架的模板。第3节概述了汽车领域中架构框架的现状。第4节分析了沃尔沃汽车的实践状况，并报告了一些经验教训。第5节介绍了我们在NGEA项目的背景下在沃尔沃汽车中定义的架构框架，包括利益相关者的概述以及定义架构框架的需求和期望的关键场景。第6~8节详细介绍了该框架的三个新的、具有挑战性的观点，即持续集成和部署观点（第6节）、生态系统和透明度观点（第7节）和体系（SoS）：汽车视角的观点（第8节）。最后，论文在第9节中做了总结，并对未来的工作进行了讨论。

2.架构框架

在本文我们参考由ISO/IEC/IEEE 42010:2011标准[3]建议的架构定义，它定义架构为：" <系统>一个系统的环境中的基本概念或属性体现在它的元素、关系、以及其设计和演变的原则中”。因此，对于架构的术语表述，我们并不是指系统的特定视图，因为我们关注的是汽车领域，所以架构也会以一种抽象的方式涉及物理部件及其行为。架构的描述是“用于表达架构的工作产品”[3]。

架构框架是一组协调的观点、惯例、原则和实践，用于特定领域的应用或利益相关者社区[3]中的架构描述。更具体地说，它是由：

-一组与架构相关的关注点；

-一组持有这些关注点利益相关者：

-一组架构观点，它们框住（即，覆盖）这些关注：

-一组模型对应规则，用于在模型类之间施加约束，然后演示架构所满足的约束。

然后，架构框架建立了一个通用实践，用于在特定的应用领域或利益相关者社区中创建、解释、分析和使用架构描述，开发架构建模工具和架构方法，并建立流程来促进跨多个项目和/或组织[3]之间的沟通、承诺和互操作。

如图1所示，架构框架是由架构观点标识的预制知识结构，架构师使用它将架构描述组织到架构视图中。架构视图和架构观点是标准[3]的核心：“观点是查看系统的一种方式；视图是将一个观点应用到特定的兴趣系统的结果”。架构观点封装了表示法、约定、方法和技术，以便根据特定的模型类、构建特定的关注点和为系统利益相关者的特定受众使用。关注点决定了模型类必须能够表达：例如，功能性、安全性、可靠性、成本、部署等等。模型类决定要使用的表示法、约定、方法和技术。定义每个架构视图内容的观点是由一个或多个模型类和将它们链接在一起以保持一致性的对应规则构建的。与模式和样式一样，观点也是可重复使用的架构知识的一种形式，用于解决源自最佳实践的某些类型的架构描述问题。观点最初是在20世纪70年代提出的（在Ross的结构化分析中），然后在[6]中进行了改进。架构设计方法通常定义一个或多个观点，例如[7-10]

图1. 超出标准的术语和概念（图取自[3]）

许多现有的实践通过模型集合来表达架构，并且模型被进一步组织成内聚的组，称为视图。视图可以被定义为“从特定系统关注点的角度表达系统架构的工作产品”[3]。正如标准中所指出的，一组模型的内聚性是由特定的关注点决定的，这些关注点由该组模型处理。观点指的是表示架构与一组关注点相关的约定。

有关内容模型和架构框架机制的进一步讨论，请参见[11]。最近的框架包括开放分布式处理的ISO参考模型、GERAM（通用企业参考架构和方法）[12]、DODAF（美国国防部架构）[13]、TOGAF[14]和MODAF[15]。有关框架的详细介绍，请参阅[16]。

在本文中，我们根据ISO/IEC/IEEE 42010：2011， System and software engineering-Architecture description，使用架构观点模板来指定架构观点。

在下面，我们讲述了模板部分和指南的摘录：有关模板的完整描述，请参阅上述链接：

-观点名称：观点的名称。如果有任何同义词或其他常见的名称，这个观点是已知的或使用的，记录在这里。

-概述：提供观点的抽象或简短概述。描述观点的主要特征。

-关注点和利益相关者：架构师在寻找适合其目的的架构观点时，经常使用已确定的关注点和典型的利益相关者来指导他们的搜索。因此，重要的是（同时也是标准所要求的）记录观点所针对的关注点和利益相关者。

-关注点：关注点在系统中名为“感兴趣的领域”。关注点可以是非常综合的（例如，可靠性），也可以是非常具体的（例如，系统如何处理网络延迟）。在本节中确定的关注点对于架构师来说是至关重要的信息，因为它们帮助架构师决定什么时候这个观点是有用的。当在架构描述中使用时，这个观点就成为架构师和利益相关者之间的“契约”，这些关注点将在这个观点产生的见解中得到处理。以该观点产生的见解能够回答的问题的形式来表达关注点是有帮助的。例如，系统如何管理故障？或者系统提供什么服务？

-典型的利益相关者：提供系统中典型的利益相关者的列表，这些利益相关者是此类视图的潜在受众。典型的利益相关者将包括那些可能阅读此类视图和/或那些需要将此视图的结果用于其他任务的人。

-反关注点[可选]对架构师和利益相关者来说，记录下“这种观点不合适或不是特别有用”的问题可能是有帮助的。确定给定表示法或方法的“反关注点”可能是解决某些过度使用的模型和表示法的好方法。

-模型类名称：确定模型类

-约定：描述这类模型的约定。约定包括语言、表示法、建模技术、分析方法和其他操作。这些是模型类为架构师提供的关键建模资源，并确定用于构建此类模型的词汇表，以及如何解释和使用这些模型。该标准没有预先规定如何记录建模约定。这些约定可以定义如下：

（Ⅰ）通过引用现有的表示法或语言（如SADT[17]或UML[18]或架构描述语言，如EAST-ADL[19]或SysML[20]）或现有的技术：

（Ⅱ）通过给出一个定义其核心结构的元模型：

（Ⅲ）通过模板供用户填写：

（Ⅳ）通过这些方法的组合或其他方式。

-操作：指定在此类模型上定义的操作。

-对应规则：记录与模型类相关的所有对应规则。

-视图上的操作：操作定义了应用于视图及其模型的方法。操作类型包括：

构造法是在该视图下构造视图的方法。这些操作可以是过程指导的形式（如何开始，下一步做什么）：或工作产品指南（此类视图的模板）。构造技术也可以是启发式的：识别样式、模式或其他在视图合成中应用的习惯用法。

解释法 指导读者理解和解释架构视图及其模型的解释方法。

分析法用于从这个视图检查、推理、转换、预测和评估架构结果，包括引用模型对应规则的操作。

实现法是使用此视图设计和构建系统的方法。

-对应规则：记录任何由这个观点或它的模型类定义的对应规则。通常，这些规则将跨模型或跨视图，因为模型类中的约束将作为该模型类的约定的一部分指定。

-示例[可选]：为读者（架构师和其他利益相关者）提供使用观点的有用示例。

-注释[可选]：提供给观点的用户可能需要或认为有用的任何附加信息。

-来源：确定这个架构观点的来源，如果有的话，包括作者、历史、参考书目、现有技术等。

在本文中，我们应用上面的观点模板来描述我们提出的三个新观点。在我们当前的工作中，许多细节仍然需要被评估，因此我们例如在这些模型需要什么样的提供信息，共享候选的模型类以及我们的经验，而不是提出一个明确的定义要使用的建模表示法。

3.汽车架构框架的现状

架构框架在汽车领域和汽车工业中还没有得到标准化。然而，也有一些尝试，不同类型的架构观点和视图最近作为汽车架构框架的一部分被引入。

3.1 汽车架构框架（AAF）

迈向标准化架构基础和特定于汽车的架构框架的第一次尝试是在[4]中提出的汽车架构框架（AAF）。AAF的目的是描述跨所有功能和工程领域的整个汽车系统，并驱动汽车行业的思维过程。AAF符合ISO 42010国际标准[3]，因此它被定义为一组观点和视图。

AAF区分了两组架构观点和视图：（i）强制的和通用的观点和（ii）可选的观点。以下观点是根据[8]中的观点目录提出的。强制性观点及其各自的观点包括：（i）功能观点——功能分解、功能架构：（ii）逻辑观点——逻辑分解，逻辑架构：这个观点只在[4]中提到，在[21]中没有详细说明：（iii）技术观点——物理分解、技术架构：（iv）信息观点——用来界定和管理车辆的信息或数据对象的视角：（v）司机/车辆操作观点——车辆环境：（vi）价值网络观点——OEM利益相关者及其供应商和工程合作伙伴的利益相关者。AAF建议的可选观点是：（i）安全性，（ii）安全和防护，（iii）质量和RAS——可靠性，可用性，可服务性，（iv）能量，可能包括性能，（v）成本，（vi） NVH——噪音，振动，声振粗糙度，和（vii）重量。

3.2 架构设计框架（ADF）

架构设计框架（ADF）[22]是由Renault开发的，包括操作、功能、构造和需求观点。虽然AAF和ADF是相关的，但它们之间存在一定的差异。

-操作观点——这是一个更抽象的观点。从一个黑盒和用户视角[22]观察系统。

-功能观点——在与操作观点相关的视图中标识的系统功能被分配给SysML块。

-结构观点——这个观点描述了系统功能在物理组件中的进一步分配（或分组）。

-需求观点——这个观点与其他观点是正交的。每个需求视图都与其他观点的视图有关系。这个建议的过程是很容易失败的。利益相关者的需求是在确定参与者和系统边界之后的最开始构建的。这些需求是识别高层次需求的起点。技术需求视图通常是在整个操作视图集可用之后构建的。

3.3 汽车系统的架构框架（AFAS）

通过对面向汽车领域的AAF、ADF和架构描述语言的分析[23，24]，如EAST-ADL[19]和AML[25]，在[5]中提出了汽车系统的架构框架（The Architecture Framework for Automotive Systems， AFAS）。它包含了对AAF和ADF中提出的观点的阐述和统一，然后提出了附加的观点，例如：

-特性观点——用于支持产品线工程。

-实现观点——它描述了车辆[19]中电气/电子（E/E）系统的软件架构。

4.沃尔沃汽车内部的软件开发挑战

在之前的一篇论文中，我们从架构的角度研究了沃尔沃汽车，研究了OEMs在过去几年[26]所面临的挑战。为了更好地理解由组织架构中的不同部分负责架构中不同部分或层的组织问题，我们决定进行9次深入访谈，重点关注架构师的角色以及组织因素如何影响他们。这些访谈是在沃尔沃汽车和沃尔沃集团卡车技术（VGTT）内进行的，扩展了对这些特定公司的知识，从而提供了对两个独立但相似的汽车公司的详细了解。在[26]中，我们遵循了一种轻量级的基于理论的方法，因为我们是从一个一般的研究问题开始的，为了收集更多的信息，我们只涉及很少的人。在对第一批数据进行分析的基础上，在数据中出现的第一批想法的基础上，我们提炼研究问题，仔细规划研究，并据此选择被访谈的人。除了收集初步想法的初步工作外，我们还使用访谈作为数据生成方法。具体来说，我们使用了半结构化的访谈：我们定义了要讨论的主题和要问的问题的列表。然而，在一些会见中，我们根据收到的答案和“谈话”的流程来改变问题的顺序。每次采访大约一个小时，我们收集现场记录和录音。每次访谈都以介绍、澄清研究目的、请求记录许可和保证信息的机密性开始。关于研究方法的更多信息可以在[26]中找到。

4.1 说明性架构和描述性架构之间的差距

我们发现架构（或顶层设计）与设计之间并不总是存在明显的一旦开发需要对系统设计进行更改，这种联系似乎也会随着时间的推移而消失。架构以大型文档的形式进行交流，利益相关者应该阅读这些文档。然而，这并不总是符合现实。沃尔沃汽车也在跨职能团队中工作（沃尔沃汽车也是按照跨职能团队进行工作推进。冷酷的冬瓜注），其他类型的交流也用于交流架构。需要更多的分析来理解问题的根源。此外，架构的维护——随着设计的发展——是需要的，但并不总是在所有的部件中执行。这显示了根据V模型流程定义的规划架构与实际出现在系统开发中的架构之间的差异。

我们确定了架构具有时效性，这意味着：在任何给定的时间点上，系统只有一个架构，然而架构将随着时间而改变。我们将捕获到的、在系统构建之前所做的设计决策的架构称为规定性架构。这个架构是最初设想的或最初设想的架构。我们可以将描述系统如何构建的架构称为描述性架构。此架构描述了已实施或已实现的架构。我们注意到，在预期的架构和实现的架构之间常常存在差异。这导致了所谓的架构退化。这种退化可能以两种不同的方式出现：（i）当描述性架构包含的变更不包括在规定性架构中、但又不违反规定性架构的设计决策时，架构发生偏移：（ii）将架构设计决策引入到违反其规定性架构的系统的描述性架构中，架构发生侵蚀。

在分析架构退化的原因时，我们可以总结出以下三个方面的原因：

1. 在开发过程中，由于时间限制、错误、误解等原因，一些预期的架构的重要指示被违反了。

2. 预期的架构的一些架构选择是基于设想（可能是隐式的），这些设想后来被认定为不精确或错误的，

3.预期的架构的一些架构选择是在不确定的情况下做出的，在开发期间这些选择被判定为未达到最佳标准的。

4.2 组织和流程的挑战

第一项架构退化的原因在上述章节中讨论（4.1节）可能是通过改善沟通——如前所述——解决，或者想办法保证保护预期的架构的重要指示不以任何理由违背。

在组织方面，我们发现需要改进不同组之间的沟通，例如让团队跨职能属性更强。今天，架构师和设计人员/开发人员之间有几个级别，其中一些级别的联系不是很紧密。

一方面，这似乎是不可避免的，因为公司很大，并且需要将组织结构划分为子组织（部门、组或团队）。然而，存在这样的风险：子组织将独立地成长，并且彼此分离：这可能会导致谷仓思维（只对内不对外。冷酷的冬瓜注）。例如，这可能会导致设计人员/开发人员认为架构师远在云端，与现实没有任何联系。架构师可能也会感到沮丧，因为他们没有意识到正在发生的一切：因此，他们工作的很大一部分就是跟上小组的步伐。参考[23，28]中的术语，架构师应该既是“内向的”架构师（概念上与[29]的内部关注点相关），即专注于更有建设性的工作和架构的定义；，又是“外向”的架构师（概念上与[29]的外部关注点相关），即致力于向其他利益相关者传达架构决策和知识。

不同的组织有不同的能力、态度和特点。然而，新的问题出现了。事实上，我们可以确认我们发现了许多架构反模式。我们发现了镀金反模式[29]，因为架构师似乎并没有真正参与到开发人员中。他们的技术工作做得很好，但是，他们的输出并没有真正符合开发人员的需求，最后他们经常被忽略。我们发现的另一个反模式是象牙塔[29]：架构团队看起来与开发团队是互相隔绝，不与开发人员和其他利益相关者进行日常交流。这在组织中造成了紧张。

需要探索组织和技术上的可能性，以便在架构级别之间进行更紧密的合作，并衡量这些改进可能产生的效果。在技术方面，部分解决方案可能是定义特定的观点，并从设计中自动生成相应的架构视图。每个视图都应该集中于只显示与各自利益相关者相关的内容。此外，架构师和设计人员/开发人员都需要一些方法来执行他们解决方案的早期验证，并勾画和尝试未来系统应该是什么样子的不同愿景：这将允许理解设计决策对架构的影响。正如前面提到的，这只能是一个部分的解决方案，因为它不能解决架构问题，因为这个解决方案只关注通过特定的观点和视图来可视化已经存在的东西。需要其他的解决方案来解决上面提到的即时架构的支持，以及使不同于架构师的利益相关者（如开发人员）在实际需要时改进架构。

4.3 从“即时架构”角度来看

4.1节中讨论架构退化的第二点和第三点原因呼吁“即时架构”或敏捷架构[30]使得不同于架构师的利益相关者——如开发人员——改善架构，例如通过修复错误的设想或谨慎推迟决策。

一些实践者提出的一个设想是，在开发大型复杂系统时，“一个清晰且定义良好的架构可以促进并支持敏捷开发”。这个设想意味着，在构建像汽车这样的复杂产品时，需要一些预先的规范。然而，当要实现的产品没有明确定义，公司想要快速进入市场时，这一假设就不是完全正确的（如Waterman等人观察到的[31]）。在这些情况下，可变性、对演进的支持等等并不是真正需要考虑的主要方面（快速推出产品、进入市场，开发周期才是这种情况下考虑的要点。冷酷的冬瓜注）。当产品定义良好时，设想似乎是正确的。另一个需要考虑的方面是，敏捷需要重构，但是重构通常不被执行，因为优先考虑应该实现的内容。

4.4 从软件生态系统的角度来看

另一个有趣的发现是，架构没有清晰地考虑汽车工程所特有的高度复杂的供应商网络。

在之前的一项研究[32，33]中，我们发现目前缺少一种跨价值链调整工作的整体策略。具体来说，混合商品和差异性部件会导致次优情况，导致重复工作（与[34]一致的观察结果）。我们认为，汽车架构需要从整体上考虑整个价值链，并优化架构以促进有益的分包商交互。

-商品性部件需要明确定义的技术和组织接口。目标是尽可能有效地开发它们，从而减少协调开销。理想情况下，现货商品部件可以以最小的调整进行集成。

-差异性部件应该尽可能独立于商品化部件，可能在内部开发。

-创新性部件自然需要许多合作伙伴之间的协调和迭代工作。为了有效地激发和发展创新行为，应该建立适当的沟通手段。

在传统的软件工程中，软件产品通常是单个独立软件供应商努力的结果，投资于创建一个整体的产品[35，36]。现代软件工程严重依赖于第三方供应商或开源供应商提供的组件和基础设施[35，36]。软件生态系统（SECOs）的出现是软件行业最近的一个发展趋势[36，37]。它意味着从封闭的组织向开放的结构的转变，在这种结构中，外部参与者参与开发以创造竞争力价值[35，37]。

基于生态系统分类模型[35]，我们将汽车价值链理解为汽车供应商之间跨组织协作的生态系统[38]。在这个生态系统中，原始设备制造商（OEM）扮演着生态系统协调者的角色。这个生态系统是私有的，参与者名单是经过筛选的。

汽车生态系统的特点是严重依赖复杂的供应商网络，并严重依赖硬件和软件开发[38]。由于网络部件的数量不断增加，复杂性已经达到了传统开发流程[39]难以处理的程度。汽车行业通过从硬件、部件驱动到需求和功能驱动的开发过程的模式转换，以及严格的基础设施元素标准化，解决了这个问题。

汽车开放系统架构（AUTOSAR）标准的主要目标是搞定日益复杂的汽车电子架构[40]。我们将AUTOSAR生态系统称为汽车生态系统的一个子集，在这里，不同的参与者通过基于AUTOSAR标准定义的技术平台交换产品和服务来参与创造价值（即软件组件的开发）。

在汽车领域[41]中报告了几个具有挑战性的方面，其中就包括需求工程。OEMs和供应商需要根据需求文档来沟通需求，而现在的需求文档是不精确和不完整的。在这方面，[42]中的工作报告说，需求价值链在软件项目之外很少被理解。在软件项目和产品[42]之间相互依赖的利益相关者之间，哪些需求的沟通、协作和决策制定的原则促进了高效、价值创造和利益的持续一致，这一点还不清楚。这是很重要的一点，因为软件生态系统SECOs利益相关者的利益和期望的沟通方式对于成功地影响利益相关者，使他们能够构想出满足他们需求的未来解决方案至关重要。需要强调的是，在汽车领域，沟通、协作和决策制定是与需求观点和需求工程相关的跨组织挑战。

5.沃尔沃汽车的架构框架

定义架构框架的起点是确定框架域中已建立的利益相关者。利益相关者可以是个人、团队、组织或分类（个人、团队或组织的），而关注点可以是细颗粒度的，也可以是范围非常广泛的[11]。

5.1 利益相关者

表1描述了我们通过与沃尔沃汽车软件架构师的专门会议确定了主要利益相关者；它们分为五大类：

-电气系统的终端用户，如司机和乘客

-客户利益相关者，例如依赖于电气系统（即汽车）的产品和服务的付费客户和产品规划人员，他们获取电气系统作为整体产品的一部分。

-负责计划、长期质量、团队、部门和预算的管理人员。

-电气系统的开发人员包括整个价值链的工程师，他们创建电气系统、架构，以及测试和集成各种组件的必要工具。

-电气系统的维护人员，在电气系统的整个生命周期中与之相互作用。

表1. 利益相关者概览

然后，我们利用已确定的利益相关者来确定架构框架将关注的关注点集。这将帮助架构框架、视图以及连接的建模工具的用户理解他们为什么建模以及什么时候建模。

5.2 具有挑战性的场景

为了定义利益相关者的关注点，我们通过一些由来自不同公司和大学的汽车工程和架构专家组成的小组，确定了一组具有挑战性的场景。然后对这些场景进行了细化，以定义架构框架及其观点。图2给出了与我们将在本文中详细介绍的观点密切相关的场景的概览。下面将描述这些场景。

图2. 具有挑战性的场景概览

-场景1 决策管理 旨在探索如何制定、沟通和管理决策。

用户故事：“作为开发生态系统的一员，我希望能够清楚地理解如何做出决策以及如何进行沟通。”

有趣的子场景包括：

-需求（1.1）：如果过早地对需求进行决策，将会导致不必要的变更。

用户故事：“作为一个负责任的‘组件’，我需要编写一个需求。目前，我被迫将需求写在某个文档或某个结构中。这决定了需求是指硬件组件还是软件组件、它是由内部实现还是由外部供应商实现。通常，现在做出这样的决策还为时过早，当更多的信息变得可用时，就需要进行更改。这么早做决定让我觉得不舒服。”

-架构（1.2）：架构决策制定包括做出正确的决策、与之沟通、确保遵循它，以及在需要时更改它。

用户故事：“作为架构师（{系统架构师；功能开发者；低层级架构师}之一），我需要在正确的时间做出正确的决定（即什么时候做决定是有用的，什么时候有必要的信息）。我需要做合理的决定。我需要像性格内向的人来根据现有的数据做出最好的决定，而像性格外向的人来进行沟通。”

-客户功能（1.3）：电气架构是指导客户功能的实现，但不清楚架构如何支持客户功能（关于跟踪和方法）。

用户故事：“作为一名产品经理，我希望在做客户功能决策时得到电气架构的支持。根据市场分析部门的愿望清单，我与设计系统的部门进行了对话。对于这项任务，我希望电气架构不仅考虑到非功能方面，还考虑到客户功能的本质（随时间而变化）。”

-变更管理（1.4）：良好的架构灵活性允许我们不断地去除设想，甚至在过程的后期进行变更。然而，在‘电气弱相关’架构中，由于技术上的依赖，这些变更会影响电气系统的稳定性。

用户故事：“作为一名产品规划人员，我希望有一个灵活的变更管理过程，允许我在过程后期更改或添加功能，通常以去除设想（把原来未定的设计构想，变为确定项。冷酷的冬瓜注）为目标。这包括例如在过程的后期定义和更改针对ECU的功能分配。

-场景2 定义/发展架构 探索电气架构的长远发展。包括：

-长期采购决策对逻辑架构的影响（2.1）：长期采购合同允许优化生产成本，但限制了架构的发展。

用户故事：“作为一名功能开发人员，我希望在不考虑采购协议的情况下进行功能演变的优化。今天，我必须提前两年或两年以上与产品规划人员讨论某个功能的计划，来对现有的合同作出反映，例如，什么时间、以不同的时间间隔采购相关控制器节点。问题在于，这样一来采购的需求使物理布局主导了逻辑架构（决策）。

-架构和设计朝着不同方向发展的危险（2.2）：如果不积极管理，架构和设计会随着时间的推移而产生分歧。这样，架构就会被认为是过时和无用的，从而失去了指导设计决策和实现的能力。

用户故事：“作为一个系统架构师或功能开发人员，我希望架构和设计之间有严格的相关性。否则，其中一个就是错的。（架构和设计之间有严格的映射关系，如果出现偏差，那么证明其中一个是错的。冷酷的冬瓜注）”

-场景3 架构的灵活性 解决了强调电气架构灵活性的不同场景，包括技术层面和流程层面。在技术层面，ECUs更大的容量允许较晚增加功能特性。在流程层面，需要跨多个合作伙伴管理可用的资源。

-从流程的角度进行应用的工作负荷管理（3.1）：

用户故事：“作为一名功能开发人员，我希望在应用的工作负荷方面更加灵活。供应商应该能够在整个生命周期中动态地获取和返回资源。这将允许更快地从设想转向决策，并允许根据需要改变决策。”

-从技术角度进行应用的工作负荷管理（3.2）：ECUs和总线的更高容量将促进推延甚至非常晚的更新（即车辆已经上路之后），因为新功能可能会使用更多资源（这个地方的资源可能更多是指开发阶段越靠后、获取的能够用来做决策的信息越多。冷酷的冬瓜注）。这种灵活性是有代价的，要理解平衡点在哪里并非易事。

用户故事：“作为一名系统架构师，我希望平衡ECU和总线的容量与成本，以确保以一种经济上可行的方式进行‘未来打样’。”

-容易且安全的附加组件（3.3）：能够以安全且容易的方式添加新功能将使得我们在某种程度上能够将软件开发从整车开发周期中分离出来。在整车的开发过程中，OEM可以专注于关键的基本功能。为用户带来便利的功能，以及更先进的连接功能可以独立地、在SOP的时候再释放。这将使我们能够更持续地开发，并在[44]之前观察到的关键截止日期之前减少故障报告的峰值。

用户故事：“作为一名功能开发人员，我希望能够（在很晚的时候）添加新功能。这些附加组件可以来自第三方，即使在车辆投入使用后也能够添加。这样我就可以避免在生产开始之前进行大爆炸式的集成。”

-关注点分离（3.4）：

用户故事：“作为一个系统架构师，我想在两个层面上平衡关注点的分离：域的层面（例如安全域 vs.信息娱乐域）和抽象层面（例如架构愿景 vs.架构实现）。这样，我就授权开发人员在架构的约束下做出决策，并在他们的工作环境中应用适当的开发方法（例如，安全性 vs.非安全性）。”（关注点的分离手段之一是不是就是各司其职？架构师规定好价值链中各利益相关者的职责与权力？冷酷的冬瓜注）

-灵活的功能（3.5）：

用户故事：“作为一名功能开发人员，我希望能够灵活处理汽车中运行的功能，并允许在非常晚的时候进行部署。因此，我获得了实现特定客户功能的灵活性和较短的上市时间。”

-场景4 持续的部署和透明度 包括：

-在汽车生态系统的不同价值链中需要开放和透明的信息（4.1）：价值链的良好透明度支持灵活性，因为所有的合作伙伴都可以采取适当的行动来快速实现（变化的）目标。不确定性锥就是一个很好的例子[45，46]：在项目的开始，可用的数据很少，决策也很不确定。在汽车领域也是如此，在那里架构设计工作从一个已经存在的系统开始——通常是先前车型系列的架构——开发人员试图在不做太多改变的情况下对其进行增强，以减少风险。随着项目的进展，设想被去除，不确定性减少了，但结果是，做出变化很大的决策变得更加困难。良好的透明度有助于更快地减少不确定性，并允许我们快速地学习并做出决定。

用户故事：“作为电气系统的开发人员（内部或外部），我希望能够接触到相关决策、相关设想的状态以及开发过程中产生的知识。这使我能够参与整个价值链的快速学习，并使我在工作中变得有效和灵活。”（价值链上的参与者都能接触到很多核心的决策信息。冷酷的冬瓜注）

-使用这些信息来持续改进一个持续集成、交付和部署流的需求（4.2）：跨组织的持续集成、交付和部署促进了快速反馈和丰富的学习。这种学习还应该有助于改进组织之间的交互和它们之间的集成流。在OEM和合作伙伴之间创建和维护持续改进的文化也是必要的，例如，通过在（共享的）CD工具链上应用持续部署。

用户故事：“作为一名项目经理，我希望在OEM和价值链合作伙伴之间建立一种持续改进的文化。作为电气系统（内部和外部）的开发人员，我希望能够从持续的交付流程中受益并承担起改进的责任。”

-建立短反馈周期的需要（4.3）：在开发新功能、基础软件和硬件时，应该计划如何接收反馈、收集哪些数据以及如何在开发中使用反馈。

用户故事：“作为任何电气系统的开发人员（内部或外部），我希望快速反馈我的工作将如何在不同层次的集成过程中工作。作为一名功能开发人员，我希望拥有快速且明确的反馈周期。作为一名测试人员，我希望快速更新所有级别的测试并持续改进功能。这将允许在汽车开发中大规模地从持续集成中获益（例如，提高质量和更快的整体开发）。”

-场景5 车辆作为一个体系（SoS）的组成部分 包括：

-可靠通信的需要（5.1）：要使车辆成为体系（SoS）的组成部分，车辆需要连接到其他车辆、基础设施、云，以及SoS的任何其他组成系统。很可能汽车将通过不同的通信手段和不同程度的服务质量进行连接。

用户故事：“作为一名架构师，我需要对车辆进行工程设计，使其能够支持具有不同服务质量（QoS）的异构通信手段。应该明确区分不同通信手段的QoS，以便有可能开发出超越汽车边界的端到端功能。

-确保正确理解车与车之间的通信（5.2）：仅有适当的通信手段是不够的：交换的信息应该被所有相关的部分正确理解（统一的应用层协议。冷酷的冬瓜注）。

用户故事：“作为一名架构师，我需要确保汽车和SoS其他组成系统之间的高度互操作性。超越汽车边界的端到端功能可能需要在这样的设想下构建：交换的信息得到了适当的理解，接收系统采取了必要的动作。”

-自动程度和为SoS服务的准备程度（5.3）：SoS场景通常要求车辆有一定程度的自主性。此外，往往一个组成系统不得不暂时牺牲自己的目标，采取必要的行动，以实现SoS的目标。

用户故事：“作为一名架构师，我需要管理汽车向自主行为的转变，这是实现SoS目标所必需的。汽车应该被设计成，通常是立即，暂时停止正在做的事情，并执行SoS要求的动作。需要在车辆的独立性（不受SoS的影响）和向SoS提供的服务之间找到正确的平衡。（来自自身和来自SoS请求的优先级。冷酷的冬瓜注）”

-处理不确定性和功能安全（5.4）：车辆开始从环境中接收大量信息，因为通信来自其他车辆、行人、道路信号和整个城市。这些信息对于支持新的安全行为[47]可能是宝贵的。然而，这些信息往往是不可靠的，并受到不同程度的不确定性的影响，如其他组成系统的存在、通信手段等。

用户故事：“作为一名架构师，我希望支持创新和非常有前景的安全方案，包括自行车、行人等。然而，这意味着功能安全的保障方式应该改变，因为SoS是开放的（组成系统可能随时加入或离开SoS），我们不能100%依赖于由不可控和独立的系统组成发送的信息。”

-网络安全和隐私（5.5）：一旦汽车联网，它就会像任何其他连接到互联网的计算机或设备一样受到攻击。其后果可能是悲剧性的。

用户故事：“作为一名架构师，我需要保护汽车免受攻击，以避免危险或灾难性的场景，并确保用户数据的隐私。”

5.3 对架构框架的影响

确定的架构相关的关注点决定了要包含的观点和视图的选择。需要注意的是，几乎每个观点所涉及的概念都已经在沃尔沃汽车的当前架构中得到了处理。然而，我们正在研究正确观点的定义，这些观点将根据ISO 42010国际标准[3]创建架构框架。第2节中总结的大部分观点对沃尔沃汽车来说确实也很有趣。除了这些观点之外，我们还预见了一组来自汽车领域的新挑战的观点，如第4节所解释的，并通过上面描述的场景进行了说明。以下列出了新的观点：然后，由于论文篇幅有限，我们将重点关注三个最具挑战性的问题：

-持续集成和部署（详见第6节）——OEMs越来越有兴趣减少开发时间，增加灵活性，对决策进行早期反馈，甚至在生产后逐步增加新功能。

-生态系统和透明度（详见第7节）——在某种程度上与价值网络观点有关，这在AAF中只是简单地概述了一下[4，21]。围绕OEM的生态系统可以看作是一个虚拟组织，由OEM、供应商和其他参与创造客户价值过程的合作伙伴组成。

-体系（SoS）观点：车辆的视角（详见第8节）——车辆之间的协作和互联的未来场景对车辆架构提出了新的挑战。这个观点的目的是为了理解：为了设计一辆体系（SoS）的组成部分的汽车，架构应该如何改变。

-自动驾驶汽车——自动驾驶汽车需要特殊的架构解决方案，例如，受自动和自适应系统[48]的启发。

-模式管理——需要一个模式观点来设计车辆的不同模式以及从一种模式到另一种模式的转换。

-可以考虑特殊的观点和视图，以便向开发人员和其他利益相关者传播和交流架构，如第4.2节所讨论的。

在架构描述中使用多观点和视图的自然结果是需要表达这些视图之间的相关性和一致性规则。[3]中引入的机制称为模型对应，它允许定义两个或多个架构模型之间的关系。由于架构视图是由架构模型[3]组成的，所以可以使用模型对应来关联视图，以表达一致性、可跟踪性、提炼或其他依赖关系[11]。这些机制允许架构师在模型类之间施加约束，并检查架构是否满足这些约束。

6.持续集成和部署的观点

6.1 持续集成和部署

“持续集成和部署”的观点为系统架构增加了一个开发视角，旨在回答以下问题：

1. 汽车工程中的持续集成和部署实践如何影响系统架构？

2. 系统架构中的架构决策如何影响持续集成和部署实践？

6.2 概述

敏捷开发方法和实践，如持续集成和部署，可以帮助减少开发时间，增加灵活性，并通常缩短反馈周期，从而可以更好地管理复杂的系统知识。然而，复杂的供应商网络（参见第7节中的生态系统和透明度观点），以及典型的带有大量ECUs的设置，对这些实践构成了特定的挑战，包括安全问题和复杂的依赖关系。

对持续部署的支持必须面对安全问题。这方面的一个例子是，在运行时是否可以修改或更新负责安全关键功能的ECU上运行的软件。这可能是可取的，例如，当更好的自动驾驶算法出现时。

ECU之间的依赖关系是架构的一个属性。正如第4.1节所提到的，实现的架构可能与预期的架构不同，而软件的持续集成和部署可能会导致架构更改。这突出了在不同架构层次上工作的组织部分之间的协作的需要，以及对敏捷和灵活的架构恰当支持的需要，这引起了两个主要问题：（i）一个是关于架构作为持续集成和部署的推动者，促进更新的变型的处理和协调：（ii）另一个是关于架构级别的持续集成和部署，促进对架构本身的修改的推理。（一正一反。冷酷的冬瓜注）

6.3 关注点和利益相关者

6.3.1 关注点

在本节中，我们将重点讨论在为汽车设计软件时支持持续集成和部署所必需的关注点。我们按照ISO/IEC/IEEE 42010标准提出的问题的形式表达了我们的关注点。

-我们如何才能避免搭建错误的架构？即使是一个技术健全的架构，如果不符合既定的目的，也是毫无价值的。当然，系统架构需要在考虑的产品被开发出来并进入市场之前很久就存在，因为它需要指导开发活动的组织。尽管在产品生命周期的早期需要大量的信息，但是只有在产品开发过程中和早期市场阶段才会有大量的信息可用。

-我们如何减少架构设想的数量？预先定义的架构越多，它就越基于设想而不是事实。这可能会导致延迟的更改、重复的工作，或者在最坏的情况下，只在产品上市后才会出现问题。

-一个系统如何才能对市场的变化做出更快的反应？一旦产品发布，许多设想都会涉及到市场情况。然而，市场容易发生持续的变化，这种变化可能会使软件开发过程中的架构决策失效。

-我们如何处理接口的变化？应对市场的变化将导致后期架构的变化，进而会影响持续集成和部署：不可能将一个组件集成到系统后再进行界面更改，除非这个平台和其他相关组件已经被调整到新界面。因此，接口更改后的部署可能涉及大量更新的组件，这些组件不可能以连续的方式进行部署。换句话说，在接口更改之后，很难保证所有组件的主要分支都处于可部署状态。

-我们如何处理依赖关系？依赖关系可能需要团队之间额外的协调工作，这可能会降低甚至阻碍持续的集成和部署。依赖关系有两种类型，显式依赖项和隐式依赖项。显式依赖关系由预期的架构覆盖，可以在持续的系统演化过程中进行适当的管理、监视和更新。隐式依赖项应该被正确地识别，并尽可能地减少，如下所示。那些不受欢迎的隐式依赖关系（例如，那些违反重要的架构约束的依赖关系）应该被删除。其余的应该明确。

6.3.2 典型的利益相关者

对于持续集成和部署的观点，我们需要考虑第5节中描述的和表1中总结的所有利益相关者。此外，我们需要考虑供应商，因为持续的集成和部署将取决于他们的交付（参见下一节中的生态系统和透明度观点）。

6.4 用于持续集成和部署的模型类

[49]中已经提出了各种表示法来针对持续集成和部署管道进行建模。其中，有几个可以适用于这一观点。此外，还需要将它们与架构方法以及上面定义的关注点联系起来。我们目前正在研究一种定性评估方法，这种方法将使我们能够确定持续集成和部署的干扰因素和瓶颈。CI视图（CodeIgniter View？冷酷的冬瓜注冬瓜注）将详细说明如何避免中断或不必要的减速。此外，它将是一个理想的建模表示法，能够捕获和可视化依赖关系。需要进一步的研究来了解最适合这个观点的模型类。

Grubb和Chechik使用扩展的目标模型[50]对系统演化进行建模。他们的方法允许对在系统演进过程中所实现的扩展利益相关者目标进行推理。我们计划研究这种技术是否能够提供一种合适的模型类，例如，在什么时间点上持续集成成为可能，以及在开发过程中架构对连续架构的影响。通过这一点，我们期望系统架构、流程和组织之间的依赖关系变得更加明确，并且能够在支持业务目标方面得到更好的优化。

6.5 操作视图

操作视图应该处理此观点的两个主要关注点：（i）通过架构支持持续集成和部署，以及（ii）支持架构级别上的持续集成和部署。作为第一组操作的示例，我们提到了用于识别和删除不需要的隐式依赖项的方法。此外，需要适当的操作来维护、监视和根据系统演化更新显式依赖项。

作为第二组的示例，我们提到了识别和显示对系统架构有影响的系统演进的操作。具体来说，这些操作应该通过在执行部署之前强调变更对整体架构的影响以及对架构约束的潜在违背来支持开发人员。当更改对非功能属性（如性能[51]）造成影响时，这可能会特别复杂（因为前期的硬件、结构设计可能支撑不了这种变更。冷酷的冬瓜注）。

最后，还应该提供操作来评估架构描述和决策。例如，可以定义分析方法来评估反馈周期在持续集成和部署中的效率，以及它帮助解决设想的能力。

6.6 对应规则

该观点与功能安全、安全与防护、隐私以及本文提出的新观点“生态系统和透明度”等观点是一致的。当持续集成和部署涉及到生态系统中其他参与者的工作时，需要考虑后者。

7.生态系统和透明度观点

7.1 生态系统和透明度

“生态系统和透明度”的观点关注硬件和软件的价值链，以及架构的逻辑组件，旨在回答以下问题：

1. 电气架构如何使组织网络（包括OEM、一级供应商、二级供应商）协同工作（持续地）提供价值？

2. 在价值链中透明和持续的协作需求如何影响架构决策？

7.2 概述

生态系统和透明度观点考虑了汽车工程中的架构资产，这些资产是基于复杂的合作组织网络提供的。架构中的逻辑组件将由各种物理组件实现，包括在不同抽象级别上的硬件和软件。

在一个具体的场景中，一个逻辑组件可以部署在几个AUTOSAR ECU上。此场景中的硬件将由不同的一级供应商提供，而AUTOSAR层将由一个或多个经过认证的AUTOSAR供应商提供。这些AUTOSAR供应商可以被描述为二级供应商，因为它们与一级供应商签订了合同，后者应该交付带有基本软件的ECU，但是可以进行不同的设置。在这些ECU之上，应用软件将由OEM或独立的软件供应商开发，以提供由逻辑组件定义的服务。

上面的场景示例显示了生态系统和透明度观点的重要性：如果一个电气架构应该考虑战略性的业务目标，例如改进灵活性、减少上市时间或开发效率，那么生态系统和透明度观点将提供必须考虑的重要信息。这种观点与业务决策和长期运行的采购合同有关，但也与市场软件更新后的新业务模型有关。因此，我们期望硬件和软件组件的生命周期是重要的架构方面，和管理供应商和组件的不同开发周期一样重要。

7.3 关注点和利益相关者

7.3.1 关注点

在本节中，我们将重点讨论在汽车电气系统的生态系统中实现高效工作所必需的关注点。

-给定的系统架构隐含了哪些类型的价值链，它们的目的是什么？一个给定的系统架构将定义不同类型的逻辑组件之间的相互作用，以支持用户可感知的特性。虽然其中一些特性将被很好地理解和稳定的（稳定的意思是不大会发生变更。冷酷的冬瓜注），但是其他的特性将是高度创新的，它们的开发将受制于不稳定的需求。实现这些逻辑组件的价值链将根据它们所支持的功能类型而彼此不同。

-如何将供应商开发能力映射到由特定系统架构创建的需求？跨价值链的开发需要不同的功能，这取决于特性的类型。系统架构可能能够将生态系统中关键创新特性的交互最小化或限制为只支持高度迭代开发的参与者。

-我们如何在价值链中建立所需的透明度水平？特性的需求越不稳定，生态系统参与者之间需要的信息交换就越多。为了能够在整个价值链中持续交付，所有相关的合作伙伴都应该能够访问关键信息，以便他们能够承担责任。在一个不那么动荡的环境中，（法律和组织上的）努力创造高透明度是不会有回报的。

-面对不断变化的供应商，我们如何管理透明度（例如架构决策）？为了维持一个强大的汽车工程生态系统，我们需要能够改变参与者之间的关系。这还将影响透明度的水平（包括共享什么信息以及以什么频率共享）。

7.3.2 典型的利益相关者

对于生态系统和透明度的观点，我们需要考虑不同生态系统参与者中的利益相关者。关于OEM（汽车工程生态系统中的关键参与者），可能第5节中描述的和表1中总结的每个利益相关者都是这个观点的受众。

其他参与者（如一级和二级供应商）将有非常相似的利益相关者需要考虑。

7.4 生态系统和透明度的模型类

由于我们在这篇论文中提出了一个关于生态系统和透明度的新观点，到目前为止还没有确定的建模方法。模型需要提供以下信息：

价值链分析：为了记录不同的价值链，可以创建一个Janssen 等提出的生态系统[52]的（部分）的地图、或单一特定的价值链，例如在我们以前的工作中基于Boucharas等标注[53]的AUTOSAR生态系统[33]。

对参与者和目标的分析：除了关键的价值链之外，还应该维护关于这些链中参与者及其目标的信息。Yu和Franch提出使用目标模型来实现这一目的，这是一种很有前途的方法，可以根据架构决策来调整不同参与者的目标，并实现双赢[54]。当目标是强有力的合作和伙伴关系时，这些是很重要的。（供应商管理，对不同能力程度的供应商采取不同的‘萝卜’管理。冷酷的冬瓜注）

关于匿名参与者的推论：在某种程度上，在创建电气架构时不知道具体的合作伙伴和供应商。在这种情况下，我们提出了一种基于角色的方法，即定义具有重要特征的典型参与者以及他们对生态系统的期望[55，56]。（期望与上一条对应，即目标。冷酷的冬瓜注）

定义透明度需求：Hosseini等人提出了定义透明度需求的框架，这可能是这些方面的良好起点[57，58]。为了在这个观点中得到实际应用，这个框架需要在动态方面进行扩展，例如在伙伴关系结束时提取信息。这也包括所有权和数字版权管理问题，我们希望从其他作品（例如从[59]）借用概念。

7.5 操作视图

有关操作视图的列表，请参阅前一节，即第7.4节。

此外，还应该提供操作来评估架构描述和决策。例如，可以定义分析方法（i）检查生态系统中的双赢情况，（ii）为关键的价值链确定合适的伙伴，（iii）与开发伙伴分析和管理所需的透明度水平。

7.6 对应规则

此观点与其他各种观点（包括安全性、隐私和价值网络）相一致，但也与持续集成和部署相一致，即需要同步不同生态系统参与者的开发周期，以确保快速反馈周期。此外，它还与体系（SoS）观点相一致，例如，如果需要对SoS的几个组成部分进行排列以提供特定的功能。

8.体系（SoS）观点：汽车视角

8.1 体系（SoS）：汽车视角

“体系（SoS）：汽车视角”的观点集中在汽车作为一个体系（SoS）的组成部分。因此，这个观点旨在回答这个问题：如何设计一辆汽车，使之成为一个体系（SoS）的一部分？

8.2 概述

联网汽车将受益于智能交通系统（ITS）、智能城市和物联网，提供智能交通控制、智能队列协调、集体避碰等新的应用场景。车辆将通过传感器收集的数据与来自环境的外部数据，如其他车辆、道路、云等，相结合。

联网汽车将面临安全相关的新挑战和机遇。目前的安全方面的法规，如ISO 26262标准，没有考虑到车辆是更复杂系统的一部分的情况：我们面临的挑战是如何应对来自环境的可能危害安全的新危险。同时，为安全连接汽车打开新的机会，在沃尔沃汽车称为“连接安全”：举例来说，这种新技术将允许联网汽车注意湿滑路面，路上的自行车，等等，并启动所需的所有操作，以避免事故和碰撞。

这些场景对架构设计提出了新的要求。例如，联网汽车安全保障的一个主要问题是，在设计阶段不可能对系统进行全面分析。当从单一车辆转向协同系统时，需要进行新的安全分析来处理运行时的不确定性。已经提出了一些在运行时处理认证的方法，例如[60，61]，但是仍然缺少一个清晰的框架来定义连接的安全需求。

8.3 关注点和利益相关者

8.3.1 关注点

在本节中，我们将重点讨论在汽车体系（SoS）中启用功能所必须考虑的关注点。

-一旦汽车成为SoS的一部分，如何保证功能安全要求？

-一旦汽车成为SoS的一部分，对系统设计和功能分配有什么影响？

-一旦功能安全要求涉及车辆外部的装置（SoS的其他组成系统），如何确保这些要求得到保证？

-端到端功能开发和软件持续交付的方法和过程需要如何演进以适应体系（SoS）的设置？

-如何在车辆与其他车辆、道路信号、行人等异构实体之间实现可靠、高效的通信？

-如何确保SoS的车辆及其他组成系统能够交换信息及使用已更改的信息？

-如何保证车辆连接后的安全性？

-如何确定共享数据和用户隐私之间的正确权衡？

-如何在SoS（以及可能的数据复制）中充分更新或同步共享数据？

-如何管理可用信息的实效性？

-车内的哪些功能允许使用来自其他组件的数据？

8.3.2 典型的利益相关者

因为在这个观点中，我们采用了车辆的视角，所以在第5节中描述的和在表1中总结的每一个利益相关者都可能是这个观点的受众的一部分。此外，公司外部的其他利益相关者也应被视为利益相关者。例如SoS、其他OEMs的利益相关者、供应商、道路当局等使用的安全及通讯手段的标准当局。

8.4 汽车作为SoS的组成部分的模型类

没有明显的模型类可以用于这个观点。在文献中有一些尝试，为SoS定义的架构语言（ALs），如[62]或在Atesst项目中所作的努力，然而，为了准确理解属性描述语言（ADL）能否完全满足这个观点和沃尔沃汽车的需求，需要执行深入分析这些语言。初步分析的结果表明，这种语言可能过于正式和沉重。正如[23，28]中所述，通常从业人员不采用ALs，因为他们（i）太复杂，需要专业的能力，（ii）投资回报不够明显，（iii）他们需要超过技术规范的输入，同时从业者没有能力在AL中明确地进行建模设计的决策，及（iv）在软件和系统生命周期中缺乏集成，缺乏成熟的工具，和使用性问题。

这意味着使用的语言应该在公司内部进行定义和/或定制，以便能够准确地实现公司和用户的需求，同时可以与公司的生命周期相集成。根据特定需求定制现有ALs的有趣方法可以在[63]中找到。

这个观点的模型类应该支持以下概念的规范，这些概念是设计一辆将成为体系（SoS）的一部分的汽车的基本构件。这些构建块已在NGEA项目中确定，并记录在可交付的D3.2 SoS车型概念中。

-通信渠道的异构性：今天的汽车已经使用几个通信渠道与其他系统进行通信。通信手段还包括GPS接收器、声音信号、可视制动灯、转向指示灯等，可以用来向其他系统传达驾驶员的意图，还包括摄像头，可以检测其他车辆的意图或读取路标，然后高亮显示给驾驶员。在不久的将来，我们可以期待几个新的通信渠道。例如IMT2020 （5G）——LTE （4G）移动网络的继承者，车车通信（V2V）和车辆对基础设施（V2I）——基于IEEE 802.11p的通信，BLE（低功耗蓝牙），单个或少数供应商使用的专有通信通道，标准WiFi版本等。

-连接性：在SoS的不同地方，连接性对于实现预期的服务水平至关重要。可以通过许多不同的通道进行连接，如前一项中讨论的那样。然而，当连接性受到限制或根本不可用时，必须有处理服务降级的车载功能。用户将体验到功能的鲁棒性。必须向用户充分明确数据和功能的服务质量。可接受的QoS通常需要非常好的连接性和实时信息的可用性。然而，由于不能总是保证连接，所以通常需要其他形式的后备解决方案或冗余。特定位置和时间可用的QoS需要以一种用户友好、易于掌握的方式传达给用户。

-大而不可靠的信息：低质量的信息可能会导致灾难性的事件，特别是当功能的实现严重依赖于外部信息时。因此，确定接收到的信息的在正确性和及时性方面是否是否具备高质量是非常重要的。多传感器数据融合通过结合来自传感器的感知数据来提供答案，从而使结果信息更加可靠。

-互操作性：互操作性是不同系统协同工作的能力。根据参考应用领域和描述它们的许多不同因素和方面，这个通用定义以许多不同的方式结合在一起。互操作性涉及标准、协议以及接口的集成和调整，以支持组成系统之间的有效和高效通信。互操作性是SoS中两个或多个组成系统交换信息和使用已交换信息的能力。系统间共享数据的明确解释对于互操作是必要的，但还不够。尽管共享数据标准提供了以增强功能和互操作性为目标的规范，但使用这些标准编码的数据不一定是可互操作的。例如，具有相同标签、甚至具有相同含义的概念可以在不同的应用程序中完全不同地使用。例如，车辆内部的速度可以有不同的含义。

-网络安全和隐私：汽车的互联性对安全和隐私都提出了挑战，因为汽车会像任何其他连接到互联网的设备一样暴露出来。一个与安全风险相关的典型例子是2015年一辆吉普车被黑客攻击[64]。由于涉及到隐私，汽车将需要共享几个信息来使能有希望的SoS场景，但敏感的信息应该得到适当的保护。（使能功能 Vs. 保护隐私。冷酷的冬瓜注）

-分布式端到端功能：端到端功能不仅要在车辆节点之间提供，还要在车辆外部提供，然后涉及SoS的其他组成系统，如云、其他车辆、行人、道路基础设施和信号等。联网车辆可以从基于云计算的数据和服务中获益良多。以分布式端到端功能实现的服务将受益于将软件动态加载到车载电气架构的可能性。动态加载的软件可以在一个或多个物理节点上执行，这将在网络安全、功能安全和兼容性方面带来挑战。

-功能安全：功能安全要求适用于车外的功能。为了能够处理安全，一旦汽车成为一个组成系统的SoS，人们可以期待的操作和关键功能将得到保护。然而，连接安全则将关系到汽车的整体安全。一个典型的例子是，一辆汽车从另一辆受信任的车辆报告的云上接收关于街上一些冰的信息。这些类型的场景可能隐含地让汽车驾驶员产生期望，他们将开始依赖于服务，而服务又依赖于潜在的不可控连接、设备、传感器等。

8.5 操作视图

模型驱动工程（MDE）技术提供了有趣的功能来定义新的模型类[28]或对现有模型进行调优和自定义[63]。MDE技术通常依赖于表示模型类概念的元模型的定义。然后视图可以被看作是必须符合观点规则和约束的模型，即模型（视图）应该符合元模型（观点）。感兴趣的读者可以在[65，66]中找到更多的信息。

其他操作应该帮助和指导用户解释视图。研究的出发点应该是准确地理解用户和视图的目的。然后，本研究将定义用于该语言的语法（例如，图形化、文本化、树形）的要求。还应该提供操作来评估架构描述和决策。例如，可以定义分析方法来评估互操作性水平、系统处理通信通道异构性的能力、安全性和优先级（当汽车成为SoS的一部分时）等。最后，通过帮助设计和构建系统的方法，将视图连接到软件和系统生命周期。

8.6 对应规则

这个观点与其他各种观点相一致，包括功能安全、安全、隐私，以及其他的SoS观点，这些观点关注于整体SoS的工程。此外，该观点还与拓扑结构、成本、可变性、持续集成和部署以及生态系统和透明度相对应。

9.讨论及总结

在这篇论文中，我们描述了目前沃尔沃汽车对于架构框架定义的研究。在这一阶段，我们将根据我们在汽车领域的共同经验，以及一系列与广泛领域专家进行重要概念识别和验证的研讨会，来确定未来汽车的潜在观点。具体来说，我们提出了与架构相关的未来需求的具有挑战性的场景，并提出了三个新观点（持续集成和部署、生态系统和透明度、体系（SoS））。对于每一个观点，我们开始收集它们各自观点的实际需求和用户。基于这些，未来的工作需要确定用于描述架构的最合适的建模语言。对于这些建模语言，重要的是要在一种语言的（i）支持正式程度的能力或者是（ii）可以向利益相关者传达正确的信息并促进协作的直观信息的简单性，和严格的开发过程要求的精确性之间找到合适的平衡点。我们计划对架构框架进行评估，通过付诸实践、与沃尔沃汽车内部的架构师进行定性评估、以及使用ATAM（架构权衡分析方法）[67]方法来评估我们的架构关于已识别的质量属性目标。

在一个持续的架构环境中，我们期望观点、利益相关者、关注点等等会随时间而改变。然后，应该进行持续的评估，以理解利益相关者和关注点的改变是否应该反过来触发架构的改变。当架构发生变化时，应该对架构的新版本进行适当的文档记录；这将意味着另一个架构描述，这是因为42010标准[3]的规则就是用一个架构描述来表达一个架构。随着架构的发展，在旧的和新的、预期的和已实现的以及其他类型的转换之间建立链接或提供一些可跟踪性也是有益的。同样的思路也适用于演变的观点：当利益相关者和关注点发生变化时，所使用的观点可能会发生变化，应该利用相应规则来记录什么变了，什么没变，等等。

关于架构框架的实现，我们将研究MEGAF[65，66]，这是一个基础设施，使软件架构师能够意识到自己的架构框架，专门针对特定的应用领域或利益相关者社区，并符合ISO/IEC/IEEE 42010标准[3]。

参考文献

[1] Peter van Staa, How KETs can contribute to the re-industrialisation of Europe, European Technology Congress, Wrocław, June 12–13, 2014:, 2014.

http://docplayer.net/21724658-Date-2012-how-kets-can-contribute-to-the-reindustrialisation-of-europe.html.

[2] P. Pelliccione, E. Knauss, R. Heldal, M. Agren, ˚ P. Mallozzi, A. Alminger, D. Borgentun, A proposal for an automotive architecture framework for Volvo Cars,

in: 2016 Workshop on Automotive Systems/Software Architectures (WASA),

2016, pp. 18–21, doi:10.1109/WASA.2016.9.

[3] ISO/IEC/IEEE 42010, systems and software engineering — architecture description, ISO/IEC/IEEE, 2011.

[4] M. Broy, M. Gleirscher, S. Merenda, D. Wild, P. Kluge, W. Krenzer, Toward a

holistic and standardized automotive architecture description, Computer 42

(12) (2009) 98–101. http://doi.ieeecomputersociety.org/10.1109/MC.2009.413.

[5] Y. Dajsuren, On the Design of an Architecture Framework and Quality Evaluation for Automotive Software Systems, PhD thesis, Technische Universiteit

Eindhoven, 2015.

[6] A. Finkelstein, J. Kramer, B. Nuseibeh, L. Finkelstein, M. Goedicke, Viewpoints:

a framework for integrating multiple perspectives in system development, Int.

J. Softw. Eng. Knowl. Eng. 2 (1) (1992).

[7] P.B. Kruchten, The 4 1 view model of architecture, IEEE Softw. 12 (6) (1995).

[8] N. Rozanski, E. Woods, Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley Professional,

2005.

[9] P. Clements, F. Bachmann, L. Bass, D. Garlan, J. Ivers, R. Little, R. Nord,

J. Stafford, Documenting Software Architectures: Views and Beyond, Addison-Wesley, 2003.

[10] P. Eeles, P. Cripps, The Process of Software Architecting, Addison Wesley, 2010.

[11] D. Emery, R. Hilliard, Every architecture description needs a framework: expressing architecture frameworks using ISO/IEC 42010, WICSA/ECSA 2009,

2009.

[12] ISO, ISO 15704 industrial automation systems ? Requirements for enterprisereference architectures and methodologies, 2000,

[13] U.D.D.C.I. Officer, US department of defense architecture framework, version 2.02, August 2010:http://dodcio.defense.gov/Portals/0/Documents/DODAF/

DoDAF_v2-02_web.pdf, 2010,

[14] O. Group, The open group architectural framework (TOGAF), version 9.1, December 2011:http://www.opengroup.org/subjectareas/enterprise/togaf, 2011.

[15] M. of Defence UK, MOD architecture framework (MODAF), version 9.1, December 2012:https://www.gov.uk/guidance/mod-architecture-framework, 2012.

[16] ISO/IEC-JTC1/SC7-WG42, Survey of architecture frameworks,

[17] D.A. Marca, C.L. McGowan, SADT: Structured Analysis and Design Technique,

McGraw-Hill, Inc., New York, NY, USA, 1987.

[18] G. Booch, J. Rumbaugh, I. Jacobson, Unified Modeling Language User Guide,

The (2Nd Edition) (Addison-Wesley Object Technology Series), Addison-Wesley

Professional, 2005.

[19] P. Cuenot, P. Frey, R. Johansson, H. Lönn, Y. Papadopoulos, M.-O. Reiser,

A. Sandberg, D. Servat, R.T. Kolagari, M. Törngren, M. Weber, The east-adl architecture description language for automotive embedded software, in: Proceedings of MBEERTS’07, Springer-Verlag, 2010, pp. 297–307.

[20] S. Friedenthal, A. Moore, R. Steiner, A Practical Guide to SysML: Systems Modeling Language, Morgan Kaufmann Publishers Inc., San Francisco, CA, USA,

2008.

[21] M. Broy, M. Gleirscher, P. Kluge, W. Krenzer, S. Merenda, D. Wild, Automotive

Architecture Framework: Towards a Holistic and Standardised System Architecture Description, Technical Report, 2009.

[22] H.G.C. Góngora, T. Gaudré, S. Tucci-Piergiovanni, Towards an architectural design framework for automotive systems development, in: Complex Systems

Design & Management, Springer Berlin Heidelberg, 2013, pp. 241–258, doi:10.

1007/978-3-642-34404-6_16.

[23] I. Malavolta, P. Lago, H. Muccini, P. Pelliccione, A. Tang, What industry needs

from architectural languages: a survey, IEEE Trans. Softw. Eng. 39 (6) (2013)

25. http://doi.ieeecomputersociety.org/10.1109/TSE.2012.74.

[24] N. Medvidovic, R.N. Taylor, A classification and comparison framework for software architecture description languages, IEEE Trans. Softw. Eng. 26 (1) (2000).

[25] M.V. M. Rappl P. Braun, C. Schröder, Automotive software development: a

model based approach, World Congress of Automotive Engineers, SAE Technical Paper Series 2002-01-0875, 2002.

[26] U. Eliasson, R. Heldal, P. Pelliccione, J. Lantz, Architecting in the automotive domain: descriptive vs. prescriptive architecture, in: Proceedings of WICSA2015,

2015, pp. 115–118, doi:10.1109/WICSA.2015.18.

[27] R. Heldal, P. Pelliccione, U. Eliasson, J. Lantz, J. Derehag, J. Whittle, Descriptive

vs. prescriptive models in industry, in: ACM/IEEE 19th International Conference

on Model Driven Engineering Languages and Systems (MODELS 2016), 2016.

[28] P. Lago, I. Malavolta, H. Muccini, P. Pelliccione, A. Tang, The road ahead for

architectural languages, Softw. IEEE 32 (1) (2015) 98–105, doi:10.1109/MS.2014.

28.

[29] P. Kruchten, What do software architects really do? J. Syst. Softw. 81 (12)

(2008) 2413–2416, doi:10.1016/j.jss.2008.08.025.

[30] A. Shahrokni, P. Gergely, J. Söderberg, P. Pelliccione, Organic evolution of development organizations-an experience report, 2016. SAE Technical Paper, 2016-

01-0028, doi:10.4271/2016-01-0028.

[31] M. Waterman, J. Noble, G. Allan, How much up-front? A grounded theory of

agile architecture, in: Proceedings of 37th IEEE International Conference on

Software Engineering (ICSE ’15), Florence, Italy, 2015, pp. 347–357.

[32] M. Soltani, E. Knauss, Challenges of requirements engineering in autosar

ecosystems, in: Proceedings of 23rd IEEE International Requirements Engineering Conference, Ottawa, Canada, 2015a.

[33] M. Soltani, E. Knauss, Cross-organizational challenges of requirements engineering in the autosar ecosystem: a case study, in: Proceedings of 5th IEEE International Workshop on Empirical Requirements Engineering, Ottawa, Canada,

2015b. At RE’15

[34] H.H. Olsson, J. Bosch, Strategic ecosystem management: a multi-case study

on challenges and strategies for different ecosystem types, in: Proceedings of

41st Euromicro Conference on Software Engineering and Advanced Applications (SEAA ’15), Funchal, Portugal, 2015.

[35] S. Jansen, M. Cusumano, Defining Software Ecosystems: A Survey of Software

Platforms and Business Network Governance, Edward Elgar Pub, 2013.

[36] K. Wnuk, K. Manikas, P. Runeson, M. Lantz, O. Weijden, H. Munir, Evaluating the governance model of hardware-dependent software ecosystems–a case

study of the axis ecosystem, in: Software Business. Towards Continuous Value

Delivery, Springer, 2014, pp. 212–226.

[37] G.K. Hanssen, A longitudinal case study of an emerging software ecosystem:

implications for practice and theory, J. Syst. Softw. 85 (7) (2012) 1455–1466.

[38] E. Knauss, D. Damian, Towards enabling cross-organizational modeling in automotive ecosystems, in: Proceedings of MD2P2, 2014, pp. 38–47.

[39] H. Fennel, S. Bunzel, H. Heinecke, J. Bielefeld, S. Fürst, K.-P. Schnelle, W. Grote,

N. Maldener, T. Weber, F. Wohlgemuth, et al., Achievements and exploitation

of the autosar development partnership, Convergence 2006 (2006) 10.

[40] S. Fürst, J. Mössinger, S. Bunzel, T. Weber, F. Kirschke-Biller, P. Heitkämper, G. Kinkelin, K. Nishikawa, K. Lange, Autosar–a worldwide standard is

on the road, 14th International VDI Congress Electronic Systems for Vehicles,

Baden-Baden, 62, 2009.

[41] M. Broy, Challenges in automotive software engineering, in: Proceedings of the

28th International Conference on Software Engineering, ACM, 2006, pp. 33–

42.

[42] S. Fricker, Requirements value chains: stakeholder management and requirements engineering in software ecosystems, in: Requirements Engineering:

Foundation for Software Quality, Springer, 2010, pp. 60–66.

[43] S. Fricker, Specification and analysis of requirements negotiation strategy in

software ecosystems., IWSECO@ ICSR, 2009.

[44] N. Mellegård, M. Staron, F. Törner, Why do we not learn from defects? - Towards defect-driven software process improvement, in: Proceedings of the 1st

International Conference on Model-Driven Engineering and Software Development, 2013, pp. 297–303, doi:10.5220/0004345602970303.

[45] S. McConnell, Rapid Development: Taming Wild Software Schedules, 1st, Microsoft Press, Redmond, WA, USA, 1996.

[46] T. Little, Schedule estimation and uncertainty surrounding the cone of uncertainty, IEEE Softw. 23 (3) (2006) 48–54, doi:10.1109/MS.2006.82.

[47] Volvo Cars, Volvo Cars’ connected car program delivers pioneering vision

of safety and convenience, https://www.media.volvocars.com/global/en-gb/

media/pressreleases/159478/volvo-cars-connected-car-program-deliverspioneering-vision-of-safety-and-convenience. 2015.

[48] M. Salehie, L. Tahvildari, Self-adaptive software: landscape and research challenges, ACM Trans. Auton. Adapt. Syst. 4 (2) (2009) 14:1–14:42, doi:10.1145/

1516533.1516538.

[49] D. Ståhl, J. Bosch, Modeling continuous integration practice differences in industry software development, J. Syst. Softw. 87 (2014) 48–59.

[50] A.M. Grubb, M. Chechik, Looking into the crystal ball: requirements evolution

over time, in: Proceedings of 24th IEEE International Requirements Engineering Conference (RE ’16), Bejing, China, 2016, pp. 347–357.

[51] M. Fagerström, E.E. Ismail, G. Liebel, R. Guliani, F. Larsson, K. Nordling,

E. Knauss, P. Pelliccione, Verdict machinery: on the need to automatically make

sense of test results, in: Proceedings of the 25th International Symposium on

Software Testing and Analysis, in: ISSTA 2016, ACM, New York, NY, USA, 2016,

pp. 225–234, doi:10.1145/2931037.2931064.

[52] S. Jansen, S. Brinkkemper, A. Finkelstein, Software Ecosystems: Analyzing and

Managing Business Networks in the Software Industry, Edward Elgar, Cheltenham, UK, pp. 29–42.

[53] V. Boucharas, S. Jansen, S. Brinkkemper, Formalizing software ecosystem modeling, in: Proceedings of the 1st International Workshop on Open Component

Ecosystems, ACM, 2009, pp. 41–50.

[54] X. Franch, A. Susi, E.S. Yu, Business and software ecosystems: how to model,

analyze, and survive!, in: Proceedings of 23rd International Requirements

Engineering Conference (RE ’15), Ottawa, Canada, 2015. Tutorial based on

RISCOSS EU FP7 project

[55] E. Knauss, I. Hammouda, EAM: ecosystemability assessment method, in: Proceedings of 22nd International Requirements Engineering Conference (RE ’14),

Karlskrona, Sweden, 2014, pp. 319–320.

[56] I. Hammouda, E. Knauss, L. Costantini, Continuous api-design for software

ecosystems, in: Proceedings of 2nd International Workshop on Rapid and Continuous Software Engeering (RCoSE ’15 @ ICSE), Florenz, Italy, 2015.

[57] M. Hosseini, A. Shahri, K. Phalp, R. Ali, A modelling language for transparency

requirements in business information systems, in: International Conference on

Advanced Information Systems Engineering, Springer International Publishing,

2016a, pp. 239–254.

[58] M. Hosseini, A. Shahri, K. Phalp, R. Ali, Foundations for transparency requirements engineering, in: Proceedings of 22nd International Working Conference

on Requirements Engineering: Foundation for Software Quality (REFSQ ’16),

Gothenburg, Sweden, 2016b.

[59] A. Averbakh, E. Knauss, S. Kiesling, K. Schneider, Dedicated support for experience sharing in distributed software projects, in: Proceedings of 26th International Conference on Software Engineering and Knowledge Engineering (SEKE

’14), Vancouver BC, Canada, 2014, pp. 355–360.

[60] D. Schneider, M. Trapp, Conditional safety certification of open adaptive systems, ACM Trans. Auton. Adapt. Syst. (TAAS) 8 (2) (2013) 8.

[61] K. Östberg, M. Bengtsson, Run time safety analysis for automotive systems in

an open and adaptive environment, in: Proceedings of SAFECOMP 2013-Workshop ASCoMS, 2013.

[62] F. Oquendo, Formally describing the software architecture of systems-ofsystems with sosadl, in: 2016 11th System of Systems Engineering Conference

(SoSE), 2016, pp. 1–6, doi:10.1109/SYSOSE.2016.7542926.

[63] D. Di Ruscio, I. Malavolta, H. Muccini, P. Pelliccione, A. Pierantonio, Developing

next generation ADLs through MDE techniques, ICSE 2010, 2010.

[64] Andy Greenberg, Hackers remotely kill a jeep on the highway - with me in it,

https://www.wired.com/2015/07/hackers-remotely-kill-jeep-highway/. 2015,

[65] R. Hilliard, I. Malavolta, H. Muccini, P. Pelliccione, Realizing architecture frameworks through megamodelling techniques, in: Proceedings of ASE ’10, ACM,

2010, pp. 305–308, doi:10.1145/1858996.1859057.

[66] R. Hilliard, I. Malavolta, H. Muccini, P. Pelliccione, On the composition and

reuse of viewpoints across architecture frameworks, in: Proceedings of WICSAECSA ’12, IEEE Computer Society, 2012, pp. 131–140, doi:10.1109/WICSA-ECSA.

212.21.

[67] R. Kazman, M. Klein, P. Clements, N.L. Compton, L. Col, ATAM: method for architecture evaluation, 2000

---

本文由 @冷酷的冬瓜 译自《Journal of Systems Architecture》 Volume 77, June 2017, Pages 83-100 的《Automotive Architecture Framework: The experience of Volvo Cars》，需要论文原件的可以在公众号后台回复「论文」获取。

​

冷酷的冬瓜是谁？

一个半吊子汽车电子工程师、一个逗比奶爸；一个自大狂、一个劣质内容输出者。

欢迎来微博找我，让我们一起加速汽车向电动化/网联化/智能化/共享化的转变！

相关精彩推荐：

埃隆·马斯克：特斯拉Model Y的热泵是我见过最好的工程设计之一

狼（堡）烟四起？《经理人杂志》：74号大厅的对决

未来的汽车架构以及IT的发展趋势影响

,