ASPICE SYS.3 系统架构设计指导

1. 系统需求分析与架构设计流程

首先讲下此流程的目的，比较简单，如此文标题所述，将系统需求分析和系统架构设计合二为一了，因此此流程目的必须分开讲述：

其一，深入分析并理解客户需求，将分析结果转化为一系列功能需求和非功能需求，制定系统需求文档，以指导系统架构的设计。

其二，在理解系统需求文档的基础上，确定设计约束，规范化系统架构设计。系统架构设计完成后，进行检查以确认系统架构设计与系统需求文档的可追溯性和一致性。

下面简单讲下这个流程中所涉及到的活动，当然这是笔者自己工作所结，仅供参考，具体执行还要具体情形。

1.理解原始需求
此活动由系统工程师主导，相关开发人员支持，研究和理解原始需求，从公司以往开发历史项目、正在开发过程中项目和该项目需求分析中识别产品基础平台及基础模型，制定该项目方案使用的基本框架/模型；从先前的可重复使用的开发资料中制定可复用的系统需求，供该项目分析使用，以草拟系统需求文档大纲。

2.分析系统需求
此活动由系统工程师主导，相关开发人员支持，识别操作环境、系统内外的边界接口、并分析系统需求对操作环境及接口的影响；分类系统需求，对需求进行功能性及非功能性区分、分类、分组和排定优先级，进一步分析系统需求包括其相互依赖关系，正确性、完整性、技术可行性和可验证性，以支持风险识别，并分析对成本、进度和技术的影响，并从技术方面分析对与接口、环境、效能、资源的影响，形成相应分析记录；制定可验证准则，进一步完善系统需求文档。

3.完成系统需求分析
此活动要求系统工程师在相关开发人员的支持下，分析整理完系统需求后，输出系统需求文档，制定验证准则，制定系统需求文档与需求管理列表之间的追溯关系。

4.系统需求评审
评审人员根据相关文档以及检查单，评审系统需求文档，进行比对检查，以确保其一致性，并检查系统需求文档内容合理性、完整性。评审结束需输出系统需求评审报告，评审通过后由系统工程师通知配置管理员进行归档管理，并由配置管理员遵循基线准则形成系统需求基线。此外需对该项目系统需求分析工作进行回顾总结，并生成总结报告或记录。系统需求评审完成并通过后，系统工程师可进行下一步系统架构设计工作，测试人员可进行系统合格性测试计划编写。

5.理解系统需求文档
此活动由系统工程师主导，相关开发人员支持。研究、理解系统需求文档，系统需求问题可与系统需求分析负责人澄清（若系统需求分析人员与系统架构设计人员为同一人，则此活动在系统需求分析中已进行）。以支持系统架构设计；识别架构，可从以往项目中识别此次项目可适用的基础模型架构；结合系统需求识别以往项目可复用的架构要素。

6.设计系统架构
此活动由系统工程师主导，在相关开发人员支持下，构思系统架构设计方案，并根据系统架构设计评估规范对其进行评估，包括其系统组件数量、架构实现复杂度、资源消耗、可复用性、系统内外接口数量、功能优先级考虑、架构实施风险系数、时间周期、以及对开发成本的影响，生成系统架构设计评估记录，最终决定系统架构设计方案；按照相关准则方法，定义内外边界，即根据系统要素之间的关系制定系统架构的内外接口；定义静态架构和动态行为，即根据系统需求制定系统功能静态框图、时序图及状态机等动态行为；进行系统需求分配，将系统需求分解并分配到系统要素及接口。

7.完成系统架构设计
此活动由系统工程师主导，在相关开发人员支持下，根据系统需求文档，在完成系统架构设计过程后，输出系统架构文档，制定验收准则，制定需求追溯矩阵，建立系统架构设计与系统需求文档间的追溯关系。

8.系统架构设计评审
此活动要求评审人员根据系统需求文档以及相关检查单，对系统架构文档和需求追溯矩阵进行同行评审，确认系统架构设计的内容正确、合理、完整，并且架构设计与系统需求追溯关系明晰，保持一致。评审结束需输出系统架构设计评审报告，评审通过后由系统工程师通知配置管理员进行归档管理，同时，可对系统架构设计工作进行回顾总结，生成报告或记录。系统架构设计评审完成并通过后，开发人员可跟进进行软件/硬件/结构的具体需求分析，后续软件架构设计、软件详细设计及软件单元构建，测试人员可进行系统集成测试计划编写。

2. 系统架构文档

系统架构文档是在理解并分析系统需求之后，必须输出的，是后续硬件、软件设计开发的重要支撑。系统架构文档应详细地说明根据系统需求文档，该系统所确定的系统元件及接口，即系统框架；此外需说明系统元件深入到的具体层级以及所涉及的具体接口；为阐释功能需求所定义的静态图、动态行为图等内容，最终输出系统架构设计文档。

2.1 系统概述

1.结构与外围描述
根据系统需求文档，理清并说明系统外围件、装配关系、装配环境要求，材料选型要求、环境布置、防水防尘要求等。

2.硬件及外围描述
需说明清楚器件选型的要求，以支持最终决定系统元器件的选择：
电子电器元件选型；电源大小；CAN收发器；N-MOS管；IGBT、BUCK芯片IC等元件；

3.电子电气架构拓扑描述
说明清楚该产品（ECU）所处的电子电气架构，ECU主从节点、网络通信渠道等。以拓扑图呈现

4.软件环境描述
说明清楚芯片选型要求，基于芯片所采取的软件架构：应用层、中间件、系统服务层、底层驱动等部署。是否采用AUTOSAR软件架构


5.设计约束
需说明系统架构设计是否还有其他的限制要素。

2.2 系统架构设计

1.系统整体概述
需对系统整体进行简要说明，包括系统及系统外部整体部署界面。
注：如下示例图，需按此描述清楚该产品系统以及相关联外部系统的整体部署

2. 系统架构图
说明该产品系统架构,系统需求如何分配到系统元件及接口

1.根据系统需求，说明清楚应定义的系统元件数量、应定义的接口形式及接口数量
2.分配系统需求到已定义的系统元件及接口

3.动态行为
需说明通过动态图体现系统之间的模块是怎么交互来实现系统功能的
通过动态图（包括状态迁移图、时序图、消息序列图、用例图等）描述系统功能。在描述动态行为时，往往要考虑响应时间。
4.设计约束
列出用于该系统架构构建的所有设计约束。设计约束代表已经批准并必须遵循的设计决定。其中包括结构设计，硬件器件选型、软件语言、开发流程需求、开发工具的指定用途等
5.风险评估

3. 系统架构方案选型评估

3.1 目的

在系统总体架构设计过程中，即分配系统需求到系统元件和接口，必然会涉及多种方案的选取，为保证架构设计的合理性、完整性和针对性，从根本上保证系统质量，降低成本及风险，需要对总体架构以及其中细节进行评估

3.2 对系统整体的架构评估

将软件、硬件和结构综合起来进行评估，看研发的系统是否具备高可用性、高稳定性、高可靠性、高安全性、高性价比；是否具备良好的可扩展性等。通过总体架构评估，达到增强各功能模块的集成度和联动性、提高总体性能的目的。主要关注内容如下：

【规则1】系统组件和接口控制评估
在研究和理解系统需求后，进行系统架构设计时，即首先会进行模块划分，在整体架构层级，会有结构、硬件、软件的区分，而后进行系统需求的分配。不同的设计方案必然影响系统组件以及接口处理。在这里主要考虑两方面，一是系统组件数量，二是接口。“低耦合高内聚”不仅是软件架构设计中要坚持的设计思想，同样在系统架构设计中也要考虑，实现软件、硬件及结构的完全解耦，这对于系统和后续软件开发工作十分有利。

软件程序尽量与硬件驱动分离，同时针对软件模块，硬件模块也要根据功能场景，实现高度模块化。接口数量形式跟模块划分的数量及功能复杂度密切相关。务必追求模块数量分配合理、接口数量及形式分配合理、模块实现功能明确且高度集成的原则。

【规则2】实现复杂性评估
系统架构设计本身就是为了降低系统复杂性，便于产品开发。因此在系统架构方案选型分析中，对于其实现复杂性必须考虑，必须符合实际，既严格符合设计要求，也能降低实现难度。

关于复杂性，尚无统一的定义，从不同角度可以给出不同的答案。可以用数量来度量，比如芯片集成的电子器件越多越复杂；按层级度量，复杂度在于层次的递归和不可分解性。此处需计算评估，可以选择从认识的负担和开发工作量的角度来定义系统实现的复杂性，可参考以下公式：

系统元件（各模块）的复杂度Cp乘以该模块对应的开发时间权重值Tp，累加后得到系统的整体复杂度C。系统整体的复杂度并不简单等于所有子模块复杂度的累加，还要考虑开发维护该模块所花费的时间在整体时间中的占比（ 对应权重值 Tp ）。也就是说，即使某个模块非常复杂，如果很少使用或修改，也不会对系统的整体复杂度造成大的影响。

子模块的复杂度Cp是一个经验值，它关注几个现象：修改扩散，修改时有连锁反应；认知负担，开发人员需要多长时间来理解功能模块；不可知，开发人员在接到任务时，不知道从哪里下手。

造成复杂的原因一般是模块依赖度高和晦涩（Obscurity）。其中模块间高度依赖，则导致部分模块不能独立的修改和理解，必定会牵涉到其他模块。模块晦涩，指模块功能分配不合理，关联度集成度不高，过于分散。

分模块是解决复杂性的重要方法。理想情况下，模块之间应该是相互隔离的，开发人员面对具体的任务，只需要接触和了解整个系统的一小部分，而无需了解或改动其他模块。为降低系统实现复杂性，可从以下角度着手评估和分析：

模块划分选择“深模块”（Deep Module）。深模块指的是拥有强大功能和简单接口的模块。深模块是抽象的最佳实践，通过排除模块内部不重要的信息，让其更容易理解和使用

注重通用性和专用性。设计新模块时，应该设计成通用模块还是专用模块，一种观点认为通用模块满足多种场景，在未来遇到预期外的需求时，可以节省时间。另外一种观点则认为，未来的需求很难预测，没必要引入用不到的特性，专用模块可以快速满足当前的需求，等有后续需求时再重构成通用的模块也不迟。以上两种思路都有道理，实际操作的时候可以采用两种方式各自的优点，即在功能实现上满足当前的需求，便于快速实现；接口设计通用化，为未来留下余量。设计通用性接口需要权衡，既要满足当前的需求，同时在通用性方面不要过度设计。一些可供参考的标准：

l 满足当前需求最简单的接口是什么？在不减少功能的前提下，减少方法的数量，意味着接口的通用性提升了。

l 接口使用的场景有多少？如果接口只有一个特定的场景，可以将多个这样的接口合并成通用接口。

l 满足当前需求情况下，接口的易用性如何？如果接口很难使用，意味着我们可能过度设计了，需要拆分。

信息隐藏。程序的设计思路以及内部逻辑应当包含在模块内部，对其他模块不可见。如果一个模块隐藏了很多信息，说明这个模块在提供很多功能的同时又简化了接口，符合前面提到的深模块理念。信息隐藏在降低复杂性方面主要有两个作用：一是简化模块接口，将模块功能以更简单、更抽象的方式表现出来，降低开发人员的认知负担；二是减少模块间的依赖，使得系统迭代更轻量。

注重拆分和合并。可参考以下思路：

l 共享信息的模块应当合并，比如两个模块都依赖某个配置项。

l 可以简化接口时合并，这样可以避免客户同时调用多个模块来完成某个功能。

l 可以消除重复时合并，比如抽离重复的模块到一个单独的方法中。

l 软件通用模块和专用模块分离，如果模块的部分功能可以通用，建议和专用部分分离。举个例子，在实际的系统设计中，我们会将专用模块放在上层，通用模块放在下层以供复用。

【规则3】资源消耗评估
系统架构设计，资源消耗也是考虑因素之一，否则资源消耗过高对于系统运行、开发成本都有不利影响。在做方案选型评估时，可从以下方面着手：

软件模块：减少外设使用（不需要的就关掉），减低时钟频率，尽量选择低功耗模式。

硬件模块：尽量使用低功耗器件，低功耗芯片。

低功耗产品几个因素：供电电压、时钟频率、外设数目、运行模式（掉电，睡眠）

l 尽可能的使用低功耗模式，加快进入低功耗模式的速度(程序代码优化)

l 最大限度降低时钟频率，将主频降低到满足应用的最小值

l 合理使用外设，能关掉就关掉

l 尽可能使用低电压低功耗的器件

l 减少循环等待而白白占用CPU资源，设置等待事件

l 关于电源的电路设计及可大幅度较少静态电流

【规则4】可复用性评估
系统架构设计，尽量考虑系统元件及架构要素的可复用性，不仅能提供产品质量，也能降低开发成本。

对于可复用性，我们在评估时，期望它简单、可移植性好和可兼容性好、灵活、可扩展、通用和参数化、模块化、将变化限制在局部、稳定，这些角度在评估架构可复用性时要予以关注。

【规则5】优先级评估
系统架构设计中对优先级的把握就是要将真正重要的功能／需求／元素放到突出的位置，以最多的资源去展示它们，而将次要的部分弱化，隐藏起来，再次的部分后续考虑。评估角度可从客户需求（用户需求）优先级、功能优先级、具体需求优先级等出发。

【规则6】成本评估

针对系统需求文档中每一条系统需求去评估是否有多种可实现的方法，实现的方法一般如下：

l 自行开发

l 沿用旧架构

l 供应商采购

l 开源方案

l 芯片厂商提供

【规则7】风险评估
系统架构方案抉择需充分考虑并评估其风险程度，需考虑各种系统架构方案对后续开发周期过程中可能出现的风险以及软件实施过程中因外部环境/需求的变化可能引起的风险等进行评估。

3.3 对硬件的架构评估

对硬件架构的评估，主要是根据具体的评估依据，看研发的系统是否尽量采用了低功率处理器和较少的功耗部件，是否满足低功耗的要求；系统是否具有较大的基础资源空间以及资源扩展空间（如程序指令空间，内部外部存储空间等）；是否易于运维管理；研发产品的硬件是否易于升级，是否满足可扩展性的要求等。

3.4 对软件的架构评估

对软件的架构评估，主要是根据具体的评估依据，看软件设计是否符合体系化设计原则；产品中所开发的软件是否易于升级，是否满足可扩展性强等要求。