美行科技康健：基于位置服务的模块化定制( 二 ) 9月13日

我们先来看一下位置服务百年来的发展，这是1924-1927年的两个导航，那个时候人家也认为将车主很合理地从A送到B是必不可少的东西，这是现在的工具，可以看到从手机到仪表到HUD再到语音播报，这是百年发展下来的结果。
当然我不是说导航多重要，位置服务多重要，这主要就是想证明我上面说的话。我们做了HUD设计、仪表映射设计、IVI交互、语音，但是车主还在使用手机，失败吗？我觉得很失败，这就是我刚才提到的内容比HMI更重要，其实对我是一个鞭策。
很多软件商， Tierl-1 ，主机厂也意识到这个问题所在，问题在哪呢？就是我们所有的应用是分散的，用定位来说就是松耦合，不是紧耦合。那我们要做紧耦合，必须要有一个中心。位置服务跟车、人息息相关，它的延展性非常高，我们在进行生态融合时，要注意专项功能延伸，以及拓展到娱乐件和安全件的信息复用。
再看一下位置中心做到哪些扩展？第一是车的服务的延展性很高，第二在HMI交互上可以打通更多交互设备，第三可以将更多感知内容增加在导航上以带给人更多的安全性。
提到这里又要抛出一个问题了，开发中面临的问题点，我归纳了四个：
1、全栈自研当前还只是极少数，当然不排除有些主机厂或者互联网巨头有那个实力可以做全栈式开发，但是大部分还是集成模式；
2、一般来说，软件封装的层次越高，通用性就越差。当一个引擎定版以后再在上面增加功能，对我们来说是非常难的，这在稳定性、安全性、通用性测试上的时间将远远多于开发时间；
3、不管是在现有模块上进行需求变更，还是新增功能模块，资源占用会越来越高，风险也越大。那么该如何解决资源占用问题？
4、开发得越深入，对开发环境的依赖度也越大，当更换环境时，成本也就越高。为什么现在新能源汽车在平台化上总是比传统燃油车主机厂先那么一步？其实是因为包袱太重，开发越到后面面临的风险越大，虽然技术能力做得到，但在做每个选择时都要非常谨慎。
在这里我们提出就单应用层级来说，我们是否需要一个 “融合插件”？下面我就慢慢解释一下融合插件是什么概念。
我们的想法是在保持基础应用不变的前提下，封装一层插件，保证公共模块的稳定，同时增强整体方案的易扩展性，也就是输入标准化，输出差异化。我们的目的是形态可控，减少依赖，降本增效，架构稳定以及低风险。说白了就是不破坏客户任何一个原有的生态，但是在此基础上做功能开发和定制。我们这个不是赋能，而是把你的能力完全展现出来。
首先看一下标准化输入，我们在最下层级看到有几块，第一，位置服务SDK/API ，也就是传统导航引擎，这里有几个模块，定位、地图、检索、路线、引导、HMI等等，这都可以沿用主机厂固有的，中间生态服务主机厂也可以自主选择，也就是说自动驾驶系统有什么我们就用什么。
在中间层我们做了模块化的功能插件。其中所谓的模块化功能，就是我们将和场景的东西设计成一个一个融合模块，这个模块可以通过中间层打通生态位置和自动驾驶，并且在专项服务的云平台实现功能级的差异。当然，上方唯一入口的检索、定位、设置我们不会去动。
进行标准化输入，再统一进行差异化输出，这是我们最后想要达成的效果。大家可以简单看一下，包括仪表显示、DVR、导航共享、天气和导航的共享融合、人机共驾的渲染、3D渲染、地下停车场的引导等，都可以争取在保证原有供应商体系不变下实现新的迭代。