汽车领域：自动化编译框架
问题与挑战
随着汽车电子电气架构从基于多MCU的分布式架构发展至基于高性能计算中心的集中式架构，对于软件开发人员而言，将已有硬件平台上的应用进行复用或迁移是一项庞大的工作。在进行开发时，开发团队经常遇到的棘手问题就是如何将已有的软件算法快速编译和部署到不同的硬件环境或平台上。
此外，由于全球疫情以及政治问题的影响，芯片出现产能不足或面临断供的问题。因此芯片的反复变更在所难免，由此导致集成开发环境反复切换，这极大地分散了企业聚焦新功能开发的精力。
如何提供自动化编译框架用于解决硬件平台的切换以及屏蔽硬件差异，更好地实现应用的快速开发和部署成为一个重要的课题。下文会给出通用自动化编译框架的解决方案以供参考，并对提供自动化编译框架的意义进行展望。
解决方案
自动化编译框架采用基于模型的方式进行，通过模型屏蔽不同层级的细节，从而实现解耦以及快速复用。自动化编译框架的组成如图1：
▲图1 自动化编译框架一般组成
自动化编译框架由4部分组成（即硬件层之上的部分）：
模型层
实时框架抽象层
目标平台抽象层
第三方或遗留代码
接下来对自动化编译框架的组成及运行原理进行详细介绍。
2.1 自动化编译框架组成介绍
模型层
模型层内部存在两层，如图2所示，分别为平台无关模型（Platform Independent Model, PIM）和平台特定模型（Platform Specific Model, PSM）。PIM和PSM的理念来源于模型驱动架构（Model Driven Architecture, MDA）理论。
在进行应用开发时，开发人员应当使用PIM。工具应当根据应用开发人员的设置将PIM转化为PSM，即，第一步由开发人员创建一个平台无关模型PIM，第二步由工具将平台无关模型PIM转变为针对不同编程语言的平台特定模型PSM。
▲图2 模型层
实时框架抽象层
框架是在给定域下的、可以提供一系列服务的协作类的集合。在构建复杂系统的实践中，一个常用方法是使用预定义的框架。而在自动化编译框架中的预定义框架具有实时性。
实时框架负责为软件系统提供体系指导，需要提供实时抽象用于构造和生成PSM中描述的模型的代码。如图3所示，实时框架需要包含行为层、服务层和操作系统抽象层。其中，行为层提供了一系列的协同类组成架构基础，提供面向对象的、响应的、多线程的行为；服务层包含了内存分配和对容器的支持；操作系统抽象层提供了操作系统服务的抽象，便于行为层使用操作系统服务。
框架提供实时抽象的目的是针对不同的硬件资源和有无操作系统的情况下进行应用管理、调度等工作，需要注意的是实时框架抽象应当是操作系统无关的，即其需要提供操作系统的抽象用于解耦。
▲图3 实时框架抽象层
目标平台抽象层
该部分的工作即为根据硬件平台将实时框架代码进行编译和构建。在该部分需要集成编译工具链将代码自动编译为目标环境的库或可执行文件。
目标平台抽象层的目的是抽象硬件运行平台，来屏蔽运行在x86或ARM上的软件。需要注意的是操作系统不一定是必须存在的，这是因为对于资源较少的硬件而言是没有操作系统的，实时框架抽象层需要针对无操作系统的硬件平台提供框架的支撑。
第三方或遗留代码
该部分类似于AUTOSAR CP中的CDD（复杂驱动），其目的和意义是为了将已有代码进行快速复用或集成第三方非模型形式提供的库。
2.2 自动化编译框架运行原理
下图描述了自动化编译框架的运行机制，以模型为切入点，展现出由模型到代码到库或可执行文件的转变过程，并且对不同阶段的扩展性进行了说明。
▲图4 自动编译框架运行原理
在使用自动化编译框架时，负责自动化编译框架的工具以及在其运行中涉及的不同人员和角色的工作及内容总结如下：
基于模型的方式，通过模型抽象屏蔽细节
模型层面，应用层应当为平台无关模型（Platform -independent Model, PIM）；
模型生成代码应当为平台特定模型（Platform -specific Model, PSM）在这一层应当暴露实现语言信息，例如C/C++/Java等；
应当存在操作系统抽象层（Operation System Abstraction Layer, OSAL），用于屏蔽操作系统和PSM模型，在最终生成代码时，根据不同的硬件平台的操作系统进行适配。
对于存在操作系统的硬件平台，应当提供对应硬件平台对OSAL的实现；
对于没有操作系统的硬件平台，应当提供中断、内存管理、仲裁等服务的抽象。
模型使用
开发人员只负责PIM的模型搭建，和PSM的语言选择。PIM到PSM的映射应当是有专用工具自动实现的；
专用工具应当开放PIM和PSM的适配规则接口，便于更好的扩展和更新；
专用工具应当自动依据硬件平台选择适配和实现OSAL，并且提供接口用于对未来的新平台的支持。
意义与展望
自动化编译框架的目的是，提供一种能够针对应用开发屏蔽编译差异，可扩展、利于编译框架平台化的理念和方法，其能够解决硬件平台带来的差异化问题。整体而言，应用自动化编译框架能够获得的潜在收益有五个方面。
3.1 软件与硬件平台解耦
在软件开发中，将软件和硬件进行解耦是首先需要解决的问题。由于不同的硬件厂商会提供不同的开发环境和集成环境，在进行硬件切换时，会出现由于底层耦合导致的应用切换问题，从而出现了硬件约束软件的情况。在实际工作中，如果没有一个统一的编译框架的约束，会存在人为的或不同工具链之间的集成问题。
通过使用统一的自动化编译框架和集成环境，可以解决不同阶段不同层级的软件集成问题，从而能够在流程或工具层面进行约束，真正地获得软件和硬件平台解耦带来的收益。
3.2 软件与运行环境解耦
软件需要编程语言去编写和构建，而任何语言都需要自己的运行时环境。开发团队在开发应用上一般都会配置好软件的开发语言，例如在动力、底盘等领域，我们倾向于应用C语言进行相关的开发；在智驾、智能网联等领域，我们倾向于使用C++；在车机、座舱多媒体等领域，我们倾向于使用Java或Android。因此在应用开发时需要确认开发语言和掌握该语言的团队成员。
但是随着软件比重的日益增加、硬件资源的扩展提升以及用户体验的快速迭代，我们会面临将原来采用某一种语言开发的程序迁移到另一种语言的情况。在这样的情况下，如何更好地复用软件来屏蔽掉运行时环境的问题变得尤为突出。
自动化编译框架在应用开发阶段屏蔽了编程语言，从而实现了软件和运行环境的解耦。
3.3 软件快速跨平台迁移
软件开发过程中我们一般会通过交叉编译来解决开发环境和实际运行环境的差异，具体表现为开发人员的IDE一般是运行在x86 Windows或Linux上，而目标环境一般为ARM。因此在软件开发中一般是需要开发板进行调试和运行测试的。
通过自动化编译框架，使用系统抽象层来实现快速的跨平台迁移工作，从而做到在开发板未提供时进行开发和编译调试。同时结合虚拟硬件技术，可以做到虚拟调试目标平台下的应用，从而极大地减少了硬件的需求并提前了软件开发阶段。
3.4 应用与基础组件解耦
可以通过自动化编译框架实现应用和基础软件的解耦，从而加速应用开发工程师在应用开发的效率，减少其对基础软件的依赖，从而将更多的创造力投入在应用开发本身。
3.5 更快速地复用和部署
解耦以及便捷的平台给予了不同领域开发工程师良好的知识封装，使得各领域开发工程师能专心在其领域进行开发。通过更好的分工以及依赖解耦，更快速地进行复用和部署。
