嵌入式软件分层隔离的典范

新用户02834186 2022-11-16 发布于上海

展开全文

引言：嵌入式软件开发分层、模块化是理想状态，实际开发中因各种限制而有所取舍，但这不妨碍学习参考优秀软件架构，即使有部分思想在项目中落实，也是大有裨益的。

1、AUTOSAR的软件分层理论

汽车电子与消费电子不同，其硬件、软件都更关注可靠性、安全性和长效性。其软件需要兼容不同供应商、在不同车型可复用，汽车电子行业的软件架构AUTOSAR（Automotive Open System Architecture）可以作为参考对象。因为不曾使用和系统学习，基于有限信息理解其软件分层思想，可能有所偏差。

AUTOSAR是一种汽车开放系统架构，AUTOSAR规范的运用使得电子控制单元的接口特征标准化，应用软件具备更好的可扩展性以及可移植性，实现对现有软件的重用，提高软件产品的质量。

传统的汽车电子软件开发流程存在很多不足：

1、软件复用性极差
2、硬件平台各式各样，接口难以统一
3、功能差异性导致软件模块化极其有限
4、嵌入式系统不支持硬件抽象

这也是芯片供应紧缺或升级迭代加快，频繁更换物料时嵌入式设备软件开发所面临的问题，重复的无用功太多。

如车载空调ECU零件（Electronic Control Unit 电子控制单元），在A款车型上进行首次开发，可通过实体按键操作调节温度。但是同样的空调、同样的ECU，换到B款车型上做开发时，想用中控大屏幕来控制温度，之前写的控制代码就不管用了，需要从头开始重新开发。或者说，同样的A款车型，想升级换另一个空调零件，那么软件也得重新开发。

深度耦合的架构，导致新项目很难复用以前的代码，几乎每一个新项目都是从头开始。

而AUTOSAR的目的就是建立分层的体系架构和制定接口规范，将分层架构高度抽象，使得汽车嵌入式系统软硬件耦合度降低。

应用软件层专注于业务功能开发，不关注底层硬件细节；基础软件层针对不同的硬件适配提供基础接口，不关注业务逻辑。各个供应商或厂家按统一的标准实现各自的功能，互不干扰。

基础软件层框架：

基础层基于硬件实现基础的驱动功能，类似BSP效果，但进行了一定抽象封装，与硬件解耦。

应用层实现业务功能，为保证业务功能和底层的解耦，中间是运行时环境RTE隔离。RTE是AUTOSAR 体系的核心，支持软件组件间、基础软件间、软件组件与基础软件之间的通信。

AUTOSAR的标准化，使软件开发合作如同堆积木一样，可以按需修改和更换不同的子模块，其核心思想是“统一标准、分散实施、集中配置”。软件系统的开放化和标准化提高软件开发的效率和质量。

嵌入式物联网需要学的东西真的非常多，千万不要学错了路线和内容，导致工资要不上去！

无偿分享大家一个资料包，差不多150多G。里面学习内容、面经、项目都比较新也比较全！某鱼上买估计至少要好几十。

点击这里找小助理0元领取：加微信领取资料

2、软件分层实施

软件分层理论不错，但如汽车电子的AUTOSAR的复杂架构需要工具配置保证接口和规范，对于消费电子或者小公司无法满足条件的，如何结合实情进行简化实施呢？

以电子产品充电时需要亮LED为例，即主芯片的某个GPIO控制LED亮灭的需求，抛砖引玉的发表见解。

主控芯片可能有C1、C2、C3三种，而不同的产品形态导致硬件布局差异，即使都是C1主控方案，可能采用P1、P2、P3三个引脚的其中一个用于LED控制，对于点亮LED，P1、P2是输出高亮灯，而P3是输出低亮灯。

针对这个需求，充电时亮灯属于业务需求，按需求执行亮灯接口；底层提供GPIO输出，对于LED的控制属于运行时环境。为了简化称呼，自定义为三层结构，即平台适配层---功能组件层---业务层 ，最下层为芯片原厂库或者SDK。

软件开发从底层开始，不同的芯片控制GPIO的接口不同，因此需要封装一层，使用固定的pal_gpio_write接口。至于最终使用哪颗芯片的HAL库或者SDK，需要根据芯片类型配置决定，这样功能组件层不关注芯片差异导致的GPIO控制接口差异，只需要关注具体的GPIO引脚，而这个由LED功能里的配置决定。最终提供给业务层的接口就只有led_charge_show()，具体这个接口运行在什么平台、控制哪个端口都是封闭的。对于业务层开发，只需要知道，充电时LED的工作状态执行led_charge_show即可，其内部细节不关注。

这其中除了C源码开发，对脚本处理及其扩展也是软件分层实现的基础，仅仅使用IDE开发工具是无法做到的。按开发环境选择合适的脚本语言，分层配置，最后统一使用某个项目宏，即开启对应的项目宏。编译时选择对应的C文件或者宏定义，实现一套代码选择性的编译匹配不同的硬件主板或软件需求。