软件系统架构的选择对于软件系统开发的成败至关重要，软件架构各种风格各种方法，光分层架构方法就很多，如何评估哪个软件系统架构方法更合适。CMU/SEI（卡梅隆大学软件工程协会）提出了一套架构权衡分析方法，Architecture Tradeoff Analysis Method，简称ATAM。传统软件架构评估方法按评估形式，一般分为三种。一是调查问卷法，即直接请对系统架构了解的专家学者对系统架构做出主观评估。二是度量法，即将软件系统架构完全量化，通过一些客观的数字指标来评估架构的好坏。三是场景评估法，即挑选出重要的系统使用场景，根据不同场景中各架构的表现分别作评估，ATAM属于场景评估法，主客观程度介于前面两种方法之间。软件质量属性说的是我们评估软件架构，到底评估它的什么特性，一般有如下几个，- 性能：指系统的响应能力，即系统执行某个特定事务所需要的时间。
- 可靠性：即在意外或错误使用的情况下，维持软件系统的功能特性的能力。一般包括容错和健壮性两个方面的能力。
- 可用性：是系统能够正常运行的时间比例，和可靠性相比，可用性除了体现出错概率外，还体现出错后恢复正常的速度上。
- 安全性：是指阻止非授权用户使用的企图或拒绝服务的能力。又可分为机密性、完整性、不可否认性及可控性。
- 可修改性：是指能够快速地以较高的性价比对系统进行变更的能力。包括可维护性，可扩展性，结构重组和可移植性。
敏感点和权衡点都是在软件架构中所做的关键决策，不同的是，敏感点决策只影响一个软件质量属性，而权衡点则同时影响多个质量属性，有时不同属性间还会互相冲突，比如选择不同的加密方式同时影响性能和安全性，所以需要权衡。风险承担者是指那些关心软件架构，个人利益受软件架构好坏影响的人，在项目管理领域也称为项目干系人或涉众。这照些人整体上又可以分为系统的生产者和系统的消费者。生产者包括架构师，开发人员，维护人员，测试人员等；消费者包括客户，最终用户等。ATAM通过理解体系结构方法来分析体系结构，评估过程分9个步骤：即评估小组负责人向参加会议的风险承担者介绍ATAM评估方法，负责人将解释评估的原则、评估的方案及目标（例如：那些质量特性应该优先考虑）。从业务角度介绍系统的概况，一般包括业务环境，背景，业务约束条件，技术约束，质量属性需求等内容。设计师或设计小组对体系结构进行详略适当的介绍。包括技术约束，与本系统交互的其他系统，用以满足质量属性要求的体系结构方法（功能，模块，进程，硬件）。由设计师确定体系结构方法，由分析小组捕获，但不进行分析。评估小组，设计小组，管理人员和客户代表一起确定系统最重要的质量属性目标，并对这些目标设置优先级和细化。下面通过汽车后保险杠上加装后视摄像头案例介绍下ATAM在汽车软件中的应用。汽车后保险杠上加装后视摄像头。目前大部分汽车都有尾部摄像头，倒车时通过中控显示倒车影像。
当在原有的电气系统中加入摄像头后，从汽车尾部传输到汽车头部的数据量会急剧增加。同时，为确保倒车期间的安全性，倒车影像数据必须保证实时传输。而在总线上，还有其他安全关键信号也需要保证实时传输，这意味着通信总线不得不持续地在视频信号反馈和诸如驻车辅助等安全关键性传感器之问调整传输的优先级。在这一场景下，架构师需要回答一个问题：如何保证摄像头的加人不会对车上原有的安全关键性功能造成负面影响？相比实际车辆的软件架构，该案例有一定的简化和修改，仅作为ATAM的说明，这里充当“描述ATAM方法。”通过示例图来描述该架构。首先展示的是汽车的功能架构。因为关注的是摄像头功能，我们只选取了架构中与之相关的主动安全域、底盘域和车载娱乐域的功能，主动安全域包括紧急制动、制动防抱死（ABS)功能，底盘域包括转向灯、近光灯和刮水器，车载娱乐域包括中控屏和抬头显示设备(Head-up Display，HUD）中的信息显示功能。
架构中的功能从属示例 在介绍下汽车的EEA架构，这个案例中简化的物理视图。 
架构的物理视图示例 在物理视图中，存在两条总线： ·CAN总线：连接车载娱乐域中的控制单元。 ·FlexRay总线：连接安全域和底盘域中的控制单元。 除此之外，视图中还有如下控制单元节点： ·主控制单元：汽车的中枢控制单元，控制车辆配置，负责整个电子电气系统的初始化和诊断。该单元是车辆上计算能力最强的控制器。 ·制动防抱死控制单元(ABS)：该控制单元负责车辆的制动和相关功能。这是一个高度安全关键的系统，具有车辆上最高的软件安全等级。 ·高级驾驶辅助系统(ADAS)：该控制单元负责主动安全领域更高级别的决策，例如制动防碰撞、紧急制动、防滑等功能。它也负责驻车辅助等功能。 ·转向：该控制单元负责车辆的转向功能，例如电子转向系统；驻车辅助等功能的一部分也通过该控制单元实现。 ·尾部控制单元（Back Body Controller，简称BBC)：该控制单元负责与车辆尾部相关的非安全关键功能，例如：调节后视镜、行李舱电子开关、后窗除雾等功能。 接下来，是架构的逻辑视图，在该视图中，聚焦在车载娱乐系统显示的主要功能组件，以及它对摄像头控制单元的信号输人的处理。 
架构的逻辑视图示例 还有一种增加了摄像头后架构的潜在布置方案。在这种方案中，信号处理的主要工作在尾部控制器节点完成。 
潜在方案示例 3、确定架构方法 我们关注的是目标控制单元上的软件组件的划分。无论采用何种软件架构，系统的物理架构(硬件)都没有变化。因此，架构方法的确定应仅依赖于汽车的电子电气系统。有另一种架构的替代方案，不同于将摄像头功能的软件组件划分至主控制器和尾部控制器的方式，所有的信号处理工作都在主控制器中进行。因为系统的主要功能是对图像信号的处理，因此我们采用了常见的管道过滤器(pipe-and-filter)风格来设计架构。汽车的电气系统应该支持主动安全的先进机制（通过软件控制），并且确保这些机制之间不会互相干扰，从而危及车辆安全。 
另一种替代方案示例 对这两种替代方案都进行研究，最终决定选择何种架构来支持最初期望的质量目标，基于它们的各自生成的质量属性效用树来完成架构的选型。 4、生成质量属性效用树 在这个案例中，让我们考虑两个互补的场景，虽然可以为上文提到的每个质量属性都找到多个场景，这里我们只关注安全性：场景一，当车辆倒车、倒车影像激活后，CAN总线出现了信号拥挤；场景二，当恶劣气候下主控制器单元已经过载时，影像信号的计算会对雨刮器、近光灯等功能的性能造成于扰。 场景多方面描述 方面 | 详细含义 | 源 | 后摄像头 | 刺激 | 影像信号 | 构件 | 主控制单元，尾部控制单元，CAN总线 | 环境 | 倒车过程中 | 响应 | 处理彩像数据并显示在中控屏上 | 度量 | 视频影像可以实时显示，同时来自驻车传感器的安全关键信号不会丢失 |
在第一个场最中，我们所关注的是倒车影像对安全性的影响。需要了解视频信号的数据传输会对连找主控制器和尾部控制器的CAN总线造成何种影响。因此，我们设计的两种架构布置方视频信号处理布置在主控制器单元或布置在尾部控制器中，都需要被纳入分析。假设两种架构方案都不会导致硬件的增加，因此对电气系统的整体性能没有影响。通过这一简化我们将不必分析物理架构，而将关注点全部放在架构的逻辑视图和布置方案上。 通信总线占用 场景编号 | 场景1:倒车过程中的总线信号拥挤阻止了安全关键信号的传输 | 剌激 | 该场景中，当车辆倒车时，来自尾部摄像头的倒车视频影像占用了过多的总线容量，导致总线信号无法传播由制动传感器发来的信号。
对该场景评估的关键问题是，哪种布置方案会对汽车软件的安全性造成最小的影响。 | 响应 | —分析两种架构布置方案中潜在的信号拥挤
—列举每种架构方案对功能的限制因素 | 需求 | 该架构应该能让安全关键信号在任何时刻被发出、被接收 | 质量属性 | 安全性：在该场景中，需要找到不会造成总线信号拥挤并造成潜在信号丢失的架构。 | 文本(可选) | 当倒车时，车尾摄像头发出的视频信号削减了制动传感器向主控制单元发送信号的能力，从而导致在潜在碰撞即将发生时，驾驶员没有得到预警提醒 |
主控制单元的过载 场景编号 | 场景2：在气候恶劣的情况下，已经满负载的主控制器单元会削减倒车影像信号的质量 | 剌激 | 当车辆倒车且遇到下雨/下雪等路况时，主控制单元需要同时负责驱动雨刮器工作、点亮近光灯以及处理视频信号，ECU的工作负载可能过大，而不足以同时完成所有的计算工作
对该场景评估的关键问题时：哪种布置方案会对汽车软件的性能造成最小的影响 | 响应 | —分析两种架构布置方案中各类信号计算需要占用的ECU资源
—列举每种架构方案对功能的限制因素 | 需求 | 在任何气候条件下，车辆在倒车时都应该稳定地提供来自尾部摄像头的影像信号 | 质量属性 | 性能：在该场景中，我们需要找到不会造成车辆控制器计算过载并削减视频信号传输质量的架构方案 | 文本(可行) | 当在恶劣气候条件下倒车时，汽车的控制单元可能会出现计算量过载，从而无法充分应对视频信号传输的任务 |
在上述分析中，之所以要同时考虑两种方案，是因为它们展示了功能在节点上分布方案背后的不同逻辑可能性。在这个的案例中，基于场景分析得到的质量效用树包含着两种质量属性安全性和性能。两种场景在效用树中的评级都是高。当生成了效用树后，就可以对两种架构进行分析，并找到它们各自的权衡点和敏感点。
对架构及其两种部署方案进行深入分析。在分析过程中，会发现了很多风险，这里以一个风险为例：信号无法传输到另一个控制器的风险。可以使用风险模板来完成描述。可以看到该风险会影响到乘客的安全，因此需要被消除。进一步分析，消除该风险意味着总线通信不能对安全关键信号造成影响。因此，应该优先考虑第一种架构方案—在尾部控制单元完成视频信号的处理。这一方案意味着尾部控制器需要有足够的计算能力完成对视频信号的实时处理，这可能会导致车辆电气系统的成本增加。但既然安全性是业务动机，单车成本的增加应该可以被车型销量的增加所平衡。风险编号 | R1_S1 | 描述 | 来自制动传感器的信号无法通过总线传输。造成的风险，当车辆遇到障碍物时将无法有效制动，从而发生碰撞。 | 危险源/敏感点 | 该风险发生在连接主控器单元和尾部控制器单元之间的FlexRay总线上，如下图(SP1): 
| 风险影响 | 功能安全ASIL等级C要求：
RQ1:车辆需要在检测到前方障碍物后，在2m之内制动停车。
该风险对用户的影响是，车辆无法制动停车，从而对系统造成危险。同时也会对乘客的健康造成轻微危害。 | 风险严重性 | 3 | 风险概率 | 5—该现象非常容易在倒车过程中发生(只要安全信号和视频信号影响信号需要同时传播) |
在实践中，架构和评估团队会执行与上述类似的完整讨论和展示工作，包括问题的发现，场景、场景优先级的排定以区头脑风暴等。ATAM评估总结 场景 | 在倒车过程中捕获来自尾部的倒车影像信号并将其显示在中控屏上 | 属性 | 安全性 | 环境 | 车辆处于倒车状态 | 刺激 | 倒车影像信号在中控屏显示 | 响应 | 处理视频数据并在中控屏显示 | 架构决策 | 敏感点 | 权衡点 | 风险 | 将视频信号处理任务放在主控制单元进行 | S1 | T1 | R1 | 将视频信号处理任务放在尾部处理单元进行 |
| T2 | R2 | 推理 | 主控制器单元的功能对系统至关重要(敏感点S1)
安全性的提升造成成本提升(权衡点T1)
由于主控制器的信号处理负荷过高，安全需求可能存在风险(风险R1) | 架构视图 | 
|
ATAM方法是为软件架构的设计而开发的。但是在汽车领域，汽车软件架构和物理硬件的架构是紧密联系的。建议在对汽车领域的软件架构进行ATAM评估时，将硬件也纳入评估团队，只有这样才能确保所设计的软件架构完全满足系统的要求。
|
