SWC设计前的准备—软件需求分析

阿宝说车

2024-09-16 09:56发布于广东汽车领域创作者

#01
前  言

汽车软件SWC（Software Component）的概念主要来源于Autosar（Automotive Open System Architecture）架构，代表着汽车电子控制器中的软件组件/单元，用以实现某些功能。
          
在SWC设计之前，需要进行一系列的准备和规划工作，以确保后续设计的顺利进行和项目的成功实施。

这些工作主要包括以下两个方面：
          
1. 需求分析

明确功能需求：首先，需要明确SWC需要实现的具体功能，包括输入输出、处理逻辑、性能要求等。这通常来自于项目工程师或产品经理的需求文档。

划分功能模块：将整体功能需求细分为不同的功能模块，这些模块将对应不同的SWC。这有助于实现功能的模块化设计，提高代码的可维护性和复用性。
          
2. 系统架构设计

在明确功能需求的基础上，需要设计整体的系统架构，包括SWC之间的层次关系和交互方式。AUTOSAR架构是一个常用的选择，它提供了标准化的软件架构和接口规范。
          
下面会提供一种需求分析思路与流程。  



#02
需求分析关联方及流程  

SA ：system architect 系统架构师

FO ：function owner 功能负责人

图片

SWC正向设计流程
          

1、用例与功能系统设计 


用例，即Use Case；来源于用户需求；可以由功能负责人分析、设计；

用例（Use Case）驱动的开发方法是一种软件开发策略，它强调以用户为中心的设计思想，确保整个开发过程紧密围绕用户的实际需求进行。这种方法的核心在于，从用户的视角出发，而非单纯从技术或开发人员的便利性角度，来识别、定义和实现系统的功能需求。

具体而言，它包含以下几个关键步骤和特性：

  1. 用户参与与需求捕获；


  2. 用例编写：基于收集到的用户需求，开发团队会将这些需求转化为具体的用例描述。每个用例都详细描述了用户（或系统外部实体）与系统进行交互的目的、前置条件、主要流程（包括成功路径和异常路径）、后置条件等，从而形成一个清晰的、可验证的需求模型。


  3. 系统外部视角：用例驱动的开发方法特别重视从系统外部观察系统的使用情况。这意味着开发人员需要跳出技术实现的细节，站在用户的角度去思考系统应该如何工作，以及用户在使用过程中可能会遇到哪些问题。这种视角有助于避免“内部人”思维，确保系统设计符合用户的真实需求和使用习惯。


  4. 迭代开发与验证：随着用例的逐步细化，开发团队会基于这些用例进行迭代开发。


  5. 持续反馈与调整：整个开发过程中，开发团队与用户之间保持密切沟通，及时收集用户反馈。根据反馈结果，开发团队可以对用例进行必要的调整和优化，以确保系统始终能够满足用户的实际需求。
          
根据上面分析的步骤，可以给出如下用例图的示例，当然也完全可以用文字陈列；

 图片
          
参与者：用户

系统：主驾座椅加热系统

连线表示用户与用例之间的关联
          
如果用文字表述，需要分清晰层次来说明用例，如：

用例名：UC01-主驾座椅加热2档

前置条件：座椅加热状态为关闭&主驾有人

操作：手动点击屏幕主驾座椅加热虚拟按键

后置状态：座椅加热开到2挡   
          
如果需求完善，且实际硬件支持错误检测，可以补充异常路径：
          
异常路径 ：弹窗提示，开启失败

2、能力设计 


PC（Product Capabilities） 或者VC（Vehicle Capabilities）：

是构成产品功能实现基石的核心概念，它源自于精心设计的架构平台。在这个平台上，PC/VC被明确定义为一系列可复用、可组合的基本功能单元，这些单元共同支撑起产品复杂多样的功能体系。在产品的功能设计阶段，开发团队需要深入理解和挖掘PC/VC所提供的丰富能力，作为构建具体功能特性的基础。
          
具体而言，每当面临新的业务需求或用户用例时，设计者们会首先审视并筛选适用的PC/VC单元。这些PC/VC单元就像一块块积木，通过不同的组合方式，能够灵活、高效地搭建出满足特定需求的功能模块。此过程要求设计者对PC/VC有深刻的理解，能够准确判断哪些PC/VC能够直接应用，哪些需要通过微调或扩展来满足特定需求。
          
PC 的设计需要遵循如下原则：

  1. PC具有唯一性：PC的唯一性体现在每个能力单元在系统中的身份识别上都是独一无二的。这意味着，在定义PC时，我们会为每个能力赋予一个明确的、不重复的名称和标识，以确保在整个产品开发周期内，无论是设计、开发还是维护阶段，都能准确无误地引用和识别这些能力。这样的唯一性有助于避免功能重叠和混淆，确保产品功能的清晰划分和高效实现。


  2. PC具有独立性：PC的独立性是指每个能力单元在逻辑上是自洽的，不依赖于其他PC的具体实现细节。这意味着，一个PC可以独立地被设计、测试和维护，而不必考虑它与其他PC之间的内部交互细节。这种独立性提高了系统的可维护性和可扩展性，使得开发者可以专注于优化单个PC的性能和稳定性，而不必担心对其他部分造成影响。    


  3. PC的颗粒度不能太小：在定义PC时，需要仔细考虑其颗粒度大小。颗粒度过小会导致PC数量过多，增加系统设计的复杂性和维护成本；而颗粒度过大则可能使得PC过于庞大，难以复用和组合。因此，合理的PC颗粒度应该是既能够清晰地表达功能需求，又能够保持足够的复用性和组合灵活性。一般来说，PC应该聚焦于解决一类相似的问题或实现一组紧密相关的功能。


  4. PC的重用性：PC的重用是提升产品开发效率和质量的关键。通过定义可复用的PC，我们可以在不同的产品、项目或功能模块中重复使用这些能力单元，减少重复劳动和错误。为了实现PC的重用，我们需要建立一套完善的PC库，并对PC进行详细的文档化和版本管理。这样，当新的需求出现时，开发者可以快速搜索和找到合适的PC进行复用，从而加速产品的开发进程。
          
根据上述划分的原则，可以设计如下的PC来实现上面举例的UC；
    图片

UC示意图
              

3、模块设计 


即Module Design

System Architect在接收到Function Owner的PC需求后，会组织一次跨部门或团队的会议，需要全面评估这些需求对系统整体架构的影响。会议参与者可能包括硬件专家、软件开发者、项目经理及其他相关利益方。通过集体讨论，团队会首先探索是否可以利用现有系统中的PC资源来满足新功能的需要。
          
如果经过综合考量，确定现有PC无法满足新功能的要求，或者采用现有PC会导致不必要的复杂性和成本增加，System Architect会提出新增PC的提议。接下来，System Architect将负责将新增PC的需求细化为具体的规格参数，并依据系统架构的逻辑和功能模块的划分，将这些PC资源合理地分配至最适合的Module。
          
在分配过程中，System Architect会确保新增PC能够无缝集成到现有的系统架构中，同时保持各模块间的独立性和可扩展性。如果遇到没有直接对应的Module来容纳新增PC的情况，System Architect将承担起创建新Module的责任。这包括定义新Module的边界、功能范围、与其他模块的交互接口以及所需的集成策略，以确保新Module的引入不会破坏系统的整体稳定性和性能。
          
整个过程中，System Architect还会与Function Owner保持紧密沟通，确保新增PC的需求得到充分理解和满足，并在必要时对设计方案进行调整，直至达成双方认可的最优解决方案。
          
可以设计如下的Module来实现上面举例的PC，在实际开发中要注意PC的实现不能重复或者遗漏： 
          图片

Module示意图

4、模块部署 

          
在详细规划与实现过程中，首先需明确每个Module（模块）的具体功能及其所需的输入输出接口、处理逻辑、以及预期的性能指标。随后，基于这些详尽的功能定义，我们可以将各个Module逐一分配到对应的电子控制系统中去实现，这一过程涉及以下几个关键步骤以确保清晰性、具体性和条理性：
          
功能细化与分类：首先，对每个Module的功能进行细化分析，识别出哪些是数据处理功能、哪些是控制逻辑功能、哪些是通信接口功能等。根据功能类型，将Module划分为不同的类别，如传感器数据处理模块、执行器控制模块、通信协议转换模块等。
          
系统匹配与选择：根据已划分的Module类别，评估现有的电子控制系统的技术特点、处理能力、接口资源及成本效益，为每个类别的Module选择最合适的电子控制系统。这一步骤需要综合考虑系统的可扩展性、可维护性、以及与现有系统或设备的兼容性。
          
接口定义与协议制定：为选定的电子控制系统与Module之间定义清晰的接口规范，包括物理接口（如GPIO、串口、网口等）、通信协议（如CAN、Modbus、Ethernet/IP等）、数据格式与传输速率等。确保Module与控制系统之间能够顺畅、高效地进行数据交换和控制指令的传递。   
          
根据设计部署经验及原则，上述两个Module均可部署在车身控制器中；

图片

部署示例
      


#03
小  结

至此，我们可以认为已经完成了软件组件（SWC）设计前期的核心任务——软件需求分析。这一阶段的成功标志着我们对系统需求有了全面而深入的理解，并能够将这些需求转化为具体的软件功能要求。然而，上述描述仅代表了一种理想化的正向设计流程概览，仅提供了一个清晰的起点和方向。
          
在实际的软件与系统开发过程中，往往会遇到远比理论描述更为复杂多变的场景。UC与Module之间的追溯关系错综复杂，它们之间不仅存在直接的映射，还可能涉及多对多、层级嵌套或相互依赖的关系。这种复杂性要求我们在设计过程中保持高度的灵活性和严谨性，以确保每一个功能需求都能被准确无误地映射到相应的软件模块上，同时保证模块间的接口清晰、耦合度低，便于后续的维护和扩展。   
          
为了有效应对这些挑战，我们可以考虑引入一系列先进的工具和技术来辅助设计管理。例如，利用需求管理工具来跟踪和管理需求变更，确保所有相关方对需求的理解保持一致；采用UML（统一建模语言）或SysML（系统建模语言）等建模工具来构建系统的逻辑架构和物理架构，直观展示UC与Module之间的追溯关系；通过版本控制系统来管理设计文档和代码，确保设计的一致性和可追溯性；以及利用自动化测试工具来验证设计实现是否符合需求规格说明，提高软件质量。不过工具只是辅助手段，应权衡利弊，不应被其复杂的操作所拖累。 



/ END /

查看原图 33K