多核系统软件的开发和集成挑战

汽车电子的发展相比IT行业要慢很多节拍，智能设备在过去的几年改变了我们的生活方式，相比之下汽车电子则显得不那么与时俱进而脱离于日常的数字生活。

消费电子与汽车电子有两个很重要的区别：汽车电子在安全性和可靠性方面的严苛要求是消费电子要求无法比拟的，毕竟汽车电子是关系人身安全的大事，任何的疏忽都会造成严重的质量问题和乘客的生命财产安全，因此汽车电子不能像IT行业那样整天追求日新月异的新玩法而应将安全和可靠的目标放在首位（个人认为用一句话形容可能更贴切：IT行业大都是一群抬头望天的梦想家，而从事汽车电子的攻城狮则是一群低头填坑的人），在过去的很多年，整车功能并没有当前那么复杂，在满足功能、安全和可靠性的前提下， 8位、16位和32位的单核处理器即可Handle。

但最近这些年，汽车新四化的脚步已势不可挡，也给汽车电子带来了深刻的变革，整车功能需求的增加和IT技术的渗透结合已使单核处理器无法满足当前和未来的要求。

为什么需要多核处理器？

楼主主要基于四点阐述一波原因：

1、汽车电子电器架构和整车功能越来越复杂，需要计算能力更强大的硬件来支持越来越复杂的软件功能，随着ADAS、自动驾驶等应用场景的加入及未来域集中甚至中央计算机的E/E架构变更，多核系统的需求将更加明显。

2、并行计算的需求：例如某些功能的输出计算需要多个输入要素在相同时间片内执行并在同一时刻输入到该功能模块。

3、相同时间片内多个任务的串行计算需求：例如多个功能需要在相同的时间内被串行执行。

4、系统响应能力的需求：例如对于那些对时间要求特别高的中断处理需要单独在一个核上运行，而周期性任务则放到另外一个核上运行，从而提高整个系统的响应能力。

各芯片供应商推出的多核处理器

多核处理器从内核架构上主要分为：同构和异构处理器两类。

异构多核架构：MCU由多个不同架构的内核构成，例如恩智浦LPC54114（一颗Arm® Cortex®-M4核和一颗Cortex®-M0+核）；LPC4370（一颗CM4 Arm® Cortex®-M4 和两颗Cortex®- M0）。在异构多核处理器中，一般都会使用高配主内核+低配小内核的配置（主内核用于执行批量应用处理），较小的内核被称为协处理器（主要用于处理一些不太复杂的操作，比如持续在I/O上发送数据；因此即使有第二个内核存在，由于它的作用是支持或补充主内核，所以被称为协处理器）。

同构多核架构：即在MCU中采用多个相类似架构的内核。多个核可同步或异步运行相同代码和应用。同构多核架构中有一个锁步模式，而这个锁步模式是保证安全应用的关键。

在汽车电子领域，芯片供应商主要有这么几位大佬：英飞凌（Infineon）、恩智浦（NXP）、意法半导体（ST）和瑞萨（Renesas）等，在最近几年都已经推出了支持Autosar架构的多核处理器。

1、英飞凌（Infineon）

1.1   Infineon AURIX TC27x系列处理器具有三个32位TriCore架构内核，其具有两个支持锁步的内核（1.6P和1.6E）及一个非锁步核（1.6P）。所谓的1.6P是一种超标量核，一般TC 1.6P核的性能比TC 1.6E高出10~20%。

该处理器支持应用的领域如下：

1.2   Infineon AURIX TC29x系列多核处理器具有三个32位TriCore架构内核，只不过只具有一个1.6P锁步核和两个1.6P/1.6E非锁步核。

2、恩智浦（NXP）

恩智浦MPC5777M多核处理器具有三个32位Tri-Core内核，其具有两个主频为300MHz的计算核心e200z7（一个锁步核一个非锁步核）和一个主频为200MHz的外设核e200z4。

总之各大汽车电子芯片供应商都有各自的多核系统解决方案，这里就不再累赘。

多核系统软件开发集成所面临的挑战

多核系统的软件开发集成相比单核，在项目时间、复杂度、成本以及给攻城狮带来的额外工作量都是成倍增加的。

1、满足ISO26262功能安全的挑战

多核系统的应用一方面是为了提高计算能力，另一方面则是通过多核可实现不同ASIL等级的拆解，但在多核系统中实现ISO26262定义的功能安全却并非易事。要想在多核系统上实现一定的功能安全设计目标，会对硬件和软件两方面产生一定的影响。

在硬件方面，可能就是多核处理器的锁步概念：在锁步模式下，两个核分别执行相同的代码，独立的比较器对两个核的计算结果进行比较，并在出现差异时生成一个trap。之后的处理取决于ECU的硬件条件和安全架构，其中硬件设计上必须确保在trap发生后ECU仍然处于安全状态（锁步核的增加不是提高计算能力的多核架构，而是一种保证系统安全的多核机制，个人的理解）。

而在软件方面，开发人员根据软件的可并行性和相关安全架构，将上层软件模块分配给AUTOSAR中定义的OS Application。这一分配过程对应于ISO26262中定义的'分区'，且该过程能够使ECU在运行时不会引起内部区域的相互干扰。

在多核ECU中，OS Application被分配给不同的处理器内核。从开发人员的角度来看，分区的主要目的并非程序并行性或是程序安全性：首要任务是确保OS应用程序之间不受互相干扰。为此，尤其需要引入运行时监控（Runtime Monitoring）并避免对安全相关的存储器内容进行篡改。

2、合理分配各核计算负载

在进行功能模块在不同核上的分配时，需要考虑各核运行负载的均衡性。

影响CPU运行负载的因素有很多，下面主要列举几例：

2.1  复杂应用的运行，如自动驾驶应用。

2.2  高速和先进通讯的应用，如Ethernet,，CanFD和面向对象通讯方式的应用和转变。

2.3  功能应用之间复杂的调度和耦合关系，例如周期性和中断任务的执行会涉及多个功能函数接口的同时调用，而各个函数运行所需的输入量又由其他模块计算得出。

3、多核系统数据一致性挑战

在多核系统中由于协作式和抢占式任务在优先级和不同核上的配置和分配，数据一致性的问题尤其需要关注。

对于多核系统的数据一致性问题，之前楼主分享过一篇《什么是Data Consistency？》，具体的概念及解决方案里面也有相应介绍，这里也不再累赘。

4、功能模块在不同核上的合理安排

首先在多核系统上功能集成可能有如下几种方式：

4.1  为了降低成本，将原先分别在单核运行的应用放到互不干扰的多核处理器上，每个核的软件仍然跟之前一样互不干扰各自运行。

4.2  应用遵循同一种软件架构标准集成，如Autosar的软件架构，那么每个核都有各自的一组任务、中断和Autosar应用SWC。在Autosar 多核的支持下，OS可允许跨核的任务激活和通过IOC机制的内核间通讯。

4.3  应用不遵循同一种软件架构标准，如既有Autosar的应用又有非Autosar应用，这种多核应用的集成方式在Autosar还未支持多核的早期比较多见，在这种情况下，Autosar应用与非Autosar应用则通过复杂设备驱动层（CDD，就像楼主之前说的复杂设备是个框，任何不能标准化的都可往里塞）通讯，这样非Autosar应用核可处理对时间要求严苛或频繁的中断。

根据上面所述的三种软件集成方式，在应用的分配上是灵活的，例如，我们可根据不同的供应商将各自的功能模块分配在不同核上，但事情并没有想的那么简单，分配的原则要考虑很多因素，例如不同功能模块之间的耦合度和关联性等等。

这部分所述话题，楼主主要基于个人理解的四点进行了阐述，也欢迎各位大佬继续补充。

多核系统解决方案和总结

随着Autosar对多核系统的支持，汽车电子多核系统的软件开发和集成应该有效利用Autosar标准，在Autosar软件架构的支持下高效利用每个核的计算能力和资源。例如将BSW层分配在一个核上，通过OS和RTE的支持，可将Autosar的软件组件（SWC）分配到不同核上。

文末了，卖个情怀，首先端午节很快就这么嗨皮的结束了，给大家送去迟到的端午祝福：端午安康，目测我们离下个假期还依然遥远。其次，公众号创办半年多了却没想到增长的很迅速，公众号的创建也纯属一次偶然，创建后楼主基本是漫无目的的随心情更新，毕竟因工作楼主的精力有限，因此没怎么去运营打理，但却得到了很多同行的认可和支持，楼主的文章也被多个公众号所转载，同时也收到了多个所谓的合作需求或约稿，但楼主基本都拒绝了，因创建此公众号的初衷并不在此，对楼主来说能得到各位大佬的指点和支持，大家共同学习进步就足矣，平时陌生童鞋一点小的打赏和广告点击足以鼓励楼主继续搞下去，也希望自己能再接再厉，进一步提升文章的质量，给大家带去更优质的内容。OK，情怀卖完，最后听首歌赶紧的压压惊。