《汽车软件架构》的读后感
以下文章选自《汽车电子与软件》
当一名普普通通又不会Linux的汽车嵌入式软件工程师遭遇到Automotive SPICE的降维打击，他发现自己身处V Model的最底端，即SWE.3 软件详细设计和写代码。未来的职业发展何在？除了转管理还有更好的出路吗？
Automotive SPICE已经为我们指明了方向，SWE.2 软件架构设计和SWE.5 软件集成都是普通的嵌入式软件工程师可以发展的方向。由Miroslaw Staron著，王驷通和欧阳紫洲译的这本《汽车软件架构》可谓是汽车行业软件架构师的必读书目。本书著成于2017年1月，译成于2020年3月。它其实更像是9篇不同主题、逐层递进的小论文，分别阐释了什么是软件架构，软件架构的下游工作，AUTOSAR的参考架构，如何来评价软件架构，功能安全与软件架构之间的关系等几个问题。当然这也是本书的一个小缺点，那就是各个章节的内容相对独立，有种分离之感。
话说大佬讲完一席话之后，如果你没有提出任何问题，那你大概率是去了元宇宙，没有认真听他讲课。以下是我阅读后总结出的问题与解答。如有错误，恳请更正。
（第一章）Q：软件架构师和软件项目经理的区别是什么？
A：架构师关注的是技术，是需求和解决方案。而软件项目经理关注的是工作产品的输出进度，是资源问题和成本消耗。
（第一章）Q：软件架构师和软件工程师的区别是什么？
A：架构师负责制定规范、策略和顶层结构，主要工作是建模、分析和评估，输出物是架构设计文档。ASPICE中对应的是SWE.2 软件架构设计。
“所有的原则、规则、决策都必须进行解释和记录，才可以在保持一致性的前提下被传播和执行。”
而软件工程师关注的是软件本体，要做的是遵守规范，主要工作是写代码、配置参数和单元测试，输出物是函数流程图、源代码、静态与动态测试报告等。ASPICE中对应的是SWE.3 软件详细设计和单元构建。
（第二章）Q：怎么来定义软件架构？
A：书中提到的软件架构包含三个部分，分别是高层结构、创建结构的原则、结构的文档记录。这三个名字有点抽象。
高层结构，通俗的讲就是你手里可用的硬件和你要创建的软件模块，都要化身成一个个矩形块，用UML（Unified Modeling Language，统一建模语言）体现在画板上，要像建筑行业那样出图纸。此外，对于软件模块来说，它的需求、属性、功能也要在输出物上体现出来。
创建结构的原则，即需要有哪些软件模块，每个软件模块应该做什么，需要定义块与块之间的接口、接口内容、接口方向。
结构的文档记录，如用visio画出的图，Rhapsody生成的图、表、报告等，针对各个软件模块的需求规范。这些是软件架构环节的输出物。
（第二章）Q：日常工作中有哪些架构的风格呢？
A：AUTOSAR采用的分层架构（Layered Architecture）就是汽车行业最常见的架构风格。应用层与基础软件（BSW）被分割开来，越高层级的模块越偏重应用，越低层级的模块越靠近硬件。
与此同时，AUTOSAR还采用了基于组件（Component-Based）的架构风格，即对于BSW层中的软件组件（SWC），彼此之间是通过标准AUTOSAR接口来通信的，这些接口的API函数已经被AUTOSAR需求定义“死”了。
单体（Monolithic）架构，AUTOSAR中的RTE采用的就是这种架构，保证实时通信。
除此之外，常见的架构风格还有客户端-服务器（Client-Server）架构及其特例——发布者-订阅者（Publisher-Subscriber）架构等。
（第二章）Q：UML和SysML有什么区别？在软件的架构设计中应采用哪种语言？
A：SysML脱胎于UML，更偏向系统层面。系统层面的架构设计应采用SysML（对应ASPICE的SYS.3过程），软件层面的架构设计应采用UML。UML常用到的图包括Structure Diagram（结构图），State Machine Diagram（状态机图），Sequence Diagram（顺序图），Activity Diagram（活动图）等。
（第三章）Q：汽车行业的需求对一个系统的设计成功至关重要，你是怎么理解的？
A：1. 需求对于系统来说应具有可测试性，即团队应该清楚如何对需求进行测试。
2. 需求对于功能设计而言应具有可追溯性，需求被软件的哪个部分所实现必须可追溯。
3. 需求对于项目进度而言，应具有可追溯性，必须能够总体掌握项目中的哪些需求已经实现，百分比是多少。
（第三章）Q：汽车软件开发中的需求类型有哪些？
A：本书中主要介绍了三种需求类型。需要说明的是需求的类型还有很多种分法，我们这里说的是具体的实现形式。
1. 文本需求。AUTOSAR的软件需求大多是文本形式。通常包含规范，描述（Description），理由（rationale）和用例（use case）。
2. 基于用例的需求。用例也是一种需求，通常被用于功能设计阶段和系统设计阶段，具体形式可以是用例图或顺序图。
3. 基于模型的需求。通常用于描述算法，发生在软件详细设计阶段。
（第三章）Q：为了满足V模型和ASPICE的要求，汽车软件工程需要什么样的建构数据库或者说是“基础设施”？
A：基础设施应该包含需求规范数据库，测试用例数据库，架构模型绘制，详细设计模型绘制，实施计划等。不仅如此，还需要允许工程师添加需求-设计元素-测试用例之间的追溯关系，并能自动化的输出成报告。
毕竟可追溯性（traceability）对于汽车软件工程来说是很重要的事。
（第四章）Q：能否简单说下AUTOSAR的开发过程？
A：OEM需要做的是三个设计工作。
1. 逻辑系统设计。即为了实现需求，需要有几个Component SWC（复合逻辑软件组件），之间的逻辑接口要定义好。
2. 物理系统设计。把上一个过程中的逻辑接口变成真实的物理接口，比如FlexRay，CAN等。
3. 物理通信设计。细化上一个过程，定义通信矩阵。
OEM需要输出的是ECU模型提取物，ECU Extract，通常是一个arxml文件。这里的AR指的是AUTOSAR。
Tier1需要做3个设计工作。
4. 物理ECU设计。Compoent SWC需要细化成若干个原子软件组件（Atomic SWC），其实就是普通的SWC了，再细分就是单元Unit了。比如Dem，CanNm在级别上都属于Atomic SWC。
5. 功能开发工作。即实现代码，要么手写，要么Simulink。
6. 基础软件配置工作。AUTOSAR将BSW最后的产物定义成了两部分，一部分是基础的功能性代码，另一部分是通过配置器生成的配置代码。配置工程师需要用Tier2的软件来实现客户需要的诊断需求、通信矩阵和网络管理需求等。
Tier1的输出物是SWC代码（应用层，复杂驱动，IoHw等），和BSW配置代码。
Tier2需要做的是基础软件的开发工作。提交给Tier1的应该是BSW配置软件及BSW的基础代码。通常从属于BSW的MCAL（Micro Controller Abstraction Layer）会被单独提起，MCAL和BSW主体部分的Tier2也不一定是一家公司。
最终，软件集成工程师会将SWC代码，BSW配置代码，BSW基础代码集成在一起，用于后续的软件集成测试。
（第四章）Q：初次学习AUTOSAR应该从哪些文件入手呢？
A：AUTOSAR是一个庞大的标准，包含了超过200份规范和20000个需求。建议从阅读标准中的Layed Software Architecture文档入手。接下来可以学习AUTOSAR方法论规范（Methodology）。在接下来就是有选择性的阅读AUTOSAR模板规范（TPS）和BSW的软件规范（SWS）了。
我个人是很喜欢看CanNm和ComM这两本SWS的。
（第六章）Q：什么样的质量属性对汽车软件架构至关重要？
A：这个需要详读ISO 25000标准族。这其中，ISO/IEC 25010-2011着重说明我们需要关注哪些质量属性，ISO/ IEC 25023-2016着重介绍了这些质量属性的度量方法。
（第六章）Q：如何评估一个架构是否满足了这些质量属性的标准？
A：两种常见的方法是FMEA（失效模式和影响分析，Failure Modes and Effects Analysis），和ATAM（架构权衡分析方法，Software Architecture Analysis Method）。其中ATAM是一种基于"场景定性分析"来评估架构的方法。
一个典型的ATAM方法的主要步骤：
1.描述ATAM方法。
2.描述业务动机。（描述主要功能）
3.描述架构。
4.确定架构方法。
5.生成质量属性效用树，并分析架构方法。
6.头脑风暴并确定场景的优先级，之后再次分析架构方法。（是一种对步骤5的迭代）
7.展示评估结果。（编制报告）
对于第4步确定架构方法，工程师需要在第一份架构方案之外，设计一份替代方案。这一点在ASPICE SWE.2.BP6中也是有要求的。之后在第5步生成效用树之后，我们就可以对两种架构进行分析，找到它们各自的权衡点和敏感点。
作者强烈建议在进行ATAM评估时邀请硬件专家，以确保软件架构完全满足系统的要求。
（第七章）如何对软件架构设计进行定量的、持续性的测量？
A：可以从三个组别，多个指标来进行量化。
1. 架构的度量：
1.1 软件架构变更：单位时间内（比如一周），架构变更的次数。
1.2 复杂度：识别扇出，即该模块直接调用的下级模块的个数。扇出越大说明架构复杂度越高。
1.3 外部接口和内部接口的接口数量。
2. 设计稳定性的度量：
2.1 代码稳定性：单位时间内，单位模块的代码变化次数。
2.2 单一模块缺陷数：单位时间内，单位模块的缺陷（defect）个数。
2.3 接口稳定性：单位时间内的接口更改次数。
3. 技术负债及风险的度量：
3.1 耦合：测量架构的显式依赖（explicit dependencies）的数量。我理解这里的显式依赖指的是在软件架构中已经定义出来的模块间的链接。
3.2 隐式依赖：架构工程师需要观察是否在软件详细设计阶段引入了额外的依赖关系。因此需要测量架构的隐式依赖（implicit dependencies）数量。我理解这里的隐式架构指在软件架构中没有描述出来的、却在详细设计阶段产生的模块间的链接。
注：技术负债指为了满足短期的时间效率而采用了你自己都看不过去的架构设计方案。这样的方案迟早是要重做的，与“债务”相似，故得名。
勘误：
版本：2020年10月第1版
P75，最后一行，图4.4应为图4.5。
P76，倒数第三行，Tire1应为Tier1。
P94，4.6.2标题之前一行，ECU通和诊断，应为ECU通信和诊断。
阅读原文，关注作者知乎
汽车电子与软件
每天分享一篇技术文章！
327篇原创内容
公众号
当一名普普通通又不会Linux的汽车嵌入式软件工程师遭遇到Automotive SPICE的降维打击，他发现自己身处V Model的最底端，即SWE.3 软件详细设计和写代码。未来的职业发展何在？除了转管理还有更好的出路吗？
Automotive SPICE已经为我们指明了方向，SWE.2 软件架构设计和SWE.5 软件集成都是普通的嵌入式软件工程师可以发展的方向。由Miroslaw Staron著，王驷通和欧阳紫洲译的这本《汽车软件架构》可谓是汽车行业软件架构师的必读书目。本书著成于2017年1月，译成于2020年3月。它其实更像是9篇不同主题、逐层递进的小论文，分别阐释了什么是软件架构，软件架构的下游工作，AUTOSAR的参考架构，如何来评价软件架构，功能安全与软件架构之间的关系等几个问题。当然这也是本书的一个小缺点，那就是各个章节的内容相对独立，有种分离之感。
话说大佬讲完一席话之后，如果你没有提出任何问题，那你大概率是去了元宇宙，没有认真听他讲课。以下是我阅读后总结出的问题与解答。如有错误，恳请更正。
（第一章）Q：软件架构师和软件项目经理的区别是什么？
A：架构师关注的是技术，是需求和解决方案。而软件项目经理关注的是工作产品的输出进度，是资源问题和成本消耗。
（第一章）Q：软件架构师和软件工程师的区别是什么？
A：架构师负责制定规范、策略和顶层结构，主要工作是建模、分析和评估，输出物是架构设计文档。ASPICE中对应的是SWE.2 软件架构设计。
“所有的原则、规则、决策都必须进行解释和记录，才可以在保持一致性的前提下被传播和执行。”
而软件工程师关注的是软件本体，要做的是遵守规范，主要工作是写代码、配置参数和单元测试，输出物是函数流程图、源代码、静态与动态测试报告等。ASPICE中对应的是SWE.3 软件详细设计和单元构建。
（第二章）Q：怎么来定义软件架构？
A：书中提到的软件架构包含三个部分，分别是高层结构、创建结构的原则、结构的文档记录。这三个名字有点抽象。
高层结构，通俗的讲就是你手里可用的硬件和你要创建的软件模块，都要化身成一个个矩形块，用UML（Unified Modeling Language，统一建模语言）体现在画板上，要像建筑行业那样出图纸。此外，对于软件模块来说，它的需求、属性、功能也要在输出物上体现出来。
创建结构的原则，即需要有哪些软件模块，每个软件模块应该做什么，需要定义块与块之间的接口、接口内容、接口方向。
结构的文档记录，如用visio画出的图，Rhapsody生成的图、表、报告等，针对各个软件模块的需求规范。这些是软件架构环节的输出物。
（第二章）Q：日常工作中有哪些架构的风格呢？
A：AUTOSAR采用的分层架构（Layered Architecture）就是汽车行业最常见的架构风格。应用层与基础软件（BSW）被分割开来，越高层级的模块越偏重应用，越低层级的模块越靠近硬件。
与此同时，AUTOSAR还采用了基于组件（Component-Based）的架构风格，即对于BSW层中的软件组件（SWC），彼此之间是通过标准AUTOSAR接口来通信的，这些接口的API函数已经被AUTOSAR需求定义“死”了。
单体（Monolithic）架构，AUTOSAR中的RTE采用的就是这种架构，保证实时通信。
除此之外，常见的架构风格还有客户端-服务器（Client-Server）架构及其特例——发布者-订阅者（Publisher-Subscriber）架构等。
（第二章）Q：UML和SysML有什么区别？在软件的架构设计中应采用哪种语言？
A：SysML脱胎于UML，更偏向系统层面。系统层面的架构设计应采用SysML（对应ASPICE的SYS.3过程），软件层面的架构设计应采用UML。UML常用到的图包括Structure Diagram（结构图），State Machine Diagram（状态机图），Sequence Diagram（顺序图），Activity Diagram（活动图）等。
（第三章）Q：汽车行业的需求对一个系统的设计成功至关重要，你是怎么理解的？
A：1. 需求对于系统来说应具有可测试性，即团队应该清楚如何对需求进行测试。
2. 需求对于功能设计而言应具有可追溯性，需求被软件的哪个部分所实现必须可追溯。
3. 需求对于项目进度而言，应具有可追溯性，必须能够总体掌握项目中的哪些需求已经实现，百分比是多少。
（第三章）Q：汽车软件开发中的需求类型有哪些？
A：本书中主要介绍了三种需求类型。需要说明的是需求的类型还有很多种分法，我们这里说的是具体的实现形式。
1. 文本需求。AUTOSAR的软件需求大多是文本形式。通常包含规范，描述（Description），理由（rationale）和用例（use case）。
2. 基于用例的需求。用例也是一种需求，通常被用于功能设计阶段和系统设计阶段，具体形式可以是用例图或顺序图。
3. 基于模型的需求。通常用于描述算法，发生在软件详细设计阶段。
（第三章）Q：为了满足V模型和ASPICE的要求，汽车软件工程需要什么样的建构数据库或者说是“基础设施”？
A：基础设施应该包含需求规范数据库，测试用例数据库，架构模型绘制，详细设计模型绘制，实施计划等。不仅如此，还需要允许工程师添加需求-设计元素-测试用例之间的追溯关系，并能自动化的输出成报告。
毕竟可追溯性（traceability）对于汽车软件工程来说是很重要的事。
（第四章）Q：能否简单说下AUTOSAR的开发过程？
A：OEM需要做的是三个设计工作。
1. 逻辑系统设计。即为了实现需求，需要有几个Component SWC（复合逻辑软件组件），之间的逻辑接口要定义好。
2. 物理系统设计。把上一个过程中的逻辑接口变成真实的物理接口，比如FlexRay，CAN等。
3. 物理通信设计。细化上一个过程，定义通信矩阵。
OEM需要输出的是ECU模型提取物，ECU Extract，通常是一个arxml文件。这里的AR指的是AUTOSAR。
Tier1需要做3个设计工作。
4. 物理ECU设计。Compoent SWC需要细化成若干个原子软件组件（Atomic SWC），其实就是普通的SWC了，再细分就是单元Unit了。比如Dem，CanNm在级别上都属于Atomic SWC。
5. 功能开发工作。即实现代码，要么手写，要么Simulink。
6. 基础软件配置工作。AUTOSAR将BSW最后的产物定义成了两部分，一部分是基础的功能性代码，另一部分是通过配置器生成的配置代码。配置工程师需要用Tier2的软件来实现客户需要的诊断需求、通信矩阵和网络管理需求等。
Tier1的输出物是SWC代码（应用层，复杂驱动，IoHw等），和BSW配置代码。
Tier2需要做的是基础软件的开发工作。提交给Tier1的应该是BSW配置软件及BSW的基础代码。通常从属于BSW的MCAL（Micro Controller Abstraction Layer）会被单独提起，MCAL和BSW主体部分的Tier2也不一定是一家公司。
最终，软件集成工程师会将SWC代码，BSW配置代码，BSW基础代码集成在一起，用于后续的软件集成测试。
（第四章）Q：初次学习AUTOSAR应该从哪些文件入手呢？
A：AUTOSAR是一个庞大的标准，包含了超过200份规范和20000个需求。建议从阅读标准中的Layed Software Architecture文档入手。接下来可以学习AUTOSAR方法论规范（Methodology）。在接下来就是有选择性的阅读AUTOSAR模板规范（TPS）和BSW的软件规范（SWS）了。
我个人是很喜欢看CanNm和ComM这两本SWS的。
（第六章）Q：什么样的质量属性对汽车软件架构至关重要？
A：这个需要详读ISO 25000标准族。这其中，ISO/IEC 25010-2011着重说明我们需要关注哪些质量属性，ISO/ IEC 25023-2016着重介绍了这些质量属性的度量方法。
（第六章）Q：如何评估一个架构是否满足了这些质量属性的标准？
A：两种常见的方法是FMEA（失效模式和影响分析，Failure Modes and Effects Analysis），和ATAM（架构权衡分析方法，Software Architecture Analysis Method）。其中ATAM是一种基于"场景定性分析"来评估架构的方法。
一个典型的ATAM方法的主要步骤：
1.描述ATAM方法。
2.描述业务动机。（描述主要功能）
3.描述架构。
4.确定架构方法。
5.生成质量属性效用树，并分析架构方法。
6.头脑风暴并确定场景的优先级，之后再次分析架构方法。（是一种对步骤5的迭代）
7.展示评估结果。（编制报告）
对于第4步确定架构方法，工程师需要在第一份架构方案之外，设计一份替代方案。这一点在ASPICE SWE.2.BP6中也是有要求的。之后在第5步生成效用树之后，我们就可以对两种架构进行分析，找到它们各自的权衡点和敏感点。
作者强烈建议在进行ATAM评估时邀请硬件专家，以确保软件架构完全满足系统的要求。
（第七章）如何对软件架构设计进行定量的、持续性的测量？
A：可以从三个组别，多个指标来进行量化。
1. 架构的度量：
1.1 软件架构变更：单位时间内（比如一周），架构变更的次数。
1.2 复杂度：识别扇出，即该模块直接调用的下级模块的个数。扇出越大说明架构复杂度越高。
1.3 外部接口和内部接口的接口数量。
2. 设计稳定性的度量：
2.1 代码稳定性：单位时间内，单位模块的代码变化次数。
2.2 单一模块缺陷数：单位时间内，单位模块的缺陷（defect）个数。
2.3 接口稳定性：单位时间内的接口更改次数。
3. 技术负债及风险的度量：
3.1 耦合：测量架构的显式依赖（explicit dependencies）的数量。我理解这里的显式依赖指的是在软件架构中已经定义出来的模块间的链接。
3.2 隐式依赖：架构工程师需要观察是否在软件详细设计阶段引入了额外的依赖关系。因此需要测量架构的隐式依赖（implicit dependencies）数量。我理解这里的隐式架构指在软件架构中没有描述出来的、却在详细设计阶段产生的模块间的链接。
注：技术负债指为了满足短期的时间效率而采用了你自己都看不过去的架构设计方案。这样的方案迟早是要重做的，与“债务”相似，故得名。
勘误：
版本：2020年10月第1版
P75，最后一行，图4.4应为图4.5。
P76，倒数第三行，Tire1应为Tier1。
P94，4.6.2标题之前一行，ECU通和诊断，应为ECU通信和诊断。
阅读原文，关注作者知乎
汽车电子与软件
每天分享一篇技术文章！
327篇原创内容
公众号
