目录
1.汽车OTA概述
2.ST如何考虑OTA？
2.1 Stellar四大亮点
2.2 PCM技术视角下的OTA
3.小结
1.汽车OTA概述
随着智能网联汽车的飞速发展，汽车OTA也越来越盛行；
目前来讲OTA分为FOTA和SOTA(Software-over-the-air)两种，区别如下：
- FOTA：Firmware Over-The-Air，从广义上将，就是当一个控制器新增或者修复一个完整功能的代码更新。例如以前改装车通过刷ECU来提升动力；通过升级制动控制器来提升整车的制动性能；通过升级智驾域，可以得到体验更多的智能驾驶辅助功能。例如特斯拉就经常推送自动泊车试用，用起来还挺方便。
- SOTA：Software 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。
