js网站开发视频教程,织梦商城模板,WordPress批量发布插件,公司网站制作专业公司目录
1.汽车OTA概述
2.ST如何考虑OTA#xff1f;
2.1 Stellar四大亮点
2.2 PCM技术视角下的OTA
3.小结 1.汽车OTA概述
随着智能网联汽车的飞速发展#xff0c;汽车OTA也越来越盛行#xff1b;
目前来讲OTA分为FOTA和SOTA(Software-over-the-air)两种#xff0c;区别…目录
1.汽车OTA概述
2.ST如何考虑OTA
2.1 Stellar四大亮点
2.2 PCM技术视角下的OTA
3.小结 1.汽车OTA概述
随着智能网联汽车的飞速发展汽车OTA也越来越盛行
目前来讲OTA分为FOTA和SOTA(Software-over-the-air)两种区别如下 FOTAFirmware Over-The-Air从广义上将就是当一个控制器新增或者修复一个完整功能的代码更新。例如以前改装车通过刷ECU来提升动力通过升级制动控制器来提升整车的制动性能通过升级智驾域可以得到体验更多的智能驾驶辅助功能。例如特斯拉就经常推送自动泊车试用用起来还挺方便。SOTASoftware Over-The-Air个人理解这个更偏向于座舱域的贴近用户的软件增量升级例如IVI某音乐软件的更新、仪表盘风格更新、车机导航地图的更新等等这不会影响整车的动力控制等。 今天我们主要讨论FOTA的升级。由于FOTA是控制器的大版本升级并且响应整车性能因此对于升级流程、回滚和升级条件都有严格的限制条件。当然这些我们供应商就不必烦心了扔给OEM去考虑吧。
一般来讲目前主流FOTA分为2种主要受MCU的eFlash容量影响
单固件升级
该种方式受限于MCU的Flash容量较小只能存放固件和引导程序结构如下 具体实现是应用程序收到指令后将设置更新标志位然后进行复位重新进入BootManager其中Updater根据标志位开始擦除旧APP接收新的APP 数据并直接写在APP运行的Flash地址空间。但是由于该方案不能实现回滚因此衍生出了软件A\B SWAP的FOTA方案。
双固件升级
该方案要求MCU需要更大的Flash容量从软件角度把Flash划分出两块相同大小的区域分为Active区和Backup区均存放APP但在同一时间下只能是一个程序有效运行的。 例如出厂阶段A、B均存有程序但是A为有效程序因此BootManager会跳转至A运行当有升级请求后可以选择在程序A里的Updater去刷写新程序到B区刷写完成后设置标志位然后复位由BootManager选择跳转至B区运行。
很明显这种方式需要编译两次并且链接文件也需要重新定义所以如果MCU硬件本身支持A\B SWAP那就再好不过了例如英飞凌TC3xx的SWAP机制就可以完美解决上述问题缺点是稍有不慎就锁板子。
那么上述两个方法的形成其实都是对MCU的eFlash容量的挑战特别是这种双固件升级假设当前MCU的eFlash容量为10MB那么从使用者角度来说要支持双固件升级可供使用的flash就仅仅剩下5MB了
那么随着跨域融合架构的出现这种容量肯定是无法支持多个功能集中到一个MCU。例如TC4xx支持25MB如果把BMS\VCU\INV等等使用虚拟化融合到一个MCU同时要支持A\B SWAP那么这时候最大可用Flash就只能12MB-13MB了还不考虑Security的独占空间。
这容量显然有点尴尬太浪费了。
那么能不能从物理硬件结构上针对OTA去优化这个机制呢
意法半导体率先亮相。
2.ST如何考虑OTA
根据意法半导体公开资料该公司针对跨域融合推出的Stellar系列有四大特征
高性能CPU、功能安全ASIL D、信息安全 硬件虚拟化支持多ECU集成 硬件加速器 .高效OTA 很明显该公司针对汽车OTA是有自己独立的见解的从上图可以看到MCU在运行模式和OTA编程模式memory空间是不一样的20MB和40MB并且没有多余的消耗也不会停机。
既然是A\B Swap那么个人理解应该是有对应大小的两个物理介质才能完成这和我们之前讨论的没啥区别呢。
但是仔细看上图它在MCU Run Mode写的2 cells/bit一下恍然大悟因为ST采用自研PCM技术用于取代eFlash在设计存储时考虑到OTA特性做到1个bit存到两个Cell这样是否就可以克服A\B SWAP需要两倍容量的存储介质问题呢
我们接着往下看。
3.小结
本节讲了Stellar的四大特征下一节我将继续详细描述OTA。
