2024-12-10-汽车嵌入式软件开发与消费电子嵌入式软件开发区别
汽车嵌入式软件开发与消费电子嵌入式软件开发区别
目录
WX:ACarSoft,可领取汽车嵌入式学习路线一份
概述：
本篇文章介绍车载嵌入式开发和消费类嵌入式开发不同，并通过"车门模块的传统嵌入式开发和autosar开发"展示两种开发方式的不同。
汽车嵌入式开发为什么与消费电子嵌入式开发不同？
汽车嵌入式软件开发和消费电子嵌入式软件开发方式完全不同，这种不同概括由两方面造成， 一是产品特性造成的环境和法规差异，二是研发模式的不同。以下内容如果感觉抽象，可以通过最后一个"车门示例"对这些概念进行区别。
首先是产品特性的差异 ：
在嵌入式开发中， 面向环境的产品设计 是重要的考量。显然，汽车电子产品和消费类电子产品的使用环境不同，其工作的环境条件，温度，湿度，外界环境的影响等等都差异很大，比如车载电台，要能扛住高温+85摄氏度的考验，以及零下-40摄氏度的极寒工作条件的考验。
除了从车载电子产品工作环境角度来说明和消费类电子产品的差异之外，还有一个明显的差异是，车载电子产品也有受制于地方性或者行业性的规定和标准，这些行业性的或者地方性的法规和标准大都比消费类电子产品的标准更加严格和苛刻，因为汽车是一个交通运输工具，更多考虑的是使用的安全性和可靠性方面的因素多一些。
其次研发模式的不同：
第一个考量 是软硬件 解耦 。软件定义汽车 （SDV） 是汽车产业向数字化转型的关键趋势， 通过软件实现汽车功能的多样化与个性化，且能通过空中下载技术（OTA）更新软件。 传统消费 嵌入式开发 模式为线性流程，软硬件开发紧密 耦合 ，这用在汽车上会导致开发周期长且灵活性差。
软件定义汽车时代，软件开发采用敏捷开发、螺旋式开发等模式，与整车V型开发模式相结合，实现软硬件开发解耦、协同，支持快速迭代与个性化定制。软件定义汽车通过软硬件开发的有效解耦与持续协同， 使软件开发、验证、交付等不依赖于整车硬件开发进度，在开发各个阶段都能即时释放软件产品。
第二个是保证软件安全性： 汽车软件的复杂性和安全性要求极高，确保软件质量与安全是一大难题。传统嵌入式软件开发，自己定义数据类型，定义驱动等手写代码存在不规范性。在复杂汽车应用场景下，极容易出现代码测试不全面造成的bug。比如手写CAN通信定义数据包解析，在某些场景下就存在通信bug。而汽车软件开发追求软件模块的层次化和模块化，比如CAN通信，你只需调用接口实现通信功能，具体传输过程通过autosar规范进行封装，防止出现人为定义代码产生故障。
第三个是分工工作更便利： 比如主机厂与供应商定义好RTE接口，主机厂也参与到软件开发当中来，因为主机厂了解车辆的使用场景或者说车辆主机厂离用户更近，更了解客户的需求，则主机厂可以负责擅长的车辆控制策略层的的开发，供应商的优势在底层软件开发、以及BOM成本更低，则负责硬件和底层软件的开发。
为什么用autosar？
随着汽车电子的发展，一款现代豪华汽车可能包含多达100个ECU （不理解汽车架构和ECU的看入门基础一文章）。包括从简单的传感器接口到复杂的信息娱乐及远程信息单元。
传统手写代码中，架构深度耦合，比如传统一辆车上用的零件的ECU，如空调的ECU，在A款车型上进行一次开发设计后，可以通过ip台上的实体按键进行操作控制温度。但是同样设备，换到B款车型上做开发设计时，想用中控大屏幕来控制温度，就不管用了，需要从头开始重新开发设计。换句话说，同样的A款车型，想更新换一个空调零件，那麼软件也得彻头彻尾从ECU到车机都得重新来过。
如果通过autosar开发， 将空调的制冷逻辑作为一个模块开发，CAN通信作为一个模块开发，按键接口作为一个模块开发，底层 IO 口作为一个模块开发，最后通过接口集成在一起。当替换不同硬件时，只需要更改底层代码就可以了，像空调制冷逻辑、CAN通信、按键逻辑接口灯模块直接实现复用。
autosar是什么？
用一句话概括 autosar ： autosar就是代码配置规范，根据配置规范衍生出配置工具 。 也就是说， 汽车软件开发的方式是工具配置，而传统 嵌入式开发 是手写代码。
AUTOSAR和传统嵌入式开发在核心方法论和工具使用上有几个关键的区别：
标准化与模块化:
- AUTOSAR: 强调标准化和模块化，定义了软件组件、接口和通信协议的标准，使得不同的软件模块可以更容易地集成和互换。
- 传统嵌入式开发: 通常更注重特定硬件平台的直接编程，模块化和标准化程度较低。
硬件抽象:
- AUTOSAR: 提供了硬件抽象层（EcuAbstraction, Rte, BswM等），使得软件与硬件细节解耦，提高了软件的可移植性。
- 传统嵌入式开发: 通常直接与硬件接口交互，硬件依赖性较高。
配置与代码生成:
- AUTOSAR: 使用配置文件来定义系统行为，然后通过工具生成代码，减少了手动编码的工作量。
- 传统嵌入式开发: 主要依赖于手动编码，配置的作用相对较小。
开发流程:
- AUTOSAR: 遵循更严格的开发流程，包括需求分析、系统设计、组件配置、代码生成、集成和测试。
- 传统嵌入式开发: 开发流程可能更加灵活和简化，但可能缺乏严格的标准化。
可维护性和升级:
- AUTOSAR: 由于模块化和标准化，软件更易于维护和升级。
- 传统嵌入式开发: 维护和升级可能需要更多的手动干预，风险更高。
工具使用（后续文章会详细介绍工具）
AUTOSAR工具:
- 配置工具: 如Vector CANoe, EB Tresos, Mentor Graphics Volcano等，用于创建和编辑AUTOSAR配置文件。
- 代码生成工具: 这些工具根据配置文件生成C代码和头文件。
- 测试和模拟工具: 如Vector CAST, dSPACE等，用于在软件开发的早期阶段进行模拟和测试。
传统嵌入式开发工具:
- 集成开发环境 (IDE): 如IAR Embedded Workbench, Keil MDK, Atmel Studio等，提供编译器、调试器和项目管理工具。
- 版本控制系统: 如Git, Subversion等，用于代码版本管理和协作。
- 硬件调试器: 如JTAG, SWD等，用于硬件级别的调试。
总结来说， AUTOSAR 开发侧重于使用配置驱动的工具和方法来提高生产效率和软件质量，而传统 嵌入式开发 则更依赖于直接编程和硬件特定的工具。AUTOSAR的工具链通常更复杂，但提供了更高的抽象级别和更严格的开发流程，这在开发大型、复杂的汽车电子系统时尤其重要。
车门模块的传统嵌入式开发和autosar开发？
让我们通过一个例子来比较AUTOSAR和传统嵌入式开发在汽车软件开发中的不同。
需求：
假设我们需要开发一个汽车的车门控制模块，这个模块需要实现以下功能：
- 当车门关闭时，自动上锁。
- 当收到解锁信号时，自动解锁。
- 当车辆发生碰撞时，自动解锁所有车门。
传统嵌入式开发方式
在传统嵌入式开发中：
硬件 依赖性 ： 开发者首先需要了解具体的ECU硬件规格，包括微控制器的型号、I/O端口、内存大小等。
直接编程： 开发者会直接在微控制器上编写代码，处理所有的硬件接口，如车门传感器、锁控电磁阀和碰撞传感器。
功能实现：
- 上锁功能：编写代码监控车门状态，当检测到车门关闭时，激活锁控电磁阀上锁。
- 解锁功能：编写代码监听解锁信号（可能是来自车钥匙的无线信号或其他控制单元的信号），当收到信号时，激活锁控电磁阀解锁。
- 碰撞解锁：编写代码监控碰撞传感器，当检测到碰撞时，激活所有锁控电磁阀解锁。
- 集成和测试：开发者需要在实际的硬件上进行集成测试，确保所有功能正常工作。
- 维护和升级：如果需要添加新功能或修复bug，开发者可能需要直接修改底层代码，这可能导致需要重新进行大量的测试。
AUTOSAR开发
在AUTOSAR框架下，车门控制模块的软件开发流程会有所不同：
硬件抽象： AUTOSAR提供了一个硬件抽象层（MCAL），这意味着开发者不需要直接与硬件打交道，而是通过标准化的接口与硬件通信。
模块化设计： 开发者将功能分解为独立的软件组件（SW-C），例如“LockControl”、“UnlockSignalHandler”和“CrashDetector”。
配置： 使用AUTOSAR配置工具，开发者可以为每个组件配置参数，如传感器阈值、锁控电磁阀的激活逻辑等。
功能实现：
上锁功能： 创建一个“LockControl”组件，该组件通过标准的AUTOSAR接口与车门传感器通信，并在适当的时候发送上锁命令。
解锁功能： 创建一个“UnlockSignalHandler”组件，该组件监听解锁信号，并通过标准接口控制锁控电磁阀。
碰撞解锁： 创建一个“CrashDetector”组件，该组件在检测到碰撞时，通过标准接口通知“LockControl”组件解锁所有车门。
集成和测试： 由于组件是标准化的，可以在模拟环境中进行集成和测试，然后再部署到实际的ECU硬件上。
维护和升级： 由于组件是模块化的，添加新功能或修复bug通常只需要更新或替换相应的组件，而不需要修改整个系统，这大大简化了维护和升级过程。
通过这个例子，我们可以看到AUTOSAR开发方法与传统嵌入式开发相比，提供了更高的模块化、标准化和可配置性，这有助于提高软件的可重用性、可维护性和开发效率。同时，AUTOSAR的开发流程也更适合于复杂系统的开发，能够更好地满足现代汽车电子系统的高性能和安全要求。
68747470733a:2f2f626c6f672e6373646e2e6e65742f41436172536f66742f:61727469636c652f64657461696c732f313434333834323237