智能汽车软件架构评估方法-ATAM

知圈 | 进“底盘 群”请加微yanzhi-6,备注底盘

软件系统架构的选择对于软件系统开发的成败至关重要，软件架构各种风格各种方法，光分层架构方法就很多，如何评估哪个软件系统架构方法更合适。CMU/SEI（卡梅隆大学软件工程协会）提出了一套架构权衡分析方法，Architecture Tradeoff Analysis Method，简称ATAM。

传统软件架构评估方法按评估形式，一般分为三种。一是调查问卷法，即直接请对系统架构了解的专家学者对系统架构做出主观评估。二是度量法，即将软件系统架构完全量化，通过一些客观的数字指标来评估架构的好坏。三是场景评估法，即挑选出重要的系统使用场景，根据不同场景中各架构的表现分别作评估，ATAM属于场景评估法，主客观程度介于前面两种方法之间。

首先先了解三个概念。

一、软件质量属性

软件质量属性说的是我们评估软件架构，到底评估它的什么特性，一般有如下几个，

二、敏感点和权衡点

敏感点和权衡点都是在软件架构中所做的关键决策，不同的是，敏感点决策只影响一个软件质量属性，而权衡点则同时影响多个质量属性，有时不同属性间还会互相冲突，比如选择不同的加密方式同时影响性能和安全性，所以需要权衡。

三、风险承担者

风险承担者是指那些关心软件架构，个人利益受软件架构好坏影响的人，在项目管理领域也称为项目干系人或涉众。这照些人整体上又可以分为系统的生产者和系统的消费者。生产者包括架构师，开发人员，维护人员，测试人员等；消费者包括客户，最终用户等。

ATAM通过理解体系结构方法来分析体系结构，评估过程分9个步骤：

1、描述ATAM方法

即评估小组负责人向参加会议的风险承担者介绍ATAM评估方法，负责人将解释评估的原则、评估的方案及目标（例如：那些质量特性应该优先考虑）。

2、描述业务动机

从业务角度介绍系统的概况，一般包括业务环境，背景，业务约束条件，技术约束，质量属性需求等内容。

3、描述体系结构

设计师或设计小组对体系结构进行详略适当的介绍。包括技术约束，与本系统交互的其他系统，用以满足质量属性要求的体系结构方法（功能，模块，进程，硬件）。

4、确定体系结构方法

由设计师确定体系结构方法，由分析小组捕获，但不进行分析。

5、生成质量属性效用树

评估小组，设计小组，管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些目标设置优先级和细化。

6、分析架构方法

7、头脑风暴并确定场景的优先级

8、分析架构方法

9、描述评估结果

下面通过汽车后保险杠上加装后视摄像头案例介绍下ATAM在汽车软件中的应用。

1、描述ATAM方法

汽车后保险杠上加装后视摄像头。目前大部分汽车都有尾部摄像头，倒车时通过中控显示倒车影像。

倒车辅助摄像头传输到中控的图像

当在原有的电气系统中加入摄像头后，从汽车尾部传输到汽车头部的数据量会急剧增加。同时，为确保倒车期间的安全性，倒车影像数据必须保证实时传输。而在总线上，还有其他安全关键信 也需要保证实时传输，这意味着通信总线不得不持续地在视频信 反馈和诸如驻车辅助等安全关键性传感器之问调整传输的优先级。在这一场景下，架构师需要回答一个问题：如何保证摄像头的加人不会对车上原有的安全关键性功能造成负面影响？相比实际车辆的软件架构，该案例有一定的简化和修改，仅作为ATAM的说明，这里充当“描述ATAM方法。”

2、描述业务动机

该架构的主要业务动机是使车辆达到高度安全性。

通过示例图来描述该架构。首先展示的是汽车的功能架构。因为关注的是摄像头功能，我们只选取了架构中与之相关的主动安全域、底盘域和车载娱乐域的功能，主动安全域包括紧急制动、制动防抱死（ABS)功能，底盘域包括转向灯、近光灯和刮水器，车载娱乐域包括中控屏和抬头显示设备(Head-up Display，HUD）中的信息显示功能。

架构中的功能从属示例

在介绍下汽车的EEA架构，这个案例中简化的物理视图。

架构的物理视图示例

在物理视图中，存在两条总线：

?CAN总线：连接车载娱乐域中的控制单元。

?FlexRay总线：连接安全域和底盘域中的控制单元。

除此之外，视图中还有如下控制单元节点：

?主控制单元：汽车的中枢控制单元，控制车辆配置，负责整个电子电气系统的初始化和诊断。该单元是车辆上计算能力最强的控制器。

?制动防抱死控制单元(ABS)：该控制单元负责车辆的制动和相关功能。这是一个高度安全关键的系统，具有车辆上最高的软件安全等级。

?高级驾驶辅助系统(ADAS)：该控制单元负责主动安全领域更高级别的决策，例如制动防碰撞、紧急制动、防滑等功能。它也负责驻车辅助等功能。

?转向：该控制单元负责车辆的转向功能，例如电子转向系统；驻车辅助等功能的一部分也通过该控制单元实现。

?尾部控制单元（Back Body Controller，简称BBC)：该控制单元负责与车辆尾部相关的非安全关键功能，例如：调节后视镜、行李舱电子开关、后窗除雾等功能。

接下来，是架构的逻辑视图，在该视图中，聚焦在车载娱乐系统显示的主要功能组件，以及它对摄像头控制单元的信 输人的处理。

架构的逻辑视图示例

还有一种增加了摄像头后架构的潜在布置方案。在这种方案中，信 处理的主要工作在尾部控制器节点完成。

潜在方案示例

3、确定架构方法

我们关注的是目标控制单元上的软件组件的划分。无论采用何种软件架构，系统的物理架构(硬件)都没有变化。因此，架构方法的确定应仅依赖于汽车的电子电气系统。有另一种架构的替代方案，不同于将摄像头功能的软件组件划分至主控制器和尾部控制器的方式，所有的信 处理工作都在主控制器中进行。因为系统的主要功能是对图像信 的处理，因此我们采用了常见的管道过滤器(pipe-and-filter)风格来设计架构。汽车的电气系统应该支持主动安全的先进机制（通过软件控制），并且确保这些机制之间不会互相干扰，从而危及车辆安全。

另一种替代方案示例

对这两种替代方案都进行研究，最终决定选择何种架构来支持最初期望的质量目标，基于它们的各自生成的质量属性效用树来完成架构的选型。

4、生成质量属性效用树

在这个案例中，让我们考虑两个互补的场景，虽然可以为上文提到的每个质量属性都找到多个场景，这里我们只关注安全性：场景一，当车辆倒车、倒车影像激活后，CAN总线出现了信 拥挤；场景二，当恶劣气候下主控制器单元已经过载时，影像信 的计算会对雨刮器、近光灯等功能的性能造成于扰。

场景多方面描述

在第一个场最中，我们所关注的是倒车影像对安全性的影响。需要了解视频信 的数据传输会对连找主控制器和尾部控制器的CAN总线造成何种影响。因此，我们设计的两种架构布置方视频信 处理布置在主控制器单元或布置在尾部控制器中，都需要被纳入分析。假设两种架构方案都不会导致硬件的增加，因此对电气系统的整体性能没有影响。通过这一简化我们将不必分析物理架构，而将关注点全部放在架构的逻辑视图和布置方案上。

通信总线占用

主控制单元的过载

在上述分析中，之所以要同时考虑两种方案，是因为它们展示了功能在节点上分布方案背后的不同逻辑可能性。在这个的案例中，基于场景分析得到的质量效用树包含着两种质量属性安全性和性能。两种场景在效用树中的评级都是高。当生成了效用树后，就可以对两种架构进行分析，并找到它们各自的权衡点和敏感点。

质量属性效用树

5、分析架构方法和决策

对架构及其两种部署方案进行深入分析。在分析过程中，会发现了很多风险，这里以一个风险为例：信 无法传输到另一个控制器的风险。

可以使用风险模板来完成描述。可以看到该风险会影响到乘客的安全，因此需要被消除。进一步分析，消除该风险意味着总线通信不能对安全关键信 造成影响。因此，应该优先考虑第一种架构方案—在尾部控制单元完成视频信 的处理。这一方案意味着尾部控制器需要有足够的计算能力完成对视频信 的实时处理，这可能会导致车辆电气系统的成本增加。但既然安全性是业务动机，单车成本的增加应该可以被车型销量的增加所平衡。

风险描述

6、描述评估结果

在实践中，架构和评估团队会执行与上述类似的完整讨论和展示工作，包括问题的发现，场景、场景优先级的排定以区头脑风暴等。

ATAM评估总结

ATAM方法是为软件架构的设计而开发的。但是在汽车领域，汽车软件架构和物理硬件的架构是紧密联系的。建议在对汽车领域的软件架构进行ATAM评估时，将硬件也纳入评估团队，只有这样才能确保所设计的软件架构完全满足系统的要求。