人们总是对智能汽车未来的样子充满幻想，自从「软件定义汽车」这句话诞生开始，软件就被给予了定义未来汽车的期望。可是随着人与车之间场景的多样化和复杂化的不断提升，谁来定义软件本身呢? 是汽车厂商、供应商，还是软件开发商？
在 4 月 9 日上汽零束 SOA 平台开发者大会上，零束给出了一种新的解题思路。将定义软件和汽车服务的权利开放，不仅是开放给供应商和第三方开发者，更是开放给普通用户。这种开放是怎么实现的？SOA 平台又是什么呢?
什么是汽车 SOA？
SOA 是一个在互联网行业耳熟能详的软件技术，如今，随着智能汽车中软件重要性的提升，SOA 理念逐渐引入了汽车领域。汽车上的 SOA，就是将汽车各子系统中最小功能的逻辑单位抽离出来，封装成服务，组成一种粗粒度小、松耦合的服务架构。这些最小单元的功能模块就像乐高中的基础件一样，既可以互不干涉的独立调用，也能在各子系统中互相兼容。
比如我们将主驾座椅按摩作为一个「基础件」，它既可以单独调用；也可以与疲劳检测功能配合，来实现疲劳预警；同时也可以与其他 ADAS 功能配合，实现其他预警功能。
SOA 平台的运行，离不开中央集中式电子架构这个智能汽车大脑和神经网络的支持。以中央计算单元为核心，通过高速通信技术把智能座舱域、智能驾驶域和智能互联域有机地组织起来，才能实现整车底层功能的互联互通，实现功能的独立调用和兼容交互，将软件结构原子化，做到软硬件的解耦。
因此，在这次的 SOA 平台开发者大会中，我们看到零束推出的「银河」智能汽车全栈解决方案，不仅包括了 SOA 软件平台，也包括中央集中式电子架构、基于物联网 IOT 方案的整车数据工厂、保证整车生命周期内可持续迭代更新的全栈 OTA 和网络安全解决方案。这些基础技术一起，为 SOA 开放者平台打下了坚实的基础。
SOA 平台，给汽车搭载上「APP Store」
以 SOA 理念来打造整车功能，将汽车各功能模块化，是当下很多车企的重头戏，比如宝马在中央计算平台将整车功能进行划、抽取和封装，大众利用面向服务的架构（MEB 架构）来实现软件的可扩展性和复用率等等。而零束这次的惊喜，是把 SOA 软件平台全面开放，让更多的第三方开发者甚至普通用户，也参与到软件功能的打造中。
零束这次把整车的智能控制算法、感知设备和执行设备都封装成统一可调用的服务，将 SOA 平台打造成专业的集成式开发环境。这样一来，汽车的 SOA 平台就像是手机上的「APP Store」，成了软件的孵化器。开发者根据零束提供的可调用服务，开发出各种服务和应用，上传到 SOA 平台；用户可以根据自己的需求，选择订阅自己喜欢的服务。和下载 app 一样，根据功能不同，这些服务有的是免费的，有的需要付费。
在平台的打造过程中，降低门槛，让更多的人参与进来，至关重要。目前零束 SOA 开放着平台分为三种模式，面向普通用户的场景工坊、面向第三方开发者的 Z-ONE Studio Lite、面向 OEM 和供应商的专业版 Z-ONE Studio，类似于「简单版」「高级玩家版」和「专业版」三个模式。
「简单版」，面向普通用户的场景工坊，界面类似于手机的控制系统，在类似 ipad 等移动端可以通过对图形的拖拽和参数选择，定制专属场景，并一键同部到自己的汽车。比如自己设置个「生日模式」，在生日当天启动汽车后，自动触发音乐播放器和氛围灯，用「happy birthday」的歌声给自己一个小仪式感等等。这种模式的设置不仅针对自己的汽车，也能同步上传到平台，看着别人给自己的模式点赞或者订阅，这也许能衍生出一种新的社交方式。
「高级玩家版」，在面向第三方开发者的 Z-ONE Studio Lite 中，采用的是类似流程图式的轻应用架构，通过调整流程图中各功能间的关系和参数，来打造不同的场景。同时平台右侧配合的可视化模拟效果，可以实时模拟车内的效果，让开发变得快速、直观。
如果说面对普通用户和第三方开发者的工具，主要是根据对车内已有的功能进行模块化组合，来打造不同场景，还处在「量变」的阶段；那在专业版的 Z-ONE Studio 上，我们更期望能看到软件功能「质变」的发生。很遗憾在这次的开发者大会中，零束并没有向我们展示专业版是如何具体实施的，这也让我们在期待 SOA 开发者平台的同时，看到了更多的挑战和不确定性。
新的模式下，新的挑战
新的尝试总要面临接踵而来的新挑战，汽车 SOA 平台也不例外。我们从不怀疑 SOA 模式下技术的可行性，不过 SOA 开发者平台带动的全新的用户与汽车交互模式、开发者与汽车和用户间新的商业模式，依然带给我们未知的好奇和挑战。
比如，对于汽车至关重要的安全性问题。 我们能接受从「APP Store」下载的 app 出现闪退、崩溃的情况，但在汽车上对于软件的容错率显然低得多，功能性软件一旦出现问题，在驾驶过程中都有可能造成安全隐患，这显然是用户和车企都无法接受的。安全性的高要求，对平台和 OEM 的监管提出了更高的标准。与高标准的监管相应的，是 SOA 平台准入门槛的提升，而让平台活跃起来恰好相反，需要的是将准入门槛降低。让更多的开发者参与进来，才能打造更强的服务和功能，吸引更多用户；同时更多用户的参与，才能吸引更多更优秀的开发者加入进来。
这就像天平的两端一样，一边是「高标准严要求」，一边是低门槛吸引更多参与者，这种挑战的难度可想而知。
除了安全问题外，智能汽车这个巨大的移动载体承载的海量数据，也造成了不小的挑战。 单就汽车本身来说，将底层打通的中央集中式电子架构目的就是实现功能的互通和数据的共享，但并不是所有数据都适合「共享」，因此就需要在数据分类分级上下足功夫。
更何况数据涉及的不只是电子架构本身，比如，第三方开发者提供的软件产生的数据，究竟是归开发者所有，还是归车企所有呢？
此外，如何调动开发者参与 SOA 平台的积极性，也是个不小的难题。 一个软件开发商在开发手机软件时，只需要做安卓版和 iOS 两个版本，而当软件上车时，要面临数不清的汽车品牌、车型。虽然目前零束 SOA 平台使得软件可以在上汽旗下 R 汽车和智己汽车上通用，但有更多的车型加入进来，降低软件研发的边际成本，显然是开发商所期待的。
与较高的开发成本相对应的问题，是开发者平台将如何实现商业的变现？ 目前座舱内的使用场景，还无法像手机一样实现收入闭环，我们能在手机 app 里直接购买服务、产品，但当类似的购买行为发生在汽车软件上时，我们还是会第一反应掏出手机、扫码，车载软件无法从用户身上直接获得营收……
在尚且没有明确的利益共享的情况下，仅用下载量来打动开发者，动力似乎没有那么足。
最后
尽管在目前的 SOA 开放者平台中，还有很多没有给出答案的猜想和潜在的挑战，但零束的这次 SOA 平台发布，让我们看到了汽车软件敞开怀抱、走向用户的一步尝试，也看到了一种新的未来商业兑换的可能性。至于 SOA 这一步能走多远，不只需要零束和上汽的努力，也需要更多供应商甚至整个汽车行业的参与，共同将定义软件的权利交给大家。