基于AUTOSAR开发工具链的AUTOSAR软件实战开发-软件架构设计（二）

软件功能模块划分

按照软件功能需求和功能安全等级分割软件功能组件，一般ECU通用功能为例,模块划分先按照功能划分，前面我们提到，对于基于标准AUTOSAR开发，当前无论是整车厂还是供应商，其底层开发均愿意采用基于工具链开发，不论是Vector亦或者东软的neusar，其底层功能都有自己很成熟的功能模块划分，再此不做详细介绍，大的功能模块包含通信模块、诊断服务模块，存储模块，复杂驱动模块几类。

 
对于不同的ECU，不同的整车厂，不同的供应商，由于其功能需求区别过大，甚至可以说是完全不同的需求，因此无法采用完全固定的架构方案适配所有需求，因此对于整车厂和供应商，其架构主要功能模块划分工作在应用层，当然之里面也能抽出一些较为通用的功能，一般会包含状态管理模块，数据处理模块，故障处理模块，控制输出模块，通信信息处理模块等。至于这些模块功能具体怎么细分就需要架构师去详细分析考量了。
 

模块划分重点考虑以下两点：
1.模块功能高内聚，模块间低耦合
在做架构设计时都会考虑的，高内聚可以使模块的可重用性、移植性大大更高。低耦合强可以减少模块间接口。二者相辅相成，一般内聚性高，耦合性就会低。主要方法：
nbsp;   分层设计，应用层架构也尽量采用分层设计，从数据方向考虑，可以分为数据获取层（I/O,CAN/LIN等方式获取数据），数据应用层。比如CAN接收数据，一帧报文有十几个信号，每个信号有偏移和缩放，但是实际使用的信号只有三个，那么数据获取层只需将这三个信号进行偏移和缩放处理，传给数据应用层。从逻辑方向考虑，可分为逻辑策略层，控制输出层。
nbsp;   模块只对外暴露最小限度的接口，形成最低的依赖关系，模块内部的修改，就不得影响其他模块，比如采集温度处理，有二十个温度处理点，但是后续只需要使用最大最小温度，那么就不需要将所有温度对外输出，在数据获取层模块对温度进行求极值处理，然后对外只输出最大最小温度两个接口，这样在温度采样点个数或获取方式发生变更时只影响数据获取层模块，不会对数据应用层模块产生影响。
nbsp;   不允许直接采用全局变量形式进行数据传输，所有对外数据交互均需通过RTE，所有接口均需通过RTE也是AUTOSAR要求的方式，可以保证模块有更好的独立和切割性。

2.功能安全。

随着汽车电子器件越来越多的应用到汽车上，功能安全也越来越受到重视，功能安全需求的加入，在设计架构功能模块时，就多了一个考虑因素，举个例子，对于一个车速采集功能，其功能安全等级要求是ASIL C，但是在TSR（功能安全需求）中拆分为了两条功能安全ASIL A(C)的需求和ASIL B（C）的需求，这样我们在划分模块时也需要将电压采集功能拆分为两个功能模块，一个用于实现安全ASIL A(C)的需求，一个用于实现实现安全ASIL B（C）的需求。（功能安全拆解在此不做详细叙述）

来源：程序猿阿吉