这是一个分为两个部分的故事-有关新一轮的汽车开发。 该“系列”致力于EPAM自己的开发，即Aos联网汽车平台。 汽车与嵌入式系统首席技术官
Alex Agizim解释了它与传统云解决方案的不同之处，以及它如何使软件开发人员能够访问汽车。 您可以
在这里熟悉第一部分
。
在第一部分中，我谈到了我们的XEN Hypervisor开发如何将汽车软件的服务部分与安全要求的软件隔离开来。 这是该行业广泛使用的障碍之一。 开源管理程序将首次成为封闭式商业解决方案的成熟竞争对手。
但这只是第一步。 为了将汽车服务提升到一个新的水平，您需要让服务公司和开发人员远离嵌入式和汽车领域。 这需要下一个抽象层次。 这样，在软件开发中使用现代框架的开发人员就可以在无需学习的情况下设计汽车服务。
也许看完之后您会想说：“为什么会有这样的困难？ 例如，我购买了一款用于汽车的Android平板电脑，设置了必要的服务，并感到非常高兴。” 这是一种经典的工程方法，非常有帮助。 但让我们看得更广泛。 从软件的角度来看，汽车行业长期以来一直停留在经典方法中。 我将告诉您我们如何看待她的未来以及我们将如何做。 最后，让我们解决主要困难。
这样啊
为什么需要让服务开发人员进入汽车的车载计算机？ 现在有什么问题吗？
汽车正在变得越来越复杂。 在所有场合它都塞满了传感器，航天器将羡慕机载计算机的性能。 尽管如此，汽车的功能仍然非常有限。 软件开发正在进步，但是90％过去了。
可以比喻为智能手机。 在2007年9月之前，编写可以在不同手机上运行的应用程序非常困难。 市场上有很多操作系统和框架在竞争：Symbian，Motorola，Ericsson等的解决方案。。。具有开发技能的人员很少。 如果企业希望大量人员使用其服务或应用程序，那么问题就始于对不同操作系统和框架的支持。
今天，在汽车行业中确实发生了同样的事情。 为了使该服务得到不同汽车制造商的支持，您必须适应许多框架和一组规则。 单独用于梅赛德斯，分别用于丰田，等等。
当iOS于2007年出现时，一年后-Android-移动行业立即取得了突破。 在AUTOMOBILE中，两个主要范例之间的冲突仍在继续。
首先是传统。
车载计算机是封闭的设备，只有制造商才能使用该设备 。 第三方开发人员在这里没有办法：首先是安全性。 可靠，但并非没有缺陷。 一方面，制造商自行关闭一切。 无需责怪第三方服务的开发人员。 另一方面，不能站在进步的最前沿。 一家汽车制造商无法完全涵盖客户的愿望清单。 开发和市场发布周期太长，即使是非常热衷的团队也仍然有限。 预期的联网自动驾驶汽车将进一步发展。 就像融入共享经济。
另一个极端是将
汽车视为物联网设备 。 也就是说，只需从所有汽车传感器收集数据，打包并发送到云进行处理。 如有必要，重复数千次。 因此，包括Google，Microsoft和Amazon在内的数百个云项目都在尝试监视汽车。 但这有点不对。
汽车不是带灯泡，恒温器和电视的智能家居。 它具有数百倍的传感器和自己的计算能力。 而且-最重要的是-汽车与中心之间的通道是不稳定的。 即使条件稳定，它也不可能每秒要运行数百兆字节的数据。 否则，这种方法是不可能的-服务的整个业务逻辑都在云中工作。
作为回报，我们想出了什么？
我们选择了不同的意识形态。
汽车不仅是传感器的信息来源。 这是一个
成熟的计算节点，服务可以在其上执行其业务逻辑 。
为此，汽车需要一个基本元素-互联汽车平台。 它使您可以将汽车作为软件平台打开。 另一方面，使用云服务中采用的工具来处理应在机载计算机上工作的服务的部署和编排。
如果我们的预测是正确的，那么我们将最终获得一个生态系统，程序员可以按照通常的方式行事，并将部分业务逻辑嵌入到车载计算机中。 就像今天在云服务中一样，它按下一个按钮，启动CI / CD，为所有必要的节点部署所有必要的组件。 在我们的案例中，要部署的节点之一将是汽车。 我们提供了一个可以做到这一点的框架。 因此，我们将云平台称为“汽车Kubernetes”。
我们认为，该概念分为两个部分：- 将安全软件与连接的服务软件隔离；
- 为想要开发或已经在提供联网车辆服务的公司提供必要的抽象级别。 他们不应该为嵌入式服务而烦恼，而应使用其常用工具开发服务，并使用车载计算机作为边缘设备。
车载计算机应成为未来移动服务的边缘计算机。 我们使汽车制造商免于独立发明服务，并向开发人员开放汽车。 智能手机曾经是怎么发生的。
它可以关闭哪些情况？
根本原因是
缺乏连通性 。 在传统的云版本中，该服务将无法访问汽车。 在“互联车辆平台”变体中，开发人员可以预见并预先“刷新”车内逻辑。 而对于云的一部分-至少缓冲数据。
该平台还将有助于显着改善车队管理，车队管理和预测性维护。 与这些服务的云通信，即使不是可选的，也变得不那么流行了。
出租车服务是一个完全可以理解的例子。 现在，它们已在智能手机上实现，可以很好地使用卡和支付功能，但不能考虑汽车的状态。 例如，您迟到了机场，Uber到达-突然发现驾驶员只在部分途中有足够的汽油。 驾驶员无法事先理解。 但是，如果将Uber服务部署在车载计算机中，那么在订购阶段，我可以告诉后端这辆特定的汽车不适合。 而且
服务质量会更高。
对于未来的共享经济，您需要在汽车中拥有一套完全没有UI的服务。 例如，将监视汽车的技术状况的服务（此处也适用Uber和汽油的示例）。 或监视人员驾驶方式并将此数据提供给保险公司或租赁公司的服务。
同时，保险公司或租赁公司需要防止乘客和驾驶员离开或与他们断开联系。 如今，仅在其他电信部门的帮助下才能正常工作的服务使它们扭曲了。 这就是服务本身的购买，安装，集成，编写。 这需要很多时间和金钱。
因此，我们总是从两个方面研究互联汽车。 一方面只是连接到Internet服务。 第二是汽车作为共享经济的一部分。 为此，必须在生产阶段将所有基本元素集成到汽车中。 因此，我们正在与汽车制造商或与汽车计算机制造商进行交谈。
业界的问题之一是由于平台方法不足，无法提出用户案例。 手机也一样。 例如，您可以说有2800家公司为车队管理提供解决方案。 但是它们都是非常单一的。 如果需要更改某些内容，则必须更改车载计算机和电信计算机。 毕竟，我想做一些本单位不能做的事情。
如何安全地关闭从云到汽车的业务服务？ 什么可以防止这种情况发生，我们如何解决呢？
1.容器因为我们来自Kubernetes的思想，所以他的主要技能是部署容器。 但是用车载电脑很难。
首先，即使在Python中我们编写了几行显示“ Hello，world”的代码，容器的大小也可以达到50 MB。 通过蜂窝信道将其倒入可能会或可能不会起作用。 甚至神秘的5G都具有与任何其他连接相同的问题：覆盖范围，带宽，稳定性。 因此，您需要增加机会。
其次，车载计算机在计算能力方面非常出色，但比云中任何最小的服务器都要受限制得多。 在其上运行许多其他程序。 您不能只是来吃掉200 MB的RAM。
因此，首先，我们在OCI标准框架内描述了我们的容器类型。 大小问题可以通过以下方式解决：开发人员操作服务所需的所有基本内容都不需要从云中携带。 它们已经预先安装在车载计算机上。 您只需要携带代码本身，在最坏的情况下，它需要数百KB。
通过在我们的容器规范中对其进行的描述，可以解决车载计算机资源的问题。 因此，您可以非常轻松地确定车载计算机将监视的配额。 并且已安装的服务永远不能超过它们。
2.安全性Kubernetes最初旨在在Cloud中部署和协调服务。 就是说，在受控，支持和防止错误操作的环境中。 但是我们有车，攻击者有无限的幻想。 他们可以拔出车载计算机，用某种设备破解它，进入汽车和云之间的通道。 因此，安全是我们始终不变的首要任务。
我们已根据美国国家安全局的建议实施了高级模型。 它表示以下内容：在设计安全系统时，您必须首先最小化潜在攻击的地点数量，并将安全性作为一层蛋糕。 在某种程度上被黑客入侵？ 有必要注意这一点，并尽一切努力不放过下一个。
在我们的模型中，“饼”如下所示：
- 在Linux OS级别，我们将容器用作一种隔离器。 打破容器是非常困难的。
- 打破容器？ 但是Connected Vehiclle平台在单独的虚拟机中运行-我们需要XEN。 该虚拟机与所有外围设备隔离。 与外围设备的通信只能通过汽车制造商提供的某些API进行；
- 破坏了容器和虚拟机？ 我们还有一个障碍-虚拟机自检：分析虚拟机运行的模式。 例如，虚拟机突然主动尝试获取某种通常不涉及的内存。 您可以响应：关闭此虚拟机，回滚到稳定版本，等等。
3.规模对于有条件的手机银行业务，更新时间对于用户的智能手机是否至关重要？ 不特别。 如果途中什么都没有中断。 对于云服务，扩展问题并不重要。
不能开车。 假设您租了一辆汽车并想使用您的服务，这会给您提供良好的保险政策，因为您的驾驶很好。 但是为此，必须在汽车中安装一项服务，以将您的数据提供给保险公司。
您上了车，将钥匙插入锁中，转身，三秒钟后就可以出发了。 在这3秒钟内，汽车接受旅行所需的所有服务是合乎逻辑的。 但是，如果没有这样一台机器，而是一万台呢？ 将服务部署到汽车上的系统应该能够快速完成此任务。 无论要安装的车辆数量如何，安装时间都应恒定。
我们在RabbitMQ之上开发的插件的帮助下解决了这个问题。 它使您可以轻松扩展和缩减系统，具体取决于您需要使用多少个节点。
4.沟通渠道从云部署到汽车时，必须对通信通道进行加密。 我们使用相互TLS进行身份验证。 它在两个方向上起作用：汽车登录到云，并且云登录到汽车。 所有这些都是基于证书的。 如果证书不合适或有人试图替换它们，将不会进行授权，也无法访问车载计算机。
此外，将容器从云分发到汽车的每个通道都使用自己的一组密钥进行加密。 假设有人窃取了钥匙，证书并且能够进入容器传输通道。 但是他只能进入这辆特定汽车的通道。 指示将是什么。 您可以续订证书，新的Mutual TLS加密将开始对它们进行操作-所有破解工作都化为乌有。 当一个被入侵的证书可能危害所有设备时，这可以使我们免于物联网网络的困扰。
5.多租户想象一下常规的智能家居物联网网络。 它拥有设备制造商和网络运营商。 通常，设备和操作员之间的依赖关系是静态的。 生命周期也非常稳定：如果您开始将一个智能灯泡换成另一个，它很快就会出现，而且您会很少使用。
就汽车和共享经济而言，这些依赖性非常动态。 有一家
汽车制造商 。
有买家/所有者 -假设这是一家汽车共享公司。 有
一个服务运营商。 还有一个最终
用户 。
所有者，操作员和用户可以随时更改。 星期一早上，该汽车属于某个银行，运营商为A公司。午餐后，该汽车已由B公司运营。不同运营商的用户也可以不同。 但是同时，属于它们的服务必须在它们之后针对不同的汽车进行迁移。
这在此处称为“多租户”，并且在我们的服务部署管理系统中得到设计的支持。 服务提供者和服务提供者的角色已经定义；无需其他逻辑。 您可以为一辆车分配不同的服务。 假设汽车转移给了另一个所有者。 上一个的服务将被自动删除，而新的服务将被自动提供。 当今的物联网网络和相同的Kubernetes不适合-它们只是没有遇到这种情况。
6.监视服务的运行为了与汽车服务进行通信，有一个称为VIS的标准化API-车辆信息服务。 它由W3C标准化。 按照我们的概念，此API由汽车制造商实施和控制。 联网汽车服务处于完全控制之下。
不同的制造商开始支持此API。 而且开发人员并不关心为谁提供服务的制造商。
当然，每个汽车制造商都可以例外。 就像智能手机一样：Galaxy S9和S10具有相同的基本API，但每个API都有适合特定型号的功能。 在汽车中，无论类型如何，都可以获得基本信息。 对于特定的事物，他们自己的细微差别。 这使制造商可以提出一些具有附加值的独特而独特的东西。
该平台的组成部分是什么？ 在什么情况下可以编写汽车服务？
该平台本身是用Python编写的。 部署系统的顶级管理是用Python编写的。 整个嵌入式部分都用C编写。
至于服务，我们首先支持Python，并添加了JavaScript。 应几个汽车制造商的要求，添加了.NET。 有关于Java的话题。
总的来说，这是一个战术问题。 没有JavaScript程序员-有程序员。 我认为随着汽车的发展，将出现参与专门连接汽车服务的程序员。 灯泡“如果没有连接该怎么办？”将始终在其头部闪烁 无论我们拥有的是什么-5G或10G。 无线连接无法100％地工作。
汽车制造商对该平台有何反应？
如今，任何汽车制造商都有一个内部部门来开发互联服务。 这些人能够快速工作。 但是它们受到内部硬件和软件部门的阻碍。
我们专注于此。 我们带来了一个工具，他们自己的开发部门可以借助该工具更快，更灵活地工作。 来自嵌入式系统的人员现在正在更改一行代码长达2年，他们将能够在平台上执行一次此操作-然后系统将允许他们独立于它们。
通常，制造商对Aos会非常谨慎。 但是有兴趣-因为它为他们带来了新的机会。 例如，他们可以建立像亚马逊，谷歌，微软这样的商业模式：分配使用板载计算机，API等的服务费。 另外，我认为有一天他们会进入市场模型。 也就是说，软件和连接的服务开发人员将为安装其服务的用户支付佣金。
在移动行业，这很快发生了。 但我们了解：人们并不每年都要换车。 汽车软件开发周期需要4-6年。 因此，我们今天与汽车制造商谈论的话题几乎不会在2022年之前以某种飞行员的形式出现。
我们是要复制特斯拉还是与特斯拉竞争？
不，反之亦然。 与其他公司不同，特斯拉可以通过空中更新在汽车中任何计算机上运行的任何软件。 因此，他们可以不断引入新功能。 但是他们的计算机不是开发汽车共享服务的平台。 您不能购买10辆汽车，不能雇用2位程序员并编写出色的汽车共享服务。 因此，特斯拉也是我们的潜在客户之一。 并从最先进的。
借助我们的平台，特斯拉和其他制造商都无需花费时间来发明自行车。 毕竟，云应用程序中尚无人在开发其Kubernetes。 我们的愿景是，这应该在联网汽车平台上实现。
如果我们通常谈论竞争，那么到目前为止，我们还没有看到一个竞争者至少谈论过我们在谈论什么。 事实证明，汽车行业仍然非常封闭。 平台中的许多功能-对FOTA和SOTA的相同支持-我们不仅仅是因为现在需要它们，而且还提前了。
但是，我不认为将来所有汽车都会有一个平台。
很有可能会有2-3个大的。一方面，他们将团结汽车制造商。另一方面，它们将再次使使用现代编程框架成为可能。我们将看到我们现在无法想象的全新案例。