深入理解边缘计算框架EdgeX Foundry(四):为什么不能用平均主义方式设计边缘计算软件?

之前介绍过EdgeX边缘计算微服务框架简介边缘计算框架的需求,我们已经了解了边缘计算遇到的五大问题并且如何解决这五大问题的。在本文中,我们来看一下为什么不能用平均主义方式设计边缘计算软件
作者:与子同袍
首发:物联网前沿技术观察

一个故事

二十世纪四十年代,美国空军非战损的飞行事故频繁发生。一天之内最多摔了17架飞机。

起初空军认为问题出在飞行员身上。因为坠机事故报告上最常见的原因是“飞行员误操作”。

这个分析看上去很合理,因为飞机并没有发生故障。工程师找不到飞机的设计缺陷。

但是事故也不是飞行员技术问题导致的。调查人员在飞行员身上找不到原因,就把注意力转向驾驶舱设计上。

他们发现,美国空军曾于1926年统计了几百名男性飞行员的身体尺寸的平均值。

在随后的30年中,座椅的形状和大小、座椅到操纵杆距离、挡风玻璃的高度、头盔形状,都是根据1926年那次统计的飞行员的平均值设计的。

美国空军开始怀疑会不会是飞行员营养好长高了。于是俄亥俄州Wright空军基地的航空医学实验室,在1950年奉命测量了4063名飞行员的140个身体部位尺寸,然后统计每个部位的平均值。

空军打算根据这次统计的平均值重新设计新的驾驶舱。

但是航空医学实验室一位23岁的哈佛毕业的工程师Gilbert Daniels中尉却觉得这样做有问题。

Gilbert Daniels中尉瘦长体型戴眼镜。他喜欢花卉和风景,在高中的时候是植物俱乐部主席。他本科毕业后加入了Wright空军基地的航空医学实验室时,从来还没有坐过飞机。但是这并不重要。作为一名初级研究员,他的工作是拿卷尺测量飞行员的肢体长度。

他不是第一次测量人体尺寸。航空医学实验室录用他是因为他专业是人类体格学。

在20世纪上半叶,这个专业专注于根据人体尺寸平均值对个体进行分类。

他的本科论文是对比250名哈佛学生的手。这些学生都来自白人中上阶层,但是出乎意料的是,他们的手尺寸根本不相似。 更令人吃惊的是,当Daniels把所有学生的手尺寸平均后,平均尺寸的手型和任何一个个体的测量值不同。根本就没有平均尺寸的手。

Daniels说:当我离开哈佛时,我已经很清楚如果要给人设计一样东西,平均值根本没用。

所以当空军叫他测量飞行员身体尺寸时,他就问了一个问题,到底有多少飞行员符合平均尺寸?

他决定找出答案。他根据4063名飞行员的测量数据,计算了10个对于飞行驾驶舱最重要的尺寸的平均值,包括身高、胸围、手臂长度等。

他把尺寸落在平均值±30%以内的定义为平均尺寸。例如,飞行员平均身高为5.9英尺,他把平均飞行员的身高范围定义为5英尺7英寸到6英尺11英寸。

然后,他把每个飞行员的尺寸和他定义的平均飞行员的10个身体部位的范围进行检查。

结果让所有人大吃一惊。4063名飞行员,没有一名飞行员的10个尺寸全部落在平均飞行员的范围内。

一个飞行员可能胸围大臀围小。另一个可能手臂长但腿短。

更吃惊的是,Daniels发现,要是只选3个身体尺寸来看,如颈维、臀围、腰围,看有多少飞行员在这三个尺寸的平均值范围内,结果只有3.5%的飞行员满足。

Daniels的数据证明了根本没有平均飞行员。要是根据飞行员的平均值设计驾驶舱,那么就不会适合任何一位飞行员。

他得出了结论:要设计好一样东西,必须要让系统适应个体,而不是根据个体的平均值来设计系统

美国空军看了Daniels中尉的报告后恍然大悟,将设计原则从之前的平均主义改为适应个体。美国空军要求飞机制造商设计的驾驶舱要能调整,从而适应5%~95%的飞行员尺寸范围。

飞机制造商听到这个强制要求时,第一反应是认为这样成本太高需要几年时间。

但是航空工程师很快就给出了低成本又容易安装的设计。他们将座椅、脚踏板、操作杆、头盔固定带和飞行服都设计为可调整的。

边缘计算情况

上述是驾驶舱设计的故事。如果是边缘计算,情况又如何呢?

对于边缘计算来说,系统就是边缘计算网关,个体就是边缘计算软件的用户。现在的目标是,该如何设计这个系统,从而适应不同行业的不同企业的需求。

一种很明显的思路就是先找一些客户做市场调研,然后根据反馈的客户需求,整理出一个能满足大部分客户需求的功能列表,然后让开发团队进行设计和开发。

Todo:加zero的tod之类的设计流程。

这样做可以,但是在给不同客户实施的时候会遇到许多问题。

为什么?

假设边缘计算软件有如下10项功能:

  1. 数据采集、协议解析,比如根据Modbus RTU或OPC协议标准采集工控设备的实时数据
  2. 数据上传到云端:把采集的设备实时数据根据指定的格式(如XML或JSON或自定义二进制)和通讯协议(如MQTT/HTTP/WebSocket等)发送到指定的云端服务器;
  3. 数据分析:在上传到云端之前,对采集到的设备数据进行处理和分析;
  4. 远程控制:接收云端下发的命令,并根据命令执行相应的动作,如修改PLC中某地址的值。
  5. 元数据定义:定义网关对应的设备的型号、序列号、采集的数据项定义等信息。设备注册上线离线:定义设备如何注册到云端。
  6. 数据告警:配置数据满足条件后的告警。
  7. 实时数据库、历史数据库
  8. 规则和触发的动作
  9. 远程配置下发及远程软件升级
  10. 系统管理和配置

如果边缘计算软件公司有500个工控行业客户,每个客户对这10个功能都会有点自己的想法和要求。

会出现如下的尴尬情况:

客户A:网关要能够采集西门子S7-1200、S7-1500型号的PLC的数据。
销售:目前还不支持。
客户B:我要把网关采集的数据发送到我们的服务器。
销售:不好意思,目前只能发送到我们自己的云服务。
客户C:网关要能够远程下发我们指定格式的配置文件。
销售:格式不好改。
客户D:网关要按照我们XX设备的条件检测和故障诊断算法对采集的数据在网关内进行分析处理。
销售:不行。我们网关只支持巴拉巴拉…这几种算法。

为什么会这样?

其实这就是平均值谬误在作怪。

同样道理,边缘计算软件公司如果按照“标准飞行员”的思路来设计软件,就会设想出一个“标准工控客户”,然后设计出边缘计算软件。

结果会和老板预想的完全不同,这个软件不会满足95%的客户的需求,而是500个客户都会觉得不好用。

那边缘计算软件到底应该怎么样设计才能适应不同的业务需求,并且跟上技术发展趋势呢?

我们将在下一篇盘点边缘计算软件的主要的几种架构设计思路。

往期精彩:

  • 深入理解边缘计算框架EdgeX Foundry(三):EdgeX如何应对5大需求问题?
  • 深入理解边缘计算微服务框架EdgeX Foundry(二):边缘计算框架有哪些需求?
  • 深入理解边缘计算微服务框架EdgeX Foundry(一):EdgeX边缘计算微服务框架简介

更多物联网,边缘计算相关技术干货请关注我的专栏物联网前沿技术观察