8月26日，由盖世汽车主办的“2021行业首届智能汽车域控制器创新峰会”于上海汽车城瑞立酒店隆重召开。本次会议持续两天，将围绕智能汽车、智能驾驶域控制器、智能座舱域控制器、底盘及车身域控制器、智能驾驶计算平台、电子电气架构、软件定义汽车、车规芯片等行业焦点话题展开。会议期间，诺博汽车科技有限公司副总经理李哲哲发表了《智能座舱域控制器的量产解决方案》的主题演讲。

诺博汽车,域控制器

以下为演讲实录：

非常感谢有这个机会跟大家进行分享。

首先介绍一下诺博科技，我们给自己的定位是为全球客户提供驱动未来出行的系统解决方案，目前业务板块比较广泛，有智能座舱、智能网联、智能车控、智能驾驶。

目前我们有四大能力中心，在上海是电子研发总部，有300+工程团队，具有全栈研发能力，包括系统、硬件、软件和测试。同时我们在南京和成都也建立了软件开发的分中心，各具备100多人的团队。同时在张家港建设了工艺和制造中心，一期产能150万，预留1万平米，总产能可能达到200万，甚至高峰期能达到400万的水平（具体产能需要再确认）。同时我们部署了一个大的实验中心，可以做硬件测试和EMC测试。

今天主要分三个方面进行介绍：1、诺博科技智能座舱战略；2、域控制器平台化开发模式；3、域控制器系统解决方案（硬件方案、软件方案、测试方案）。

诺博科技智能座舱战略

诺博科技智能座舱战略是以域控制器为核心，整合端技术，打造跨域融合，云端一体数字化座舱，包括域控制器（座舱、车身、驾驶），显示屏包括in-cell显示屏和OLED显示屏、曲面屏、异形屏，还有智能座椅、智能内饰联动。

在智能座舱方面我们建设了全栈能力，包括云端、车机端，有端到端开发的能力，我们在北京也成立了生态开发公司，近期也会很快正式开始一些车型的开发。

这是我们正在建设的核心能力，实际上在前两年开发过程当中也逐步把核心能力建立起来了，包括硬件的能力、软件的能力、网络技术、功能安全、测试验证等等。

这里给大家分享一下我们过去两年时间里在座舱域控制器开发的心得。现在域控制器非常贵，开发一个项目都是上亿的投资，车企不可能同时开几个项目，一开始对我们的要求就是平台化，但是车型非常多，品牌非常多，一年有十几个车型要上，每个车型都有自己的要求，这个要上AVM，那个要上RVC，这个是14.6的屏，那个是10.25的屏，这是百兆以太网，那个是千兆以太网，并且车型和车企之间为了差异化，不想让自己的平台和别人的平台有重复性。对于我们Tier1来说是很大的挑战，我们不可能同时开几个域控制器的平台，我们也总结了一些经验，在软件方面、硬件方面如何做平台化。

软硬分离这是平台化的基础，其实现在已经达成共识了，很多车厂也都在往这个方向走，无论是开发周期，还是迭代周期都非常短，这样才能把成本和开发费用降下来。具体来看，在域控制器的开发过程中，在安卓侧做了解耦，这样可以快速用一套操作系统底层，用一套硬件平台可以对应几个车型的开发。

这是座舱域控制器平台的规划，目前已经投产的是IN9.0，基于高通的8155，最大可以支持6块屏幕，目前因为分辨率原因是支持到5块屏幕，有百兆、千兆以太网，内置AVM，目前我们已经开启了下一代座舱域控制器的开发和预研，再下一代也在做一些芯片平台的交流。

具体来看，IN9.0座舱域控制器平台，是基于高通8155芯片平台，7月30日实现了投产，今年是几万台的规模，明年可能会达到百万台的规模，但是现在芯片缺芯产能会受到影响。在这个座舱域控制器当中集成了抬头显示、数字仪表盘、中控信息娱乐、空调面板控制、副驾影音娱乐，还有驾驶员疲劳监测、乘员/行驶监控、高清360环视等等。

这是座舱域控制器简单能力的介绍，现在输出是有5块屏幕，摄像头目前支持9路输入，主要支持DMS、OMS、RVC、360环视应用。音频输出是内置一个DSP和功放芯片，还支持8通道输出，同时支持外置A2B用于品牌音响，音频接入能力最高支持6路麦克风及车载互联包括百兆、千兆以太网、USB3.0等等都是可以的。

这是我们真正量产的产品，具体来看，架构设计有一个8155，SOC高性能处理器，同时还有一个微控制器来处理实时性的，还有以太网交换机，同时支持USB充电、LVDS解串器，我们有64GB闪存、12GB内存，支持Class-D音频功放，同时支持音效DSP，支持LVDS串行器、蓝牙wifi模组。

域控制器平台化开发模式

这里说一下硬件方案，在硬件产品集成化方面先做全功能的设计，甚至互斥的功能都放在一块板子上面，基于配置不同进行选贴。功能模块化主要是可以把每一个模块进行定义与分解，这样能大大加速开发的进程。同时在接口方面也做了标准化，把车企不同的品牌，不同的车型，不同的配置所要连接的线束和基板装配和车辆接口全部统一化、标准化。具体产品结构图，我们用的是被动散热的镁铝合金壳，这里用了高速PCBA、低速PCBA。接口标准化，这里有AVM接入、USB的输出、电源插头、以太网等等。

系统架构的设计，刚才提到我们有一颗MCU，在上面运行的是AUTOSAR，主要是做系统电源管理、安全监控、ASIL安全相关功能、QM非安全相关功能。在SoC上通过虚拟机形式支持仪表应用和安卓应用，在QNX和安卓之间做了软隔离。实时性数据就通过MCU来做处理，对需要强大计算能力的比如说视频处理就跑在8155上面。

这个是虚拟化技术Hypervisor，SOC和外部硬件资源虚拟成软件资源，处理不同的信息需求。具体来看，SOC侧软件架构通过QNX应用层支持HUD，RVC，AVM等。安卓侧应用层支持Navi，Media等。

其实刚才提到了硬件要平台化，软件也需要平台化，因为车型太多了，每个车型的配置和功能又不一样，车型最起码都有高中低配，甚至还有五个配置，因为功能越多配置越多，怎么样把这么多配置通过软件平台化适配，目前我们是通过配置字的形式。在HMIQNX侧应用中间件通过配置文件把不同的功能，通过DTC方便配置。安卓侧都是基于安卓原生HAL接口，安卓原生之外的HAL接口进行扩展。

驱动开发平台化，适配不同硬件配置。现在因为缺芯原因，基本上每个模块甚至每个外设都要有1-2家备份，这个怎么办？因为每家技术是不一样的，我们通过驱动开发的平台化来适配不同的硬件配置。

仪表开发平台化也是通过提供统一标准的接口来适配不同车型功能需求，大家也都知道，现在车型动力特别多，有燃油，燃油还分好几个T，有PHEV，还有HEV，车企现在都把它做成平台化。那么域控制器怎么平台化？特别在仪表端电车和油车是完全不一样的，有些车厂平台化做的也不是特别好，同一个车型1.5T和2.0T，甚至不同HEV动力形式都整出好几套DBC来，怎么吸收掉也是非常考验开发能力的，在仪表端我们通过这样的形式尽量吸收这种差异。

HMI开发，没有一款车希望自己的HMI界面是和别人一样的，我们域控制器硬件是一样的，软件架构是一样的，怎么体现HMI差异性？也需要在HMI开发过程中做平台化架构，让你很轻松的换一张图片，整个用户体验就是不一样的。

域控制器系统解决方案（硬件方案、软件方案、测试方案）

硬件测试，我们搭建了基于NI板卡和Lab View软件，开发专业测试平台，通过程序控制，实现不同产品的自动化测试和报告生成，这是基于自动化测试系统执行严格DV/PV测试，保证其可靠性。

软件测试，这是软件集成自动化测试，不同脚本对应不同的项目，通过自动化测试平台大大减轻人工测试和缩短测试时间，因为现在域控制器开发车企对时间要求是非常严格的，这里就需要大量自动化和敏捷开发形式来做，在过去两年我们也是从很痛苦的阶段慢慢摸索出。软件测试虽然测试时间压缩了，但是测试项目一个也少不了，包括功能测试、网络诊断、兼容性测试、压力性能实车测试。

以上是我的分享，谢谢大家。