有读者朋友让我介绍一下“云边端”的技术架构，一直以来个人觉得这种架构整体分层清晰，架构设计上也没有难点，所以一直也不作为一个重点去说。我们公司从做数据采集和企业数字化转型开始，基本上这种“云边端”的设计思路一直保持到现在，同时也是我为很多公司做项目落地、实施的时候优先采用的架构模式。这里刚好有读者朋友提出来了，我也就趁着这次机会来说明这种架构模式，同时也尽量将这个架构能从不同的角度来说明，给大家一点不一样的启发。 “云边端”的方案最早我是2016年看到一篇论文，当时那篇论文是写边缘设备设备在电力行业中，形成的新的架构模式。那篇论文应该是我看到前几年就已经写出来了，但是当时并没看懂文章的内容，不太理解云、边、端是什么意思。直到到了2019年，边缘计算的概念兴起，当时所有的设备都宣传自己的是个边缘计算设备，或是自己的设备可以进行边缘计算，集成了边缘计算的能力，那火热程度就和现在都说自己的设备是AI终端一样，当时我们的项目方案中也会无论懂不懂，都会加入边缘计算这种类似的内容，以表明自己的方案的“先进性”。再后来我也开始逐渐进入物联网、工业控制的行业领域，“云边端”的架构方案在我公司已经形成了自己的一套完整的架构系统平台，我们有自己研发的端侧传感器设备、端侧采集设备、边缘计算设备；同时有与之配套的端侧采集设备的RTOS、边缘计算设备的定制Linux系统；另外也建立了端侧采集设备、边缘计算设备的监测、控制、运维管理一体化的云端管理平台和开发体系；通过边端、云端的二次开发平台和相应的开发体系，我们可以实现对市面上绝大部分公开协议的无开发对接，以及私有协议的定制开发对接，这也是我公司承接各种定制化数据采集项目、数字化项目的基础能力。在很多项目的实践中，我们也会套用“云边端”的设计模式进行设计和思考，这种架构模式在分摊计算压力，提高系统性能，增强多系统协同能力方面有着明显的优势。
说了这么多题外话，我们来逐个拆解“云边端”的架构设计方案。我们先要明白，“云边端”整个方案出现是在云计算兴起之后，其本质就是用来解决云计算的不足出现方案。所以这里云指的就是云计算，云计算、云资源这里就不再详细描述，现在云计算已经作为一种基础的信息服务能力，有各大厂商提供。这里我们先来看计算架构模式这么多年来的是演变发展。
在云端架构无法满足超低演示、巨量接入设备的背景下，云边端架构方案开始被使用。云边端架构图如下：
上图中：
{
"commands":[
{
"callType":"5",
"callVale":
{
"no": "1#303"
"temp": "25"
},
"taskId":"T000001",
"sn":"300XXXX"
}]
}很明显，这种命令格式不可能被空调设备进行识别，将这个命令传输到边缘计算终端后，边缘计算终端通过查询采集设备和地址的对应表，可以知道1楼303房间的设备是YORK空调，设备通讯地址为03，这时候通讯计算设备就将云端下发的控制命令依据设备类型进行转换为通讯控制协议，最终发给空调设备的数据可能如下：
03 01 00 00 00 09 FD EE最终空调收到这个指令后，执行这个指令，将空调温度调整到24℃，完成了整个控制过程。
上面就是详细描述了“云边端”架构中，数据通讯的方式和流程。下面我们就来看几个"云边端"方案的具体业务实现架构。
电力行业“云边端”架构：
在这个架构中可以看到，他们将边缘计算节点形成一个机组集群，称之为“边缘计算中心”，还特别标注：“众多小型服务器机组”。单从这张图来看，这个架构并非传统意义上标准的“云边端”架构。前面我们介绍过，“云边端”架构提出的背景之一是解决低延时问题，而这张图中边缘设备依然作为服务器集群被放置在远离设备本身的地方，所以这里的边缘计算中心更像是将云端功能的下放和拆分，形成类似二级处理中心的概念，主要是用来分摊计算压力，或是用来对屏蔽系统差异。
上面这张图就是比较标准的“云边端”架构，其中IPC作为端侧，将数据汇总到边缘计算的节点中，各个计算节点再将数据汇总提交到是云端。
上面这个图是最符合传统标准"云边端"架构的设计方案，而且每个层的功能划分也是符合常规的"云边端"划分。这里除了架构，我们还应该注意到这个图中的"边缘层"，这个边缘层中标注了两个点：“云边同步”和“”操作系统+容器“，因吹斯汀，这里就引出了另外一个概念：边缘计算平台。
我们这里先将还边缘计算平台的概念放一下，先介绍一下”云边端“的另外一种”变体“模式：”云网边端“。”云网边端“和”云边端“其实本质是都是同一种架构模式，只是一种架构在运用过程中，对于细节的关注点延伸。回顾一下”云边端“架构中的数据传输链路部分。在标准的架构模型中，端侧和边侧一般会直接采用通讯线直连的方式，因为这里一般讲究的就是稳定性；而边侧到云端的这个数据通讯链路中，可以选择的通讯方式就有很多种。例如：城市主干光纤线路、4G/5G通讯线路、卫星通讯线路等等。”云网边端“架构中强调出现的网，就是指边侧到云端这部分的数据通讯链路。为什么会特意强调一下”网“这个通讯链路，就目前多个实施项目来说，个人认为可能是通讯链路的技术方案的强调或是架构成本的强调。
所谓的通讯链路技术方案的强调就是说在边侧到云端通讯的过程中，其使用的通讯链路技术有其特殊性，例如使用4G/5G等通讯链路。现在看来4G/5G的通讯链路方式不值得特别将“网”这个提出来进行说明，但是在前几年5G风行的时候，全国从上到下都在强调5G的高可靠性、低延迟性和高带宽特点，因此无论是建设方案也好，宣传发文也好，不带5G通讯的内容，就和现在没有AI的信息系统一样，有人会怀疑这个方案有什么建设意义。所以在原本“云边端”架构中，特意提及“网”这个通讯链路，从整个架构模式中就已经说明在通讯方式中采用了特别的链路，而这个链路就可以转换为设计方案或是宣传发文中的：”本项目中，我们使用5G专网融合通讯模式，实现了低延迟、秒切换的系统特性，使得系统的故障切换能力提高到毫秒级别；构建起“5G+工业互联网”的工业项目设计，推动XXXX的数字化转型“。就这一段话，这个项目整体的高度是不是噌的一下就被拔高了不止一个等级。例如：随着马斯克星链建设的成功，国内也开始积极推进商业航天、低位通讯卫星，我观察到国内今年有推出物联网卫星通讯方案，针对于基站覆盖不足，信号差的地方，作为一种补充通讯方案。所以如果我公司以后接了这种物联网数据采集项目，我也会积极在方案中强调自己使用“云网边端”的设计方案，然后在设计方案、宣发文章中写：“针对于xx地区基站覆盖不足，无通讯能力的问题，本项目采用目前国内先进的物联网卫星通讯方案，攻克边端设备和卫星通信设备的适配难题，整体性的提高了项目的抗毁坏性能力，实现XXXX公司卫星通信项目的首次落地，为后续卫星通信方案提供宝贵的项目经验和技术经验......”。就这段话，怎么也能体现出来一个项目“首创”的荣誉。
架构成本的强调是指在"联网"这件事情上，花了成本。例如我公司的端侧采集设备和边缘计算设备，均有RJ45版本、WiFi版本和4G/5G版本，以应对于多种项目现场。这三种设备的成本由低到高分别是：RJ45版本 < WiFi版本 << 4G/5G版本，其中RJ45的网线版本和WIFI版本设备价格相差100块钱左右，但是WiFi版本和 4G/5G版本版本价格相差在300左右。这个设备价格差异，最终肯定是需要在报价中体现，因此如果采用 4G/5G版本的设备，我们在建设方案中一般也会特意指出来使用了“”云网边端“的架构，然后将"网"这部分在方案中特意进行阐明：”鉴于XX项目现场网络架设问题，我们采用云网边端的技术架构，公司边缘计算设备通过4G/5G通讯能力，实现网络通讯的稳定性........“。这种也算是让客户对技术方案买单的一种体现。 这里额外讲了这么多，下一节我们就回到上一节中最后的那个概念：边缘计算平台。
上一章节说的"云边端"架构划分大家应该很清楚了，那让我们来思考一个几个问题：
大家可以仔细阅读里面描述的技术方案，看看是不是能拆解出这里面边缘集群系统的技术实现路线。
这里额外在提一句，这种边缘计算平台的架构中可以看出，云平台可以通过边缘计算平台实现容器编排、自动化部署、扩展和管理容器化应用，因此在部分方案或是设计理念中，也同步提出来一个“云管边”的概念，这里就不再详细解释这个概念，只要大家理解了边缘计算平台，其实也就可以对这种概念的设计模式也会有清晰的认识。前面已经介绍了“云边端”技术架构，并且详细介绍边缘计算平台的技术路线。那我们再来看一个“云边端”架构图：
这个是辅助驾驶车联网的架构图。我们来看这个架构很明显是一个很边缘计算终端的方案，我们再来看一张图：
这是模块化自动驾驶的示意图，依据上面的无人驾驶车联网示意图，你应该能看出来这部分就是边缘计算终端的功能，也就是智能汽车的模块功能。我前段时间注意到特斯拉汽车使用的是“端对端”的无人驾驶方案，然后详细了解了一下什么是“端对端”的技术方案。我这里将两种方案分别列出来：
简单来说，模块式智驾就是一个流水线，主要有感知、预测、规划、控制四个流程。首先，感知部分的任务就是把车辆的雷达、摄像头等传感器的数据进行处理，然后分析车辆周围物体的具体位置、道路轨迹，以及辨别它们到底是行人、自行车、轿车、还是卡车等。紧接着，感知模块就会把以上的信息传给预测模块，预测模块会根据以上的信息分析周边交通参与者下一步的运动状态，比如周围的车辆接下来是要转弯、直行、还是停车等。通过进一步分析后，预测模块会提供一条或者多条本车接下来可参考的行驶路径以及车速。随后预测模块又把本车的道路行驶方案发给规划模块，规划模块会根据车辆自身状态、导航等信息来决定车辆接下来该具体怎么做。等到规划模块确认好行驶路径和速度后，就将命令传递给控制模块，最后再由控制模块去计算和操作车辆的方向盘、刹车以及油门。一个看似简单的智驾功能，就是通过以上步骤实现的。
通过以上介绍不难看出，模块式智驾把简单的驾驶行为分解为多个步骤，而且每一步的逻辑都严丝合缝。在车企和供应商看来，模块式智驾本身是个非常好的方案，因为不同的团队可以负责相应的模块，发挥分工合作的优势，从而把智驾从概念迅速变为装车量产状态。 其次，模块式智驾有一套职能和责任都非常清晰的系统框架，因此当智驾系统在使用中发现BUG的时候，车企和供应商都能立即找到BUG的具体原因，并通过OTA迅速修复。比如车辆在高速行驶时出现了误刹车，那么通过数据分析，车企就可以知道故障是因为感知模块的数据有误，还是预测、规划模块给出了错误的判断。
虽然模块式智驾便于量产和修复BUG，但是要想让它能像人一样控制车辆，就需要学习诸多的交通规则和驾驶经验，而这一切都要靠工程师们事先去定义规则，也就是把交通规则和人的驾驶经验变成一行行软件代码。 但是光靠工程师写代码就能把现实中所有的驾驶场景都覆盖吗？当然是不可能的！关于这个问题，业内就有一个经典的案例，如果你在两侧停满车的狭窄道路驾驶车辆，此时道路一侧突然飘来一个气球，那么一般的逻辑会认为，道路一侧可能会有小孩蹿出来，所以此时车辆应该立即刹车。但同样的场景放在高速上，如果智驾系统仍旧采取立即刹车的方式控制车辆，那很可能演变为一场追尾事故。换言之，工程师如果没有针对这类驾驶场景事先定义好规则，比如高速检测到气球后系统不刹车，那么智驾系统遇到类似场景就会产生安全风险。按照小鹏汽车的说法，一个比较稳定的量产智驾系统，大约有10万条规则。而如果智驾系统要接近人一样的水平，大约需要人工编写10亿条规则。对于软件工程开发来说，这几乎是一件不可能完成的事情。正因如此，我们可以看到传统智驾系统在日常使用中或多或少会出现各种错误，以至于驾驶者不得不进行干预。
基于以上原因，专注于自动驾驶的车企一直在想办法解决传统智驾需要预设规则的问题，于是便有了端到端。所谓的端到端，其实就是将传统的感知-预测-规划-控制这些子模块全部神经网络化，也就是用先进的算法模型取代了传统的算法和人工编写的规则。 因此在工作流程上，端到端与传统的模块式有着较大的不同。传统模块式的工作顺序是感知-预测-规划-控制依次进行的，而端到端的顺序是传感器数据（雷达、摄像头）-神经网络-驾驶参数（方向盘、油门、刹车），也就是说，传统的感知、预测、规划、以及控制模块的工作全部由神经网络完成。端到端中的核心技术就是神经网络，当神经网络应用到汽车上之后，就意味着人们可以不断地训练智驾系统，从而使它学习适应更复杂的驾驶环境。 因此在功能层面，端到端最大的变化就是系统具有自主学习的能力，这是传统模块式智驾不具备的功能。如此一来，在处理各种意想不到的真实驾驶场景时，端到端可以通过神经网络计算得出合适的规则，而不需要人工事先编写好规则，这也就为智驾应对现实中无穷无尽的驾驶场景提供了解决方案。
神经网络对于人们来说是个“黑盒”，当智驾系统出现明显的逻辑错误时，在模块式系统上车企可以非常迅速找到问题出在哪个模块，然后人工编写一个新的规则。但在端到端系统上，车企并不知道复杂的神经网络中哪一个参数或者结构存在问题。 正因如此，基于神经网络打造的端到端智驾系统，有时候它能在很复杂的场景中给出合理的规则，但有时又会犯十分低级的错误，比如分不清红绿灯，于是有人就把端到端形容为：“上限很高，下限很低”。 (上面关于传统传统智驾和端对端智驾的描述来源于百度百家号) 我这里特意来说无人驾驶的方案，肯定还是和本文一直说的“云边端”架构相关。如果无人驾驶全部采用端对端智驾模式，神经网络的能力至关重要，而众所周知，神经网络是需要算力支撑，那么要实现这种方案有两选择：
"云边端"架构作为目前物联网、工业领域很重要的一个设计模型和设计方式被反复提及和使用，但是我们一样要清楚这种模式带来的复杂性和挑战，例如：添加的边缘侧导致云端失去了对于端侧的直接掌控，因此端侧的掌控完全依赖于边缘侧的能力，这样边缘侧架构设计难度提升；同时因为引入边缘侧设备，也导致云端的架构设计复杂度成倍提高（一个架构节点的加入，对于整体架构影响并非只是增加一个节点）。所以目前还有相当数量的部分厂商依然采用的是“端侧”到“云端”直连直控的方案，这也算是一种架构设计和投入成本直接的平衡，并没有什么对错之分。 我曾在《数字化的表现形式》一文中提出，“每一个方案能被市场所大范围接受，必然有着它的生存空间，我们所要做的就是分析方案本身最基本的表达内容，将其最有效的一面结合业务展示出来”。同样，每个还技术方案的出现都有着其深刻的发展背景和演变过程，我们观察和了解是它的演变过程，可以掌控它的优势和缺点，在方案设计过程中做出最合适的选择。 下一篇我们将回到企业数字化的内容，欢迎大家持续关注。
