#01 前 言

汽车软件SWC（Software Component）的概念主要来源于AUTOSAR（Automotive Open System Architecture）架构。

在Autosar架构中，SWC是核心概念之一，代表了一个独立的、可重用的、自我描述的、可替换的软件单元。这些软件组件具有清晰的输入输出接口，相较于整个汽车电子系统来说，是一个更小的功能模块。

SWC可以是一个可执行的模块或者是一个库，它独立于其他组件工作，自带相应的状态和管理接口。SWC之间的通信通过AUTOSAR定义的接口进行，这些接口确保了不同组件之间的互操作性和数据交换的标准化。

#02 SWC开发输入

SWC的设计开发工作是软件架构设计领域中一个至关重要的环节。它不仅仅是架构蓝图中的一部分，更是实现软件功能、提升系统性能、确保可维护性和可扩展性的基石。作为软件架构的开发者，整个工作流程需遵循严格的逻辑与系统性，以充分理解和分析软件需求为起点。

按照ASPICE开发流程，SWC的设计属于SWE.2软件架构设计的工作，需要接收来自于SWE.1的软件需求分析输出，基于深入分析的需求，架构师着手规划SWC的设计。这包括定义组件的接口（即对外提供的服务和所需的环境或数据），明确组件的职责范围（即它能做什么和不能做什么），以及设计组件内部的逻辑结构和数据流。在设计过程中，需考虑组件的复用性、解耦程度、与系统中其他组件的交互方式等因素，以确保设计既能满足当前需求，又能为未来的扩展和维护预留空间。

如按照软件需求的PC（Product Capabilities） /Module分析方法论，分析如下主驾座椅加热用户需求Case：

UC 01 : 座椅加热关闭时，手动点击屏幕主驾座椅加热虚拟按键，座椅加热开到2挡

UC 02 : 座椅加热2挡位时，手动点击屏幕主驾座椅加热虚拟按键，座椅加热开到1挡

UC 03 : 座椅加热1挡位时，手动点击屏幕主驾座椅加热虚拟按键，座椅加热关闭

UC 04 : 座椅加热开启时时，且主驾离座时，触发座椅加热关闭

软件架构开发工作者收到类似如下图的分析结果，（副驾座椅加热有同样需求，此处不做额外展示），就可以进行下一步的进行软件架构的设计工作；

软件需求分析

#03 SWC划分

3.1 SWC分层

在SWC设计中，一般开发者会根据经验，按照PC的功能范畴来划分SWC，除此之外，可以考虑采用分层设计的思路，目的是使得SWC具有更好的操作性与可重用性，即使得软件组件可以在不同的汽车平台和项目中复用，减少了重复开发的工作量，提高了开发效率，分层设计也可以将应用软件逻辑层与执行层隔离开来，降低了应逻辑对下层BSW的依赖，提高了系统的稳定性和可靠性。

例如，可以分为SA（Sensors and actuators）层与VC（Vehicle Control）层SWC；

以第二小节中的需求输入为例，可以划分两个SWC：

VC层SWC：主副驾座椅占位状态检测，即接收屏幕按键状态、座椅加热状态，给出加热关闭判定；

SA层SWC：主副驾座椅加热请求与主副驾座椅加热状态检测，综合给出加热关闭判定；

座椅加热SWC划分

SWC内外部交互信息示意

参考上面设计思路，如果座椅加热增加实体按键控制能力，可以放入SA层SWC实现；如果座椅加热增加联动场景，如根据空调制冷状态决定开闭场景，可以放入VC层SWC实现；

3.2 SWC区域化划分

在当今汽车技术日新月异的时代背景下，电子电气架构（EEA）正经历着前所未有的深刻变革，这一变革不仅重塑了车辆内部系统的布局与交互方式，还深刻影响了车辆上电子控制单元（ECU）的角色定位与开发流程。从分布式电子电气架构，到现如今应用最为广泛的域控制器电子电气架构，更进一步的架构发展是为了应对更高级别的自动驾驶需求和不断增加的车辆内部复杂度，区域控制器电子电气架构的概念开始浮现。在这一架构下，车辆被划分为几个逻辑或物理上的区域，每个区域由专门的区域控制器管理，这些区域控制器之间通过高速网络进行通信，实现信息的实时共享与协同控制。

具体到BCM（车身控制模块）控制器，作为车身域中的重要组成部分，其功能在传统架构中主要负责灯光、门窗、雨刮等车身附件的控制。然而，在下一代电子电气架构的演进过程中，BCM的功能很可能会根据区域划分的需求被拆分成左右两个区域控制器来实现，每个区域控制器负责相应侧车身附件的集中控制，为了将应用软件平台化，可以做出如下划分，

座椅加热SWC划分与交互示意

也就是将上一小节中的SA层SWC拆分为主副驾座椅加热功能分别执行的两个SWC，当下一代区域控制电子电气架构导入时，VC层的SWC可以直接部署在中央计算平台内，SA层的两个SWC就分别部署在左右区域控制器中；极大的增强了SWC的重用性；

尽管将SWC拆分成更细致的模块能够显著提升其重用性和灵活性，从而降低开发成本并加速产品上市时间，然而，这种高度的细分化在当前的开发平台上也伴随着一系列问题。具体而言，过于细化的模块划分往往意味着模块间的内部信号交互将显著增加，这不仅会加大系统的复杂性和维护难度，还可能引入额外的性能开销，如通信延迟和额外的处理负担。

因此，作为架构开发者，在决定SWC模块划分的精细度时，必须采取一种平衡且全面的视角。首先，需要深入了解并评估公司当前的开发平台特性，包括其支持的通信机制、性能瓶颈、内存限制以及扩展能力等因素。这有助于开发者在模块划分时避免设计出超出平台承载能力或难以实现的架构。

其次，规划也是不可或缺的一环。开发者需要根据公司长远的发展战略、项目目标以及预期的产品迭代周期，来制定合适的SWC划分策略。这包括考虑未来可能的需求变更、技术升级以及模块间的依赖关系，确保架构既能满足当前需求，又能灵活应对未来的变化。

#04 SWC设计

在设计SWC交互信息时，需要基于软件需求分析报告，我们着手为各个功能模块创建对应的SWC外部接口。这一过程首先涉及对需求文档中明确指出的功能模块与外部系统或组件之间的交互信息进行细致解析。这些交互信息通常包括了通信协议、消息格式、以及触发交互的条件等关键要素。随后，我们根据这些要求，为每一个SWC设计并定义其外部Port、Interface、参数类型等，确保这些信息能够准确无误地反映功能模块与外界的交互需求。

在创建外部接口的过程中，我们尤为注重为每个接口精心规划其参数列表以及相应的数据类型。参数的选择需紧密贴合功能模块的业务逻辑和交互需求，数据类型则必须明确且一致，以避免在后续的开发和集成过程中出现数据不匹配或理解歧义的问题。通过这样的细致规划，我们旨在构建一个清晰、规范且易于理解和维护的SWC接口体系。

此外，除了遵循需求分析中定义的外部交互外，如果我们将功能模块进一步细化为多个SWC时，我们必然需要处理这些SWC之间的内部交互问题。为此，我们需要明确每个SWC之间的交互点，即内部SWC之间的Port/Interface的设定。这些Port/Interface将作为SWC间通信的桥梁，通过RTE负责传递数据和指令。

在确定Port/Interface后，我们还需要为每个交互点详细定义所需的参数以及对应的数据类型。这些参数应当能够完整表达SWC间传递的信息内容，而数据类型的选择则需确保数据的一致性和准确性。通过这样的规划，我们能够实现SWC间的高效、可靠的交互。

根据3.1小节中对SWC的划分设计，给出如下Port设计和展示：

座椅加热SWC的Port设计

接口的设计规范在软件开发过程中占据着至关重要的地位，它通常需要组织内部通过一系列会议商定出来的的准则来确保接口的统一性和一致性。目的是构建一个清晰、可预测且易于理解的接口体系，从而极大地提升开发效率，降低维护成本，并促进团队内部及跨团队之间的协作。

具体而言，接口设计规范应包含以下几个方面来确保开发者能够较为容易地辨识接口所表示的含义及其代表的属性：

命名规范：接口及其方法、参数、返回值等命名应遵循一致的命名约定，如使用驼峰命名法或下划线分隔等，同时确保名称能够直观反映其功能和作用，便于开发者理解和记忆。

注释文档：为接口及其组成部分提供详尽的注释文档，包括功能描述、参数说明、返回值类型及可能的异常信息等。这些文档应采用统一格式编写，如使用Markdown或特定API文档工具，以便于自动化生成和维护。

版本控制：明确接口的版本管理策略，确保接口的变更能够被有效追踪和记录。对于不兼容的变更，应提供清晰的升级指南或迁移路径，以减轻对现有系统的影响。

数据规范：定义接口交互过程中涉及的数据格式、编码方式及数据校验规则等。这有助于保证数据的准确性、一致性和安全性，减少因数据格式不一致导致的错误。

所有关联开发者通过遵循这些规范，可以显著提升软件开发的质量和效率。

Port口对应的参数类型大致上也需要按照上面的约定来制定，这里不会给出详细的规范说明，毕竟由于软件开发的高度灵活性和多样性，不同的开发者或开发团队可能会根据自己的项目需求、技术栈偏好、以及过往经验，对这些约定进行不同程度的调整或扩展。因此，虽然存在某种普遍接受的“一般性”做法，但实际应用中却鲜有完全一致的“普适性”规范。

对于SWC设计的关联信息可以使用表格或者其他工具进行管理，个人设计座椅加热功能中主副驾座椅占位检测SWC设计信息如下：

Data Type 即表明接口的参数类型、范围、单位、初始值等信息，一般需要单独维护：

“一千家开发者有一千八百种开发习惯”，在设计Port、接口、参数类型时，虽然可以借鉴已有的成功经验和行业标准，但更重要的是结合项目实际情况，灵活调整，确保设计方案既符合项目需求，又能够高效、稳定地运行。