欢迎阅读关于工业控制系统 (ICS) 网络安全的多部分系列的第一部分：ICS 安全简介。 在第一篇博文中，我们将向您介绍这些系统是什么，解释它们为何如此重要，并概述保护 ICS 的独特挑战。

什么是工业控制系统？

工业控制系统用于管理、指导和调节自动化工业过程的行为。 ICS 是一个涵盖多种控制系统的术语，但所有这些系统都有一些共同的基本特征。他们的工作是产生期望的结果，通常是维持目标状态或在工业环境中执行特定任务。他们使用传感器执行此功能以收集真实世界的信息。然后，他们将这些数据与所需的设定点进行比较，并计算和执行命令功能，以通过最终控制元件（例如控制阀）控制过程，以维持所需的状态或完成任务。

从恒温器到 SCADA

虽然远非复杂，但恒温器是大多数人都熟悉的简单控制系统的一个例子。它监控封闭空间内的温度，并打开加热或冷却装置以保持所需的温度。

另一方面是大规模、复杂的环境，需要多个不同的系统协同工作，以实现工业设备功能的自动化。广泛使用的 Purdue 参考架构模型将 ICS 划分为多个级别，我们将在本系列的后续博客文章中更详细地介绍这些级别。暂时，我们将ICS的组件总结如下：

• 传感器和执行器——操纵它们所连接的机械组件（例如阀门、开关、继电器）的设备以及向控制器报告现场数据的传感器。这是连接网络环境与物理世界的关键点。
• 控制器——从传感器接收输入并根据其编程调整执行器的设备。
• 本地监督系统——使操作员能够监督、监控和控制物理过程的系统。这些界面可能使用 Windows 等商品操作系统，但通常是更简单的设备，如触摸屏。
• 管理系统——工业控制网络顶层的服务器和工作站。作为所有 ICS 控制和监控的端点以及业务系统的连接点，这些系统对整个 ICS 环境具有广泛的可见性，通常跨越多个地理区域。
• 业务系统——企业级服务，使用 ICS 运营数据和遥测技术进行业务应用程序，如计费、建模、趋势和报告。这些系统不被视为工业控制网络的一部分。

为什么要关心 ICS？

工业控制系统基本上无处不在。您喝的水、告诉您何时停止和离开的交通信号灯以及为您用来阅读本博客的设备供电的电力都来自如果没有 ICS 启用的自动化流程就无法运行的服务。这些系统也是国家安全问题。美国国土安全部列出了 16 个关键基础设施部门，其资产和功能被认为对国家经济安全和公共卫生或安全至关重要，列出的每个部门都严重依赖 ICS：

• 化工
• 商业设施
• 通讯
• 关键制造
• 大坝
• 国防工业基地
• 紧急服务
• 能源
• 金融服务
• 食品和农业
• 政府设施
• 医疗保健和公共卫生
• 信息技术
• 核反应堆、材料和废物
• 交通系统
• 水和废水系统

在这些关键基础设施领域的每一个中，不同的工业控制系统都在不断地调节流量、打开和关闭断路器、监控温度水平以及执行许多其他功能。例如，疫苗生产目前是全球的主要优先事项，该过程中使用的 ICS 的批次控制功能对于制药公司的大规模生产工作至关重要。这些部门中任何一个部门的 ICS 中断都可能产生重大后果。在一线员工必须处理爆炸性或有毒物质的工作场所，系统故障可能导致严重伤害或死亡。

很容易理解为什么工业控制系统是组织良好的威胁参与者进行网络攻击的最高价值目标之一。这些团体的目标可能从盗窃知识产权到敌对民族国家故意造成损害，但 ICS 系统对任何工业化国家日常运作的重要性使它们成为任何希望造成最大损失的团体的理想目标以相对较低的资源成本实现中断水平。

对主要公用事业公司的攻击可能会严重影响大量人口，例如 2015 年对乌克兰三个能源分销公司的网络攻击，该公司在冬天的中心暂时切断了超过 200,000 名客户的电力超过三个小时。自 2016 年以来，还公开披露了三起对供水系统的攻击，对客户的健康构成直接风险。仅在 2015 年，美国水和废水行业就发生了 25 起网络安全事件，随后发生了这些攻击。

使问题更加复杂的是公用事业的有限预算，尤其是那些由较小城市运营的公用事业。农村公用事业公司经常缺乏雇用一名 IT 人员的预算，这使他们无法应对大多数类型的网络威胁。

ICS 网络安全的挑战

工业控制系统的一些关键特性使得它们在本质上比 IT 环境更具挑战性。一方面，这些是必须实时精确运行的确定性设备，安全层可能会阻碍它们的性能。如果 ICS 设备必须以 1/60 秒的精确间隔测量电流，它们就无法容忍后台运行的安全软件产生的潜在延迟。其次，ICS 的某些组件基本上一直在运行，它们的持续运行可能是组织驱动力不可或缺的一部分（例如，推动利润或维护健康与安全）。必须精心计划因对这些系统进行更改或安装更新而导致的任何停机时间，以确保将服务中断降至最低水平。

虽然它们可以处理复杂的工业应用，但工业控制系统具有内在的简单性：它们控制着它们设计的过程，仅此而已。随着时间的推移，这些系统有了很大的改进，但它们的发展路径与 IT 不同，它们的安全功能并没有像安全从业者所希望的那样受到关注。

继承的不安全感：ICS 沿袭

第一个工业控制系统是针对它们所经营的不同部门的要求而定制的。例如，工厂车间自动化的早期阶段依靠工业继电器、气动柱塞定时器和电磁计数器的机架来启动和停止电机。根本没有终端或网络连接，编程更改由车间的电气工程师进行，通过物理更改电路来更改程序。这些系统本质上是预定义的、不灵活的和停滞的，实施任何更改或对其进行维护都非常困难。

1975 年，随着第一款可编程逻辑控制器 (PLC) Modicon 184 的发布，实现了重大飞跃。该设备可以从运行供应商编程软件的个人计算机通过专有媒体和协议进行编程。用于对第一代 PLC 进行编程的主要通信协议是 Modbus（通过串行接口），于 1979 年推出。Modbus 现在是开源的，事实证明它非常可靠且易于使用，直到今天仍在使用，开发人员已将其调整为在 TCP/IP 网络上工作。不幸的是，这带来了一个重大的安全问题，因为 Modbus 请求和响应数据包是在未加密且未经身份验证的情况下发送的，并且使用已建立的方法很容易拦截、修改和重放它们。虽然现代 ICS 中目前使用了其他几种协议，但它们中的许多都有类似的漏洞。

然而，ICS 设备中固有的安全缺陷超出了通信协议。从安全的角度来看，那些被证明最易于使用和最耐用的设备自相矛盾地是最容易出现问题的设备之一，因为它们的使用寿命极长，因此它们缺乏实现所需的硬件、马力或编程安全功能。

由于 ICS 的实际应用种类繁多，还有大量不同的、通常是专有的系统构成了当今的 ICS 环境。大多数 IT 组织使用 Windows 等知名操作系统，因此很容易找到经验丰富的管理员。 ICS 中使用的系统、协议和编程方法更加多样化，这是供应商坚持各自产品线的专有技术的结果。因此，每个 ICS 环境通常都是独一无二的，并且可能具有由具有不同优先级和专业技能的操作员运行的多个不同系统。

总之，重要的是要注意 ICS 从业者历来重视可靠性和互操作性。这是因为工业控制系统通常需要连续使用，在多供应商环境中提供长期使用寿命的关键功能。因此，当许多这些环境首次投入使用时，安全实践并不普遍，并且安全功能和实践近年来才开始集成到 ICS 系统中。

新的开口，新的威胁载体

随着世界各地的组织将更多的 ICS 功能暴露给他们的企业网络和云以提高业务和运营效率，他们在不知不觉中为他们的工业控制系统开辟了新的潜在攻击媒介。恶意行为者经常成功地访问公司网络，并且在许多记录在案的案例中，获得了对 ICS 环境的访问权，并造成了从微不足道到危及生命的各种破坏。

想要的：新员工，新想法

 

虽然这里提到的问题很重要，但它们与其他社会经济因素的融合，包括石油和天然气行业的收缩，为考虑职业转变的个人提供了机会。那些在工业环境中具有 ICS 工作经验的人拥有成为 ICS 安全从业者的坚实基础。在 2021 年 SANS ICS 峰会的主题演讲中，美国国家安全委员会负责网络和新兴技术的国家安全副顾问 Anne Neuberger 表达了让具有这种背景的人参与进来的重要性：

“在我上一份工作中，我的团队中有几个人来自公用事业部门，他们非常有价值，并且参与了每一次讨论，因为人们一直在说‘这很有用。’”

除了 ICS 中使用的不同工具集之外，专家们也有不同的思维方式，它们承担着不同的使命、文化和对 ICS 环境独特风险的理解。那些拥有 ICS 实践经验的人会带来丰富的知识，这些知识可以帮助开发出确保我们的工业基础设施安全所需的知情方法。

愿意将其专业知识应用于 ICS 领域的 IT 安全分析师也可以极大地帮助改善 ICS 网络安全状况。虽然 ICS 供应商开始将更多的安全性纳入他们的产品和技术，但掌握 IT 安全最佳实践的人对于现在保护 ICS 环境至关重要。例如，所有 ICS 协议最终都将得到强化和保护，就像 FTP 和 TELNET 在 IT 领域逐渐被 SFTP 和 SSH 取代一样。然而，在这些类型的改进出现之前，可以采用经过验证的 IT 安全实践来保护 ICS：网络分段与强大的外围保护以及强大的监控、检测和响应相结合。

在本系列的下一部分中，我们将进一步深入研究 ICS 网络安全的当前状态，检查最佳实践和架构标准，同时回顾从最近对 ICS 基础设施的攻击中吸取的宝贵经验。

原文：https://www.sans.org/blog/introduction-to-ics-security/

本文：https://jiagoushi.pro/node/1794

安全 ICS 架构的 Purdue 模型和最佳实践

在本系列的第一部分中，我们回顾了工业控制系统 (ICS) 的独特沿袭，并介绍了保护 ICS 的一些挑战。 在第二部分中，我们将向读者介绍普渡企业参考架构 (PERA)、其他专用于 ICS 网络安全的参考模型和出版物，以及保护这些至关重要的系统的架构和管理最佳实践。

回顾：ICS 网络安全的挑战

在我们对 ICS 的“固有不安全”性质的概述中，我们确定了保护这些系统的挑战，因为它们具有高可用性要求和缺乏固有的安全功能。在运营商和安全从业人员在运营技术 (OT) 环境中应对这些挑战之前，信息技术 (IT) 管理员面临着类似的挑战。第一代 IT 网络的管理员首先在外围解决了安全挑战，实施了第一批防火墙设备，将其受信任的局域网与不受信任的广域网（以及后来的 Internet）隔离开来。

保护 ICS 要求我们做同样的事情：创建一个可防御的环境。然而，在这种情况下，组织的 IT/业务网络组件对 ICS/OT 代表相同的不受信任区域，就像 Internet 对 IT 网络代表一样。再一次，分割是必需的，但沿着什么方向？普渡企业参考架构有助于回答这个问题。

普渡企业参考架构简介

Purdue 模型创建于 1990 年代初期，旨在为工业控制系统和业务网络之间的关系定义最佳实践（或使用可互换的术语，在 OT 和 IT 之间）。在它的第一次迭代中，有三个组件：

• 普渡企业参考架构
• 普渡参考模型
• 普渡实施程序手册

随着时间的推移，该模型逐渐发展为包括物理系统架构指南，并引入了环境的六个网络级别，描述了驻留在每个级别的系统和技术：

PURDUE级别	描述	例子
第 5 级：企业网络	支持单个业务部门和用户的企业级服务。 这些系统通常位于企业数据中心。	服务器提供： 企业活动目录 (AD) 内部电子邮件 客户关系管理 (CRM) 系统 人力资源 (HR) 系统 文件管理系统 备份解决方案 企业安全运营中心 (SOC)
第 4 级：业务网络	本地站点业务用户的 IT 网络。 连接到企业广域网 (WAN) 和可能的本地 Internet 访问。 直接 Internet 访问不应低于此级别。	商务工作站 本地文件和打印服务器 本地电话系统 企业 AD 副本
IT/OT BOUNDARY (DMZ)
3级： 全站监督	对站点或区域的监控、监督和运营支持。	管理服务器 人机界面 (HMI) 报警服务器 分析系统 历史（如果适用于整个站点或区域）
2级：地方监督	对单个过程、单元、生产线或分布式控制系统 (DCS) 解决方案进行监控和监督控制。 将流程彼此隔离，按功能、类型或风险分组。	人机界面 报警服务器 过程分析系统 历史学家 控制室（如果范围为单个过程而不是站点/区域）
级别 1：本地控制器	提供过程、单元、生产线或 DCS 解决方案的自动化控制的设备和系统。 现代 ICS 解决方案通常结合 1 级和 0 级。	可编程逻辑控制器 (PLC) 控制处理器 可编程继电器 远程终端单元 (RTU) 特定过程的微控制器
0 级：现场设备	用于电池、生产线、过程或 DCS 解决方案的传感器和执行器。 通常与 1 级结合使用。	基本传感器和执行器 使用现场总线协议的智能传感器/执行器 智能电子设备 (IED) 工业物联网 (IIoT) 设备 通信网关 其他现场仪表

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

一般来说，当您向下移动层次结构（从第 5 级到第 0 级）时，设备对关键流程的访问权限会增加，但内在的安全功能会减少。因此，较低级别的设备更依赖于网络和架构防御，以及位于较高级别的设备来保护它们。

在这一点上，重要的是要注意 PERA 从未打算成为网络安全参考模型。它旨在描述管理工业部门网络的企业和工业部门之间分割的最佳实践。尽管如此，它作为 IT/OT 安全中的概念框架仍然很流行，因为它显示了可以在哪里添加安全措施。

PERA 的一个关键方面是 0-3 级表示的 ICS/OT 系统与 4 级和 5 级企业网络的 IT 系统之间的边界点。从历史上看，管理员保护 ICS 系统的方式是最小化，甚至消除，两个环境之间的任何互连。随后，对于两者之间不存在互连的架构，OT 和 IT 之间的边界通常被称为“气隙”。随着对来自 OT 方面的更多数据的需求增加，管理员不得不通过防火墙连接这两个级别，这些防火墙仔细控制对非军事区 (DMZ) 的访问。防火墙调解 IT 和 OT 之间的所有通信，目的是消除两个环境之间的直接通信。

辩论普渡在 ICS 网络安全中的作用

网络安全界流行的一句话是：“所有模型都是错误的，但有些是有用的。”这当然适用于普渡模型，在考虑自 1990 年代以来技术如何发展时，该模型无疑具有局限性，从而促使业务目标和风险承受能力也发生变化。正如本系列的第一部分所讨论的，技术进步和成本效率促使组织从其 ICS 系统（位于 PERA 的 0-3 级）中提取更多数据。例如，远程连接到 ICS 可以降低操作员的劳动力成本和响应时间。此外，来自 ICS 的信息支持趋势、优化和计费等关键业务功能，有助于提高效率，同时增加 ICS 遭受攻击的风险。

一些批评者认为，PERA 将控制系统网络设想为与其他一切分离，并且对实时 OT 数据的需求增加以及基于云的系统和服务的结合消除了完全封闭系统的概念僵化的等级制度。在 2019 年 S4 会议上，Joel Langill 和 Brad Hegrat 就该主题进行了精彩讨论，可在此处查看。讨论的主题是“普渡模式是否已死”，赫格拉特先生认为普渡模式本质上已经死了，因为“融合杀死了它1”。在辩论的另一边，Langill 先生承认，虽然“从网络的角度来看，架构可能已经死了”，但该模型是最先展示“这些部分应该如何分层和互操作”的模型之一，并且“如果我们忽略了这一点，我们就会忽略我们最初创建等级制度的原因2。” Langill 认为，虽然该模型从未被视为安全参考架构，但它仍然包含一些风险理念，可帮助安全从业人员了解信息如何在组织上流动，从而有助于识别和解决潜在的攻击向量。

虽然 IT 和 OT 之间（层次结构的第 3 级和第 4 级之间）假定的“气隙”很少适用于当今的架构，但工业环境的核心组件并没有改变；它们仍然包括带有连接到控制器的传感器和执行器的设备，这些控制器将其数据传递到组织中的系统链上。此外，虽然云技术的出现可能会在地理上模糊界限，但普渡模型总是按功能对网络进行分段，这仍然可以应用于具有大量云集成的 OT/IT 环境。

争论的双方都提出了正确的观点，但 SANS 研究所的共识是 PERA 仍然是一个有用的概念框架，因为它是第一个根据明确定义的分类法对控制系统组件进行分类的框架之一。即使其层次结构不再能够统一应用于现代架构，将 ICS 和 IT 设备和系统分类为不同的功能层也有助于管理员和安全从业人员确定在何处有效地应用安全措施。

SANS ICS410 参考模型

SANS 扩展了 Purdue 模型和我们将在下一节讨论的一些 ICS 网络安全框架，为 ICS410 创建了 ICS410 参考模型：ICS/SCADA 安全要素。 ICS410 模型是一种公开可用的基础参考架构，它为 Purdue 模型添加了明确的执行边界，有助于将 ICS 设备和网络安全控制置于安全的网络架构中。

ICS410 Reference Model

一般来说，ICS410 参考模型具有以下优点：

• 以模板方式引入多个单元（cells）/行（lines）/流程（processes ）的概念，并在多个站点进行扩展。
  • 这有助于将 Purdue 模型扩展到不同的 ICS 应用，从大型站点（例如工厂、矿山、制造）到区域/分布式网络（例如电力、石油/天然气、水）。
• 包括包含广域网 (WAN) 通信的控件
• 包括安全系统

ICS 参考模型还通过以下方式提供了有关网段之间实施边界的更多详细信息：

• 细分一些 Purdue 级别（例如，第 3 级分为管理服务器、HMI、工程工作站、测试/分级系统、网络安全操作、远程访问等子部分）
• 定义多个 DMZ 并要求 IT 和 OT 之间的所有连接都终止于 DMZ（即，推一个方向，拉另一个方向）。
  • Purdue 模型不包括 DMZ，尽管它们在实践中很常用。
• 在 2 级和 3 级之间引入次要执法边界，以保护：
  • 不同单元/生产线/工艺中的 2 级设备。
  • 来自恶意行为者的 2 级及以下设备，该恶意行为者已通过上层控制并进入 OT 环境。
  • 来自恶意行为者的 3 级系统利用较低级别的物理访问。
• 明确执行边界，这会创建可以应用额外安全控制的自然阻塞点。

最后，ICS410 参考模型为保护远程访问这一关键功能提供了明确的指导。

与其他框架和参考模型一样，ICS410 参考模型将需要更新以适应增加云连接和 ICS 网络中其他 IIoT 设备所需的新设备和通信路径。

审查 ICS 网络安全标准

如果说 PERA 通过有效的分类和分类为 ICS 网络安全奠定了基础，那么一系列其他框架和出版物已经建立在该基础之上，并提供了专门针对保护工业控制系统的指导。示例包括：

• NIST 网络安全框架 (CSF)
• NIST 800-82（工业控制系统安全指南）
• ISA 99.02.01/IEC 62443：工业自动化和控制系统的安全
• NIST Cybersecurity Framework (CSF)
• NIST 800-82 (Guide to Industrial Control Systems Security)
• ISA 99.02.01/IEC 62443: Security for Industrial Automation and Control Systems

连同行业特定指导：

• 北美电力可靠性公司的关键基础设施保护 (NERC CIP)
• 运输安全管理局 (TSA) 管道安全指南
• 网络安全和基础设施安全局 (CISA) 关键基础设施部门指南
• North American Electric Reliability Corporation's Critical Infrastructure Protection (NERC CIP)
• Transport Security Administration (TSA) Pipeline Security Guidelines
• Cybersecurity & Infrastructure Security Agency (CISA) Critical Infrastructure Sectors Guidance

NIST CSF 由美国国家标准与技术研究院 (NIST) 发布，是美国政府大部分关键基础设施保护指南的核心。这在 NIST CSF 的正式标题中得到了证明：“改善关键基础设施网络安全的框架”。同样，TSA 为管道运营商使用与 CSF3 一致的类别提供指导。

Purdue 模型对这些指南和出版物的影响很明显，它们都促进了工业网络环境中系统的有效分段和隔离，并要求在它们之间的边界进行安全控制。例如，NIST 800-82 将这一概念阐明如下：

在为 ICS 部署设计网络架构时，通常建议将 ICS 网络与公司网络分开。 这两个网络上的网络流量性质不同：Internet 访问、FTP、电子邮件和远程访问通常在公司网络上被允许，但在 ICS 网络上不应该被允许。 公司网络上可能没有针对网络设备、配置和软件变更的严格变更控制程序。 如果 ICS 网络流量在公司网络上传输，则可能会被拦截或遭受 DoS 攻击。 通过拥有独立的网络，企业网络上的安全和性能问题应该不会影响 ICS 网络4。

这里引用的标准都共享许多核心概念，包括：

• 资产管理和分类，包括关键资产的定义及其在框架中的角色。
• 建立和维护包括风险评估和管理在内的安全计划。
• 安全网络和系统架构原则，强调隔离。
• 事件响应。
• 身份、访问管理、身份验证和授权。
• 数据和信息保护。
• 安全配置、漏洞管理和修补。
• 安全事件监控。
• 控制的实际应用。

在最后一节中，我们将扩展其中一些概念，并研究如何将这些指导原则转化为具体的管理任务。

应用原则：现代 ICS 网络安全架构的最佳实践

正如我们在本系列的第 1 部分中所讨论的，保护 ICS 网络可能很困难，原因有很多，包括需要连续和确定性的操作、多供应商环境中的互操作性、设备的种类和使用年限以及它们缺乏内在的安全性能力。由于这些限制，保护 ICS 环境的最佳机会是拥有强大的架构防御，从网络层开始，并在上述标准和框架提供的指导中突出显示。

强大的网络架构可提高 ICS 安全性，并为随着时间的推移可以实施额外的安全措施奠定基础。 Purdue 模型、NIST SP800-82、IEC 62443 和 SANS ICS410 参考模型都非常强调网络分段和分段之间的通信控制。

正如边界防火墙被普遍部署以保护企业环境免受基于 Internet 的攻击一样，ICS 环境应该在其许多实施边界上提供保护。尽管工业流程在普渡模型中处于较低级别，但最敏感的数据和控制点通常位于第 3 级，这也是大多数攻击者首先从业务网络访问 ICS 网络的地方。

从根本上说，ICS 系统应该使用完全独立于业务网络的专用基础设施。通过有效的分段，3 级和 4 级之间的防火墙可以控制进出 ICS 网络的网络通信。此防火墙应阻止进出 ICS 网络的所有通信，并明确允许仅最低要求的通信。

攻击也可能来自远程站点，尤其是在分布广泛的环境中。出于这个原因，应在 2 级和 3 级之间配置辅助执行边界，以保护管理系统免受来自现场的攻击，并保护各个现场站点免受彼此的攻击。这些强制边界通常使用路由器访问列表来实现，以避免关键进程通信通过可能阻碍合法通信的防火墙。

Recommended enforcement boundaries for sensitive data at Level 3

ICS 网络的完整功能需要许多不同类型的系统，包括操作员工作站、HMI、工程工作站、管理服务器、数据库服务器、历史记录器、警报服务器和许多其他专用系统。每个系统都有一个明确定义的角色，并且需要对其他系统进行特定的网络访问。因此，每个级别应进一步细分为多个网络，其中具有共同角色的系统可以驻留，并具有控制它们与网络其余部分通信的执行边界。

应创建多个 DMZ，每个都有专门的用途，以促进 ICS 网络和业务网络之间的通信。远程访问、云访问和 Internet 访问也可以通过专用 DMZ 进行调解。 DMZ 的实现和配置将在以后的博客文章中更详细地探讨。

执行边界不仅控制不同类别​​系统之间的通信，而且还充当自然网络“阻塞点”，可以监控和保存网络流量以供以后分析。防火墙生成的日志，结合从网络捕获的原始数据包，是丰富的信息来源。由于 ICS 网络是相对静态的，因此可以创建“正常”通信的基线，然后用于检测异常和威胁。

完整网络架构的详细分解超出了本博客的范围，但是有几个重要的最佳实践可供遵循：

• 4 级以下不应访问 Internet。
• 操作人员可能有一台单独的专用商务计算机，用于访问电子邮件、互联网和打印等服务。
• 可以实施 Active Directory (AD) 来帮助管理控制网络，但任何此类 AD 部署都应完全独立于业务 AD。域控制器和其他 AD 服务器应放置在第 3 级。
• 应采用如 ICS410 参考模型中所示的强制边界。
• 默认情况下，防火墙应阻止所有通信，只允许所需的通信。
• 所有对 ICS 网络的访问都应该需要额外的身份验证层，包括多因素身份验证。
• 应提供一种安全机制，以便在检查恶意软件时将文件传入和传出 ICS 网络。
• ICS 系统应该有专门的基础设施，例如不依赖于业务网络的防病毒和补丁系统。
• 应监控和记录所有进出控制网络的通信。

随着越来越多的供应商利用基于云的管理系统，从业者需要发展他们的 ICS 架构。必须与云通信的设备应放置在单独的专用区域中，将其网络访问限制为仅对其基于云的控制器和它们必须与之通信的本地系统进行访问。

此处提供的指南仅介绍了 ICS 网络安全最佳实践的一小部分。除了架构标准之外，安全从业人员还需要考虑一些控制措施，随着新功能需求和新技术不断进入等式，ICS 网络安全领域将不断发展。尽管如此，久负盛名的普渡模型经受住了时间的考验，提供了有关风险的想法和通用词汇，这些知识为当今许多受到关注的出版物和模型提供了信息。

随着我们关于 ICS 网络安全系列的继续，我们将深入研究具体的安全措施，包括在执法边界实施和配置非军事区的最佳实践。

专业术语

客户关系管理 (CRM)	CRM 系统是一个中央存储库，企业可以在其中存储客户和潜在客户数据、跟踪客户交互并与同事共享此信息。 它允许企业管理与客户的关系，从而帮助企业发展。
安全运营中心 (SOC)	一个专用的集中式站点，用于监控、评估和保护企业信息系统（网站、应用程序、数据库、数据中心和服务器、网络、桌面和其他端点）。
人机界面 (HMI)	人机界面 (HMI) 是特定设备或软件应用程序的功能或组件，它使人类能够与机器互动和互动。 在 ICS 中，HMI 通常是将用户连接到机器、系统或设备的屏幕或触摸屏。
可编程逻辑控制器 (PLC)	一种固态控制系统，具有用户可编程存储器，用于存储指令，以实现特定功能，例如 I/O 控制、逻辑、定时、计数、三模式 (PID) 控制、通信、算术和数据和 文件处理。
远程终端单元 (RTU)	远程终端单元 (RTU) 通常部署在工业环境中，是一种多用途设备，用于远程监视和控制各种设备和系统以实现自动化。 它的用途与可编程逻辑电路 (PLC) 相似，但程度更高。 RTU 被认为是独立的计算机，因为它共享相同的核心组件：处理器、内存和存储。 随后，它可以用作其他设备的智能控制器或主控制器，共同实现工业过程的自动化。
智能电子设备（IED）	工业控制系统随处可见，例如监控和数据采集 (SCADA) 或分布式控制系统 (DCS)，IED 是添加到 ICS 以实现高级电力自动化的设备。 IED 是许多工业过程中使用的功率调节的一部分，例如控制断路器、电容器组开关和电压调节器。 这些设置由设置文件控制。 文件的创建和测试是 IED 涉及的最大任务的一部分。
工业物联网 (IIoT)	传感器、仪器、机器和其他设备联网在一起并使用互联网连接来增强工业和制造业务流程和应用程序。

原文：https://www.sans.org/blog/introduction-to-ics-security-part-2/

本文：https://jiagoushi.pro/node/1795

远程访问最佳实践

远程访问连接对 ICS 的重要性

在互联网出现之前，大多数组织的 ICS/OT 环境是“隔离的”，这意味着它没有与外部网络的连接。因此，网络安全措施并不是 ICS 的主要考虑因素。然而，正如本系列的第一部分所讨论的，必须克服这种思维方式在互联网时代的持续存在，因为 ICS 环境现在更加互联并依赖于实时操作数据。随后，它们已成为威胁团体的高价值目标。

与 ICS 进行远程访问连接的好处是如此显着，以至于许多组织现在在日常运营中依赖这些类型的连接。例如，当一个组织需要检查、重新编程或更新其 ICS 时，将供应商技术人员从另一个地点派往现场远不如让技术人员远程连接到设备以立即执行工作而无需旅行费用。对于位于远程现场站点的 ICS 的持续管理，远程访问也更可取，因为它使一名技术人员能够管理多个站点，从而最大限度地提高他/她的效率。

因此，与 ICS 的远程连接将继续存在。不幸的是，它们是近年来几次成功的、备受瞩目的网络攻击的关键因素，包括 2014 年的蜻蜓攻击、2015 年的乌克兰电网攻击和 2021 年的奥兹马尔事件。

但是，对于远程连接到 ICS，可以遵循一些最佳实践，这些实践可以大大降低攻击成功的可能性，并确保在获得关键操作技术的访问权限之前发现并阻止威胁参与者。

普渡企业参考架构中的远程访问

澄清一下，我们所指的远程连接是从 Internet 和/或组织的业务网络到其 OT 环境的连接。这些连接提供了对位于 Purdue Enterprise Reference Architecture 的第 3 级及以下的设备的访问，我们在本系列的第二部分中对此进行了深入介绍：

PURDUE级别	描述	例子
第 5 级：企业网络	支持单个业务部门和用户的企业级服务。 这些系统通常位于企业数据中心。	服务器提供： 企业活动目录 (AD) 内部电子邮件 客户关系管理 (CRM) 系统 人力资源 (HR) 系统 文件管理系统 备份解决方案 企业安全运营中心 (SOC)
第 4 级：业务网络	本地站点业务用户的 IT 网络。 连接到企业广域网 (WAN) 和可能的本地 Internet 访问。 直接 Internet 访问不应低于此级别。	商务工作站 本地文件和打印服务器 本地电话系统 企业 AD 副本
IT/OT BOUNDARY (DMZ)
3级： 全站监督	对站点或区域的监控、监督和运营支持。	管理服务器 人机界面 (HMI) 报警服务器 分析系统 历史（如果适用于整个站点或区域）
2级：地方监督	对单个过程、单元、生产线或分布式控制系统 (DCS) 解决方案进行监控和监督控制。 将流程彼此隔离，按功能、类型或风险分组。	人机界面 报警服务器 过程分析系统 历史学家 控制室（如果范围为单个过程而不是站点/区域）
级别 1：本地控制器	提供过程、单元、生产线或 DCS 解决方案的自动化控制的设备和系统。 现代 ICS 解决方案通常结合 1 级和 0 级。	可编程逻辑控制器 (PLC) 控制处理器 可编程继电器 远程终端单元 (RTU) 特定过程的微控制器
0 级：现场设备	用于电池、生产线、过程或 DCS 解决方案的传感器和执行器。 通常与 1 级结合使用。	基本传感器和执行器 使用现场总线协议的智能传感器/执行器 智能电子设备 (IED) 工业物联网 (IIoT) 设备 通信网关 其他现场仪表

 

 

 

 

理想情况下，到 ICS 的远程连接应该通过 IT 和 OT 段之间的非军事区 (DMZ)，在本系列的这个版本中，我们将仔细研究安全远程访问架构。 防火墙、身份验证服务、跳转服务器和文件服务器都在安全地进行这些连接方面发挥着至关重要的作用。

在根据最佳实践构建的环境中，我们建议由位于 3 级和 4 级交界处的服务器组成的多个 DMZ，每个专用于特定目的。 DMZ 服务包括托管远程访问连接、管理云连接、作为进入 OT 的 IT 网关，以及作为从 OT 进入 IT 环境的网关。 这些服务器协同工作以适应远程用户可能需要的每个功能，同时执行对 OT 环境的最低权限访问策略。

Multiple DMZs are recommended to control communication into and out of the OT network

通过 DMZ 与 ICS 进行远程访问连接的最佳实践

在可能的情况下，技术人员的远程连接应通过将 IT 环境（即业务网络）连接到 OT 环境的 DMZ 集中起来。 这为管理员和安全从业人员提供了最大的可见性、最佳的活动跟踪和记录，以及对远程访问 OT 环境的所有用户的身份验证和访问控制。

OT 员工的远程连接应该需要两个单独的步骤：与 ICS DMZ 建立 VPN 连接，然后通过跳转主机（或跳转服务器）使用强化远程桌面 (RD) 进行第二次连接，该主机提供仔细控制、基于角色的访问 OT 系统。

Components of secure remote access for ICS networks

以下部分介绍了通过 DMZ 将连接配置到 ICS/OT 环境的各种单独组件。

认证（Authentication）

首先，管理员应确保需要远程访问的每个人都使用命名帐户进行连接；任何共享帐户都不应用于此目的。远程访问用户只应被授予对启用他们必须执行的任务的系统的访问权限，仅此而已。

远程 OT 用户应使用专用远程访问帐户（理想情况下，这些不是 OT 域帐户）通过多因素身份验证 (MFA) 对 VPN 服务器进行身份验证。一旦连接到 VPN，应该只允许远程用户连接到跳转主机或安全文件传输机制。连接到这些服务时，远程用户将进行第二次身份验证，这次使用的是 OT 域凭据。在这两个阶段，管理员都应该记录和监控登录活动，在多次失败的身份验证尝试后锁定帐户，并终止会话持续不活动。

Secure authentication to control networks

在 DMZ 的 OT/ICS 端（通常位于 Purdue 模型的第 3 级）拥有一个 Active Directory (AD) 域是此授权序列的关键组成部分。此域应专用于 ICS，不得以任何方式连接到公司 Active Directory。它通常放置在具有强制边界的专用 3 级子网中，以控制进出 AD 的通信。在此 Purdue 级别部署 AD 服务器具有许多优势，包括：

• 管理和执行 ICS 中所有 Windows 资产的安全策略
• 作为身份验证的中央来源，因此不必在每个单独的设备上管理本地帐户
• 管理角色（使用 AD 组）以促进对用户活动的精确控制
• 集中创建、修改和删除帐户
• 集中记录所有 Windows 活动，包括身份验证
• 跳转服务器认证和权限设置

虽然在 OT 网络中使用 AD 无疑会通过扩大攻击面来增加风险，但它所支持的额外安全功能使得这种权衡是值得的。为了降低这种风险，Active Directory 应由对 Active Directory 有深入了解的训练有素的员工管理。不要害怕利用组织 IT 管理员的 AD 知识和经验。

跳转主机

对于下一步，应授予技术人员使用基于角色的访问权限访问跳转主机的权限。管理员可以使用 OT 域组强制执行此措施，这些域组仅授予对远程用户执行工作所需的系统和应用程序的访问权限。

跳转主机在超越身份验证的安全远程连接中发挥着重要作用。执行边界应限制与跳转主机之间的通信。每个角色的跳转主机应该只能与该角色管理的设备进行通信。这些服务器还应禁止用户在其工作站上运行任何软件或从其传输任何数据（例如，应在本地安全策略中禁用驱动器和剪贴板重定向）。相反，远程连接所需的所有软件和数据都应预先安装在跳转主机本身上。

Jump host communications for secure remote access

对于必须随身携带数据的一小部分，管理员应该创建安全的方法来扫描和清理传入和传出 OT 网络所需的数据。文件传输部分对此进行了更详细的讨论。

文件传输

ICS 系统的远程管理，无论是来自业务网络还是 Internet，通常都需要将文件传入和传出 OT 环境。文件传输到 OT 的示例包括软件更新和补丁、防病毒更新、配置更改、项目文件和其他文档。来自 OT 环境的数据可能包括日志和诊断信息或系统备份。下单和确认等交易数据经常以两种方式传输。

通过远程连接保护文件传输的方法在概念上类似于技术人员在亲自访问 ICS 环境时需要使用 USB 驱动器传输文件时使用的“浸羊”方法。这种方法要求技术人员首先将 USB 驱动器插入该位置的服务器，扫描 USB 驱动器上的所有文件并将“清理”的文件复制到插入服务器的另一个 USB 驱动器。然后，技术人员取出“清洁过的”USB 驱动器并使用它将文件传输到特定的 ICS 系统。

要通过远程连接执行相同的任务，管理员应在 DMZ 中设置文件服务器，配置一个只写文件夹和一个只读文件夹，并配备一个或多个防病毒扫描工具。远程用户将文件上传到服务器使用防病毒实用程序扫描它们的只写文件夹，然后将文件复制到位于 3 级的单独服务器上的只读文件夹。然后远程用户可以使用“清理” 文件中的只读文件夹并在 OT 网络中使用它们。使用相同的过程将文件移出 OT 环境。理想情况下，管理员应为每组远程用户设置多组写入和读取文件夹，并根据在 OT 域内管理的角色分配权限。

最终，管理员的目标是避免直接远程访问 OT 环境，确保对所有传输的文件进行恶意软件扫描，并使用文件夹权限防止文件服务器成为单个开放存储库。

直接连接最佳实践

绕过通过 DMZ 的路径并从 Internet 直接连接到 ICS 的远程访问会带来更大的风险，SANS 研究所强烈建议管理员尽可能禁止这些类型的连接。然而，这并不总是可能的。例如，第三方承包商可能在他们自己的系统上运行极其昂贵的客户端软件，用于对现场控制器进行编程。在这些情况下，购买另一个许可证来安装在客户端的跳转服务器上是不可行的，而是需要直接连接到 OT 环境。虽然这种做法风险更大，因此考虑到这些承包商系统可能连接到许多不同组织的网络，因此不明智，但管理员可以采取一些步骤，在没有其他选择的情况下尽可能确保直接连接的安全。

首先，从管理的角度来看，组织应创建需要管理层批准的流程，以提供对 OT 网络的直接远程访问。考虑到被访问设备的操作重要性，管理层应该了解每个授权的远程连接。

从管理的角度来看，仍应要求这些远程用户连接到 VPN 并如上所述进行身份验证，所有通信都通过远程访问 DMZ。与第三方签订的合同应要求他们对其设备采取合理的安全预防措施。措施包括使用专门用于此目的的设备（即从未用于访问 Internet）、限制谁可以登录以及可以执行哪些程序，以及运行反恶意软件。连接到 VPN 后，应为设备分配一个静态 IP 地址，以便 DMZ 防火墙可以将其访问限制为仅访问设备执行特定任务所需的主机和端口。

在可能的情况下，应添加额外的控制以确保 VPN 登录（无论是访问跳转服务器还是直接连接）只有在登录源自受信任的 IP 地址时才会成功。例如，可以维护属于授权供应商和员工的 IP 地址列表以及组织拥有的地址，以进一步限制访问。

防止未经授权的远程访问

前面的部分讨论了在 ICS 中构建安全远程访问连接，但不幸的是，这些措施有时会被用户和承包商绕过。在这些情况下没有恶意； ICS 供应商希望（有时需要）24/7 全天候访问他们的设备以进行监控，因此他们的人员可能会建立未经授权的连接以启用该访问。内部员工技术人员也可能出于不同原因设置未经授权的连接，例如利用通用 Internet 热点。在典型的场景中，现场技术人员可能需要在冬季中期解决控制室中的 OT 服务器问题（或提前知道他/她需要在凌晨 2 点进行更改）。在这些情况下，技术人员可能会将热点连接到该服务器，以便他/她可以在床边进行所需的更改并保持温暖，而不是在寒冷中跋涉穿过营地到服务器机房。

不管它们的起源如何，这些连接的意外后果是它们为恶意行为者可以利用的组织的安全措施提供了捷径。为防止这种情况发生，管理员应与供应商确认他们没有设置任何未经授权的连接，并且今后也不会这样做。在现场时，管理员应注意以下类型的未经授权的连接：

• 蜂窝调制解调器/热点（设备），
• 拨号调制解调器，
• 未经授权的 ISP 连接，
• 通过以太网、无线、MPLS 或 VPN 直接连接到供应商网络。

为了解决用户或供应商对安全协议的不耐烦，管理员必须在有效的安全性和易用性之间取得平衡。如果供应商人员需要自己的 ICS 远程访问连接，请确保他们真正获得授权，并实施适当的访问控制，遵守最小权限和零信任原则，以便这些用户只能执行他们要求的任务。如果可能，默认禁用这些连接并仅在需要时手动启用它们。与供应商合作，找出他们的要求并构建一个合适的解决方案，其中包括适当的安全控制。如果供应商需要专用连接进行监控，请确保它通过远程访问 DMZ 运行，并且仅限于网络的单个网段，如果可能的话，通过跳转服务器。

最终，这项任务归结为对员工和供应商进行教育，并制定明确的政策供他们遵循。然而，即使有明确的政策和沟通，也无法替代目视检查。四处寻找未经授权的连接——站点越远，越有可能存在未经授权的远程连接。

结论

无可否认，在 DMZ 进行远程连接的首选方法比技术人员习惯的方法涉及更多的身份验证步骤，因此执行所有这些步骤可能会遇到 OT 员工缺乏热情的情况。常规的改变很少容易，但远程用户必须购买额外的安全措施。

获得利益相关者认可的一种方法是通过类比。为了工作场所的安全，工业环境中的工作人员定期参加安全会议并穿戴个人防护设备。将这些措施与安全远程访问连接所需的步骤联系起来有助于让远程用户相信它们的重要性。此外，要求远程用户在三天内完全采用他们的新习惯，然后重新评估他们的情况可能会非常有效。这个间隔可能看起来很短，但我们发现它足以让远程用户熟悉新的例程。

关于 ICS 远程访问连接的最后一些指导：

应用最新补丁 - 远程访问系统可从 Internet 访问，必须始终可用，并用于为外部各方提供对受保护网络的访问，使其成为非常有吸引力的目标。使用最新补丁使它们保持最新状态可以减少您对已知漏洞的暴露。

教育员工——为需要远程访问的用户提供有针对性的培训，并确保传达始终遵循所需步骤的重要性。

此外，关键基础设施安全局 (CISA) 为“配置和管理工业控制系统的远程访问”[1] 提供了指导。尽管它于 2010 年发布，但该指南在今天仍然非常重要。 CISA 推荐的关键最佳实践是：

• 进行正式的威胁和风险评估
• 消除与关键运营资产的所有直接连接
• 超出默认方式的安全调制解调器访问
• 使用 DMZ 隔离业务和控制架构
• 建立用户特定的认证服务器
• 为所有远程访问创建安全保证策略
• 仅使用完整的隧道加密技术
• 使用特定于远程访问元素的密码策略
• 尽可能使用多因素身份验证
• 使用基于角色的授权级别
• 使用专用硬件和软件来支持远程访问解决方案。

ICS 的远程访问连接将继续存在，因为它们为组织提供了一长串好处。对于管理员而言，遵循保护远程连接的最佳实践所需的步骤可能看起来同样长，但重要的是要记住，任何组织都不能承受这些连接被恶意行为者利用的代价。遵循最佳实践是一条很好的路线，但它仍然是有效 ICS 网络安全的关键组成部分。

在本系列的第四部分中，我们将研究跨 IT/OT 边界的安全通信。企业比以往任何时候都更有理由允许跨此边界传输数据，但保持边界安全同样重要。

Sources

• [1] https://us-cert.cisa.gov/sites/default/files/recommended_practices/RP_Managing_Remote_Access_S508NC.pdf

About Stephen Mathezer

• Check out Stephen's bio, ICS contributions, and see his upcoming ICS410 course teaches here.

原文：https://www.sans.org/blog/introduction-to-ics-security-part-3/

本文:https://jiagoushi.pro/node/1796

降落飞机

我认识一家生产工厂的首席执行官，我们就叫他比尔吧，他希望他的关键团队成员真正了解他的运营团队每天为实现生产目标而承受的压力。比尔还希望他的经理和支持人员能够理解“让它发生”和“看着它发生”之间的区别。换句话说，他希望他的团队能够认识到认为自己有技能和知道自己有技能之间的区别，并坚定地理解如果只有“教育知识”而不是“知识结合起来”会有不同的结果有经验。”

比尔做了什么来灌输这一课？他为他的 10 名主要员工购买了一小时的飞行课程。

什么？飞行课？为什么？

首先，正如比尔解释的那样，如果没有背景或先前的经验，指导某人完成一项任务并不容易。如果你期待一个成功的结果，你需要重新设定你的期望，有目的地让他们接触相关的经验，并在他们完成现实世界的场景时指导他们。飞行就是一个很好的例子。看起来很简单，教练有一个精确的飞行控制副本，并坐在学生旁边告诉他或她该做什么。但是，在学生有足够的技能和经验来纠正自己的错误并最终降落飞机之前，教练最终会接管飞行控制并确保他们不会遇到麻烦。

所以比尔基本上用一小时的飞行场景来灌输一个教训，即如果学生缺乏经验，即使是经验丰富的飞行教练也无法指导学生完成降落飞机等复杂场景。从学生的角度来看，他们可能认为他们对飞行控制有足够的了解，他们甚至可能已经练习过连接到计算机模拟的控制轭。但他们很快就会发现，要成功降落飞机，知识必须与相关经验相结合，而且很多情况下不能模拟经验。相关经验是……嗯，相关的。

那么，如何获得相关经验呢？

为了回答这个问题，让我们谈谈什么是“相关”体验。我们必须首先看看工厂或工厂是如何建造和组织的，以创造一种盈利的产品。工厂或工厂由原始设备制造商 (OEM) 设备的集合组成，这些设备经过设计和整合以生产产品或控制最终成为消费品的过程。我们可以使用从生产牙膏到精炼汽油的任何例子。现代世界的这些奇迹确实是令人着迷的艺术作品，每一个都有自己的权利。在过去三年的职业生涯中，我一直对事物的制造方式充满好奇。

直到最近，我们才以网络安全进入我们词汇的方式将机器连接在一起。多年来，控制规则并未发生根本性变化，但连接性的变化迫使我们将网络安全技能添加到我们的工具包中。

在大多数情况下，原始设备制造商已经创建了自己的专业类型的机械或设计了基于在创建特定产品或控制特定过程方面拥有专业知识或经验的解决方案。例如，一个 OEM 可能完全了解如何填充牙膏管或将液体放入瓶中，而另一个 OEM 可能具有加热和混合所有成分以制造牙膏的专业知识。但是每个 OEM 都缺乏做对方做的事情的专业知识或经验。我们还必须了解，虽然 OEM 知道自己的机械设计，但最终客户将获得不同类型的体验，包括学习如何操作、维护和排除设备故障。 OEM 必须在设计设备时考虑到客户的不同但同样重要的观点，同时培养自己团队的技能，以尽可能高效地执行其特定任务。例如，OEM 的培训方案可能会教授诸如如何编码或如何确定控制阀尺寸等技能。另一方面，如果最终用户学习如何调整和调整机器或解决电气问题，他们的培训可能更有意义。

为什么这个故事很重要？它回到了获得相关经验将导致成功的前提。例如，我曾为多家机械 OEM 工作，我在这方面的相关经验是了解如何设计控制系统来控制某些过程。我需要获得的经验是了解控制阀如何响应物理阀的尺寸和响应。这涉及了解控制系统的响应并将正确的控制元件组合在一起，以便操作员可以输入他们想要的设定点，并且物理机械将以可预测和一致的方式响应。

将我的相关经验与操作员的经验进行对比。操作员需要了解如何设置控制设定点的值以及机器如何响应，如何输入和调整这些关键参数，以及如何响应警报条件。例如，如果操作员正在制作烘焙食品，并且要求他们了解甘蔗糖和甜菜糖之间的烹饪和口味差异，他们将需要知道如何调整机械参数，以使产品的味道相同，而无论其类型如何。用的糖。对我来说，作为与 OEM 制造商合作的人，我几乎不知道有不同种类的糖，我当然不知道当你用任何一种甜味剂烘烤时有什么区别。

这些各自的相关经验是不同的，但两者都是取得成功所必需的。我们当然可以理解，并不是所有的经历对每个演员都是平等的或相关的。在 ICS 网络安全培训方面也是如此。与您的培训相关的经验最终取决于您在何种环境中工作以及获得成功所需的技能。

ICS 网络安全深入研究

所以现在让我们谈谈我们希望通过 SANS ICS612：ICS 网络安全深度课程实现的目标和学习经验。所有课程的合著者都认为，我们需要提炼安全从业人员在生产或运营环境中会发现的系统类型，并让学生接触动手实验室，为他们提供操作、维护、监控、故障排除的相关经验，响应、恢复和保护工业领域的共同元素。例如，如果有人问我在我遇到的 90% 的工厂或工厂中发现了哪些共同元素，我会将这些共同元素分类如下：

• 实时嵌入式控制系统，如可编程逻辑控制器 (PLC)，可控制某些机器或过程
• 数字和模拟输入/输出子系统
• 基于协议的“智能”传感器和阀门（例如，Ethernet/IP、Highway Addressable Remote Transducer [HART]、DeviceNet、Profibus DP、Profibus PA 等）
• 过程可见性元素，例如电子操作员界面 (EOI)、人机界面 (HMI)，有时还有监控和数据采集 (SCADA) 系统
• 过程数据存储，如 Historian 或本地过程趋势数据库
• 网络设备可以是传统的基于以太网的协议和一些实时控制标准，如以太网/IP、Modbus、Profibus 等。
• 安全控制，例如防火墙、监控系统等。

上面的列表是对常见元素的高级分类，虽然不详细，但有助于确定可能需要的培训的主要领域。在您的培训中应考虑这些类别，因为您很可能会在工业环境中遇到这些类型的技术。

当我们开发 ICS612 时，我们决定每个学生都必须通过参与动手实验来获得经验。我们认为这将为学生提供相关经验，并使他们在课程结束时能够自信地发现问题并恢复工厂运营。当然，如果我们希望我们的学生恢复工厂运营，我们需要创建一个工厂。因此，我们创建了一个环境，让学生使用 PLC、网络 I/O、EOI、HMI 服务器、Historian 服务器和其他支持元素（如远程连接技术和工作工业非军事区）构建一个工作咖啡工厂。这使我们能够与学生一起研究每个元素，并最终在一个真正代表由复杂系统组成的系统的“系统系统”模型中。

了解如何对常见工业资产进行编程和操作是 ICS612 的基本必要组成部分，但我们认为如果不通过资产攻击实验室工作，这门课程将是不完整的。在工业生产环境中发现的每项资产都有不同的漏洞，了解如何构建和保护这些关键资产至关重要。动手攻击实验室经过精心设计，可以展示这些资产的优势和劣势。我们认为，工业网络安全课程的正确组合需要学习如何让资产在正常运行条件下工作，通过实验室练习保护资产，并通过攻击实验室发现漏洞。了解如何防守和进攻不仅有趣，而且非常重要。

正如我之前提到的，课程在第五天达到高潮，其中的场景涉及一家倒闭的咖啡厂。每个学生都应该让他或她的工厂部分启动并运行。随着咖啡工厂的一部分得到修复，我们鼓励学生互相帮助，让工厂的一部分得到修复。众所周知，网络安全是一项团队运动（这使得在虚拟环境中的培训更加困难）。一旦我们真正解决了故障模式，真正的故障排除就开始了。学生很快就会明白，在真实设备上工作与模拟环境有很大不同。当电机无法启动、保险丝熔断并且您闻到烟味时，或者由于继电器触点不工作而导致灯指示不正确时，您从解决问题中获得的冒险和信心会建立在计算机模拟之外.我们第五天的学生与第一天的学生有很大不同。他们获得了相关的 ICS 网络安全经验，可以立即在他们的工作环境中使用。我们的目标是提供培训，使从业者能够在现实世界中立即使用他们的 ICS612 课堂培训。 ICS612 校友的反馈始终与我们的目标相呼应，即他们的培训是相关的，让他们在工业运营环境中感到更加自信和有效。

那么比尔的 10 名工作人员的一小时飞行体验是怎么出来的呢？他说，参与者的经历将永远改变他们认为自己知道某事而不是真正知道自己知道某事的观点。问问自己，如果你必须将你的模拟飞行技能放在一架真正的飞机上，你对降落飞机有多大信心？

这一切都表明，知识和正确的经验是任何事情成功的关键。作为旁注，比尔实验的 10 名参与者中的一名后来成为了飞行员、飞机所有者，甚至拥有了自己的跑道！

哦，是的，顺便说一句，我也是一名私人飞行员。

在我的下一篇博客中，我将深入探讨 ICS612 的学习目标：深入 ICS 网络安全，更具体地说，为什么我们选择用“破碎”的咖啡工厂来挑战我们的学生，以加强我们在期间磨练的所有技能我们上课的前四天。

原文：https://www.sans.org/blog/a-look-into-ics612-ics-cybersecurity-in-depth…

本文：

SCADA能用于那里？

SCADA（监控和数据采集）是一个以现代行业为核心的工业自动化控制系统，包括：

• 能源
• 食品与饮品
• 制造业
• 油和气
• 功率
• 回收
• 运输
• 水和废水

还有很多

SCADA系统由私营公司和公共部门服务提供商使用。 SCADA在许多不同类型的企业中工作良好，因为它们可以从简单的配置到大型，复杂的项目。

无论您在当今世界看到的任何地方，还有一些类型的SCADA系统在幕后运行，无论是在当地的超市，炼油厂，废水处理厂，甚至是您自己的家。

SCADA系统如何工作？

SCADA系统部署多个软件和硬件元素，允许工业组织：

监控，收集和处理数据

通过HMI（人机界面）软件相互连接并控制诸如阀门，泵，电机等的机器和设备

将事件记录到日志文件中

在基本的SCADA体系结构中，传感器或手动输入的信息发送到PLC（可编程逻辑控制器）或RTU（远程终端单元），然后将其发送到具有SCADA软件的计算机。 SCADA软件分析和显示数据，以帮助运营商和其他工作人员减少浪费并提高制造过程的效率。

有效的SCADA系统可以大大节省时间和金钱。 已经出版了许多案例研究，强调了使用现代SCADA软件解决方案（如点火）的好处和节省。

Basic SCADA Architecture

SCADA的演变

在五十年代，第一台微型计算机首次开发用于工业用途。 20世纪60年代，曾经将小型电脑当成中等尺寸，被用于远程监控和监控。

“SCADA”一词是在20世纪70年代初创造的，而在这十年期间微处理器和可编程逻辑控制器（PLC）的兴起使得企业能够比以往任何时候都更有能力监控和控制自动化流程。

在20世纪80年代和90年代，SCADA再次发展，广泛使用局域网（LAN），使SCADA系统能够连接到其他系统，并引入基于PC的HMI软件。

在20世纪90年代和21世纪初期，结构化查询语言（SQL）数据库成为IT数据库的标准，但SCADA开发人员没有采用。 这导致了控制和IT领域的分歧，随着时间的推移，SCADA技术变得陈旧。

现代SCADA系统

现代SCADA系统允许从世界任何地方访问车间的实时数据。访问实时信息可以让政府，企业和个人对如何改进流程进行数据驱动的决策。没有SCADA软件，如果不是不可能收集足够的数据来进行持续的知情决策将是非常困难的。

此外，大多数现代SCADA设计器应用程序具有快速的应用程序开发（RAD）功能，允许用户相对容易地设计应用程序，即使他们没有丰富的软件开发知识。

将现代IT标准和实践（如SQL和基于Web的应用程序）引入SCADA软件大大提高了SCADA系统的效率，安全性，生产力和可靠性。

利用SQL数据库的功能的SCADA软件比旧的SCADA软件提供了巨大的优势。使用SQL数据库与SCADA系统的一个重要优点是，它可以更轻松地集成到现有的MES和ERP系统中，从而使数据能够通过整个组织无缝流动。

来自SCADA系统的历史数据也可以记录在SQL数据库中，这样可以通过数据趋势更轻松地进行数据分析。

点火HMI / SCADA软件

InductiveAutomation®的点火是一种工业自动化软件平台，许多企业和组织都针对其HMI / SCADA需求进行了切换。

自2010年以来，点火已经安装在70多个国家的数千个地点。其强大而强大的性能使SCADA系统集成商能够满足客户的需求，而成本低于其他SCADA软件解决方案。

以下是更多企业选择点火的几个原因：

点火使用现代IT实践，使其与当前的SCADA系统组件兼容。

其独特的授权模式可让用户根据服务器数量支付固定费用。其他SCADA供应商通常为每个客户端或每个标签收费，但Ignition提供无限的客户端和标签。

点火是Web部署的：它可以在几分钟内下载和安装，客户端可以立即启动或更新。

感性自动化的“梦想，做到”的座右铭。是Ignition可以做的完美的体现。虽然它的大胆的声明可能听起来太好，不能成为真实的，但是这个软件的一个演示证明了它真正有多强大。一旦看到可能的话，您将开始想象软件如何适应SCADA需求，并开辟新的可能性。

监控和数据采集（SCADA）是一种使用计算机，网络数据通信和图形用户界面进行高级过程监控管理的控制系统架构，但使用其他外围设备（如可编程逻辑控制器和离散PID控制器）来连接加工厂或机械。通过SCADA监控计算机系统处理能够监视和发出过程命令（如控制器设定值变化）的操作员界面。然而，实时控制逻辑或控制器计算由连接到现场传感器和执行器的网络模块执行。

SCADA概念被开发为远程访问各种本地控制模块的通用手段，这可以来自不同的制造商，允许通过标准自动化协议访问。实际上，大型SCADA系统已经发展成与分布式控制系统功能非常相似，但使用多种与工厂接口的方式。他们可以控制可以包括多个站点的大规模进程，并且可以在很大的距离上工作。[1]它是最常用的工业控制系统之一，但是有人担心SCADA系统容易受到网络战/网络恐怖袭击的攻击。[2]

内容

1控制操作中的SCADA概念

2使用实例

3个SCADA系统组件

3.1监控电脑

3.2远程终端单元

3.3可编程逻辑控制器

3.4通信基础设施

3.5人机界面

4报警处理

5 PLC / RTU编程

6 SCADA与PLC商业整合

7通信基础设施和方法

8 SCADA架构开发

8.1第一代：“单片”

8.2第二代：“分配”

8.3第三代：“联网”

8.4第四代：“物联网”

9安全问题

10另见

11参考文献

12外部链接

控制操作中的SCADA概念

SCADA系统的关键特性是能够通过各种其他专有设备执行监控操作。

附图是使用计算机控制显示功能制造水平的一般模型。

参考该图，

0级包含现场设备，例如流量和温度传感器，以及最终控制元件，如控制阀。

1级包含工业化输入/输出（I / O）模块及其相关的分布式电子处理器。

级别2包含监控计算机，其将来自系统上处理器节点的信息整理并提供操作员控制屏幕。

3级是生产控制水平，不直接控制过程，而是关注监控生产和目标。

4级是生产调度级别。

1级包含可编程逻辑控制器（PLC）或远程终端单元（RTU）。

2级包含SCADA软件和计算平台。 SCADA软件只在本监控级别存在，因为控制动作由RTU或PLC自动执行。 SCADA控制功能通常限于基本覆盖或监督级干预。例如，PLC可以将通过部分工业过程的冷却水的流量控制到设定点水平，但是SCADA系统软件将允许操作员改变流量的设定点。 SCADA还能够显示和记录诸如流失或高温的报警条件。反馈控制回路由RTU或PLC直接控制，但SCADA软件监控回路的整体性能。

3级和4级传统意义上不是严格的过程控制，而是生产控制和调度的地方。

数据采集从RTU或PLC级开始，并包括根据需要传送到2级SCADA的仪表读数和设备状态报告。然后将数据进行编译和格式化，使得使用HMI（人机界面）的控制室操作员可以作出监督决定来调整或覆盖正常的RTU（PLC）控制。数据也可以提供给历史学家，通常建立在商品数据库管理系统上，以允许趋势和其他分析审计。

SCADA系统通常使用标签数据库，其中包含称为标签或点的数据元素，这些数据元素与过程系统中的特定仪器或执行器相关，例如管道和仪表图。针对这些独特的过程控制设备标签引用累积数据。

使用示例

在办公环境中使用的SCADA远程监视进程的示例

可以使用SCADA概念构建大型和小型系统。这些系统的范围可以从几十到几千个进程循环，具体取决于应用程序。示例过程包括工业，基础设施和基于设施的流程，如下所述：

工业过程包括制造，过程控制，发电，制造和精炼，并且可以连续，批量，重复或离散模式运行。

基础设施流程可以是公共的或私有的，包括水处理和分配，废水收集和处理，油气管道，输配电和风力发电场。

设施流程，包括建筑物，机场，船舶和空间站。他们监控和控制供暖，通风和空调系统（HVAC），接入和能源消耗。

然而，SCADA系统可能存在安全漏洞，因此应对系统进行评估，以确定为减轻这些风险而实施的风险和解决方案。[3]

SCADA系统组件

SCADA系统通常由以下主要元素组成：

监控电脑

这是SCADA系统的核心，收集流程数据，并向现场连接的设备发送控制命令。它是指负责与现场连接控制器进行通信的计算机和软件，它们是RTU和PLC，并且包括在操作员工作站上运行的HMI软件。在较小的SCADA系统中，监控计算机可以由单个PC组成，在这种情况下，HMI是该计算机的一部分。在较大的SCADA系统中，主站可能包括托管在客户端计算机上的多个HMI，用于数据采集的多个服务器，分布式软件应用程序和灾难恢复站点。为了提高系统的完整性，多台服务器通常将配置为双冗余或热备用结构，在服务器发生故障或故障时提供持续的控制和监控。

远程终端单元

更多信息：远程终端单元

远程终端单元（也称为（RTU））在此过程中连接到传感器和执行器，并连接到监控计算机系统。 RTU是“智能I / O”，通常具有嵌入式控制功能，如梯形逻辑，以完成布尔逻辑运算。[4]

可编程逻辑控制器

更多信息：可编程逻辑控制器

也称为PLC，这些连接到过程中的传感器和执行器，并以与RTU相同的方式与监控系统联网。 PLC具有比RTU更复杂的嵌入式控制能力，并以一种或多种IEC 61131-3编程语言进行编程。 PLC通常用于替代RTU作为现场设备，因为它们更经济，通用，灵活和可配置。

通信基础设施

这将监控计算机系统连接到远程终端单元（RTU）和PLC，并且可以使用行业标准或制造商专有协议。使用从监控系统给出的最后一个命令，RTU和PLC都可以在近程实时控制过程中自动运行。通信网络的故障不一定会停止工厂过程控制，并且在恢复通信时，操作员可以继续进行监控。一些关键系统将具有双冗余数据高速公路，通常通过不同路线连接。

人机界面

更多信息：图形用户界面

文件：Scada Animation.ogv

更复杂的SCADA动画显示了四台批量炊具的控制

人机界面（HMI）是监控系统的操作员窗口。它以模拟图形式向操作人员呈现工厂信息，模拟图是被控制的工厂的示意图，以及报警和事件记录页面。 HMI连接到SCADA监控计算机，以提供实时数据来驱动模拟图，报警显示和趋势图。在许多安装中，HMI是操作员的图形用户界面，从外部设备收集所有数据，创建报告，执行报警，发送通知等。

模拟图由线图形和原理图符号组成，用于表示过程元素，或由过程设备的数字照片与动画符号重叠组成。

工厂的监督操作是通过HMI，操作员使用鼠标指针，键盘和触摸屏发出命令。例如，泵的符号可以显示操作员泵正在运行，并且流量计符号可以显示通过管道泵送多少流体。操作者可以通过鼠标点击或屏幕触摸将泵从模拟器切换掉。 HMI将显示管道中流体的流量实时下降。

用于SCADA系统的HMI包通常包括一个绘图程序，操作员或系统维护人员用来改变界面中这些点的显示方式。这些表示可以像在屏幕上的交通信号灯一样简单，其表示现场的实际交通信号灯的状态，或者与表示摩天大楼中所有电梯的位置的多投影仪显示器一样复杂火车在铁路上。

“历史学家”是HMI内的软件服务，可在数据库中累积时间戳的数据，事件和警报，数据库可以查询或用于填充HMI中的图形趋势。历史学家是从数据采集服务器请求数据的客户端。[5]

报警处理

大多数SCADA实现的重要部分是报警处理。系统监视是否满足某些报警条件，以确定何时发生报警事件。一旦检测到报警事件，就会采取一个或多个操作（例如激活一个或多个报警指示器，也可能生成电子邮件或短信，以便通知管理或远程SCADA操作员）。在许多情况下，SCADA操作员可能必须确认报警事件;这可能会停用一些报警指示器，而其他指示灯保持有效，直到报警条件清除。

报警条件可以是明确的 - 例如，报警点是具有基于其他模拟和数字点的值的公式计算的值NORMAL或ALARM的数字状态点 - 或者隐含的：SCADA系统可能会自动监视模拟点中的值是否位于与该点相关联的高位和下限值之外。

警报指示器的示例包括警报器，屏幕上的弹出框或屏幕上的彩色或闪烁区域（可能以与汽车中的“燃料箱空”灯类似的方式行事）;在每种情况下，报警指示器的作用是将操作员的注意力集中在系统的“报警”部分，以便采取适当的措施。

PLC / RTU编程

“智能”RTU或标准PLC能够自主执行简单的逻辑过程而不涉及监控计算机。他们采用标准化的控制编程语言，例如IEC 61131-3（包括功能块，梯形图，结构化文本，序列功能图表和指令列表）的5种编程语言的套件，经常用于创建在这些RTU上运行的程序， PLC。与诸如C编程语言或FORTRAN之类的程序语言不同，IEC 61131-3凭借类似于历史的物理控制阵列具有最小的培训要求。这样，SCADA系统工程师就可以执行在RTU或PLC上执行的程序的设计和实现。

可编程自动化控制器（PAC）是一种紧凑型控制器，将基于PC的控制系统的特性和功能与典型PLC的功能相结合。 PAC部署在SCADA系统中，以提供RTU和PLC功能。在许多变电站SCADA应用中，“分布式RTU”使用信息处理器或站台计算机与数字保护继电器，PAC和其他I / O设备进行通信，并与SCADA主机通信以代替传统的RTU。

SCADA和PLC商业集成

自1998年以来，几乎所有主要的PLC制造商都提供了集成的HMI / SCADA系统，其中许多使用开放和非专有通信协议。 许多专门的第三方HMI / SCADA软件包，提供与大多数主要PLC的内置兼容性，也进入市场，允许机械工程师，电气工程师和技术人员自己配置HMI，而无需定制程序 一个软件程序员。 远程终端单元（RTU）连接到物理设备。 通常，RTU将来自设备的电信号转换成数字值，例如开关或阀门的开/关状态，或诸如压力，流量，电压或电流的测量值。 通过将这些电信号转换并发送到设备，RTU可以控制设备，例如打开或关闭开关或阀门，或设置泵的速度。

通信基础设施和方法

SCADA系统传统上使用无线电和直接有线连接的组合，尽管SONET / SDH也经常用于诸如铁路和发电站之类的大型系统。 SCADA系统的远程管理或监控功能通常被称为遥测。一些用户希望SCADA数据通过其预先建立的公司网络传播或与其他应用程序共享网络。尽管早期的低带宽协议的遗留仍然存在。

SCADA协议的设计非常紧凑。许多设计仅在主站轮询RTU时发送信息。典型的传统SCADA协议包括Modbus RTU，RP-570，Profibus和Conitel。除了Modbus（Modbus已经由施耐德电气公司开放，现在由modbus.org管理）之外，这些通信协议都是SCADA供应商特有的，但被广泛采用和使用。标准协议是IEC 60870-5-101或104，IEC 61850和DNP3。这些通信协议被所有主要的SCADA供应商标准化和认可。这些协议中的许多现在包含通过TCP / IP操作的扩展。虽然传统网络规范（如TCP / IP）的使用模糊了传统和工业网络之间的界限，但它们各自的要求完全不同。[6]

随着安全需求的增加（如美国的北美电力可靠性公司（NERC）和关键基础设施保护（CIP）），越来越多的使用卫星通信。这具有基础设施可以自包含（不使用来自公共电话系统的电路）的关键优点，可以具有内置加密，并且可以被设计为SCADA系统运营商所需的可用性和可靠性。早期使用消费级VSAT的经验很差。现代电信级系统提供SCADA所需的服务质量。[7]

RTU和其他自动控制器设备在业界广泛的互操作性标准出现之前被开发出来。结果是开发人员和他们的管理创造了大量的控制协议。在较大的供应商中，也有激励创建自己的协议来“锁定”他们的客户群。自动化协议列表在此汇编。

用于过程控制（OPC）的OLE可以连接不同的硬件和软件，即使在最初不打算成为工业网络一部分的设备之间也可进行通信。

SCADA架构开发

美国陆军培训手册5-601涉及“C4ISR设施的SCADA系统”

SCADA系统通过四代演进如下：[8] [9] [10]

第一代：“单片”

早期的SCADA系统计算是由大型小型计算机完成的。 SCADA开发时常见的网络服务不存在。因此，SCADA系统是不与其他系统连接的独立系统。当时使用的通信协议是严格专有的。第一代SCADA系统冗余是使用连接到所有远程终端单元站点的备用主机系统实现的，并且在主主机系统发生故障的情况下使用[11]一些第一代SCADA系统被开发为运行在数字设备公司制造的PDP-11系列等小型计算机上的“转钥匙”操作。

第二代：“分布式”

SCADA信息和命令处理分布在通过LAN连接的多个站点之间。资料近乎实时分享。每个电台负责一项特殊任务，与第一代SCADA相比，降低了成本。使用的网络协议仍然没有标准化。由于这些协议是专有的，因此开发者以外的人很少知道如何确定SCADA安装的安全性。 SCADA安装的安全性通常被忽视[11]

第三代：“联网”

类似于分布式架构，任何复杂的SCADA都可以简化成最简单的组件，并通过通信协议进行连接。在网络设计的情况下，该系统可以分布在称为过程控制网络（PCN）的多个LAN网络上，并在地理上分开。并行运行的多个分布式架构SCADA与单个主管和历史数据库可以被认为是一种网络架构。这允许在非常大规模的系统中获得更具成本效益的解决方案。

第四代：“物联网”

随着云计算的商业可用性，SCADA系统越来越多地采用物联网技术，大幅降低基础架构成本，增加维护和集成的便利性。因此，SCADA系统现在可以实时地报告状态，并使用云环境中可用的水平尺度来实现比传统可编程逻辑控制器实际可行的更复杂的控制算法。[12] [13]此外，使用诸如物联网技术固有的开放网络协议，比许多分散式SCADA实现典型的专有网络协议的异构混合提供了更易于理解和可管理的安全边界。这种技术的一个这样的例子是通过实施实时控制（RTC）来实现雨水收集的创新方法[需要引用]。

数据的这种分散还需要与传统的基于PLC的程序不同的SCADA方法。当本地使用SCADA系统时，首选方法包括将用户界面上的图形绑定到存储在特定PLC存储器地址中的数据。然而，当数据来自传感器，控制器和数据库（可能是本地或处于不同连接位置）的不同组合时，典型的1到1映射成为问题。解决这个问题的方法是数据建模，一种从面向对象编程中衍生的概念[14]

在数据模型中，在SCADA软件中构建了每个设备的虚拟表示。这些虚拟表示（“模型”）不仅可以包含所表示的设备的地址映射，还可以包含SCADA的其他方面可以使用的任何其他相关信息（基于Web的信息，数据库条目，媒体文件等） / IoT实现。随着事物互联网的复杂性日益提高，传统的SCADA越来越“受限制”，随着通信协议的发展，有利于平台无关的面向服务的架构（如OPC UA），[15]可能更多的SCADA软件开发人员将实施某种形式的数据建模。

安全问题

将电力，石油，天然气管道，配水和废水收集系统等分散设施相结合的SCADA系统设计为开放，稳健，易于操作和维修，但不一定安全。[16]从专有技术转向更标准化和开放的解决方案，以及SCADA系统，办公室网络和互联网之间的连接数量增加，使得它们更容易受到计算机安全性相对较常见的网络攻击的攻击。例如，美国计算机应急准备小组（US-CERT）发布了一个漏洞咨询[17]，警告未经身份验证的用户可以从感应自动点火系统下载敏感的配置信息，包括密码散列，利用标准攻击类型，利用Tomcat Embedded网络服务器。安全研究员Jerry Brown在Wonderware InBatchClient ActiveX控件中提交了一个关于缓冲区溢出漏洞的类似建议[18]。两家供应商在公开漏洞发布之前都提供了更新。缓解建议是标准修补方法，需要VPN访问以实现安全连接。因此，一些基于SCADA的系统的安全性已经受到质疑，因为它们被认为可能容易受到网络攻击。[2] [19] [20]

特别是安全研究人员担心：

在一些现有的SCADA网络的设计，部署和运行中，对安全和认证的担心不大

认为SCADA系统通过使用专用协议和专有接口，通过晦涩的方式获益于安全

认为SCADA网络是安全的，因为它们是物理安全的

认为SCADA网络是安全的，因为它们与Internet断开连接

SCADA系统用于控制和监控物理过程，其中例子是电力传输，管道中瓦斯和油的运输，配水，交通信号灯和其他用作现代社会基础的系统。这些SCADA系统的安全性很重要，因为这些系统的妥协或破坏将影响到远离原始妥协的社会的多个领域。例如，由受损的电气SCADA系统造成的停电会对从该来源接收电力的所有客户造成经济损失。安全性如何影响旧的SCADA和新的部署还有待观察。

现代SCADA系统有许多威胁载体。一个是未经授权访问控制软件的威胁，无论是人为访问还是由病毒感染和其他存在于控制主机上的其他软件威胁而有意或意外引起的更改。另一个是分组访问托管SCADA设备的网段的威胁。在许多情况下，控制协议缺乏任何形式的加密安全性，允许攻击者通过网络发送命令来控制SCADA设备。在许多情况下，SCADA用户假设拥有VPN提供足够的保护，不知道可以通过与SCADA相关的网络插孔和交换机进行物理访问来简单地绕过安全性。工业控制供应商建议接近SCADA安全性，如信息安全，利用普遍IT实践的深度战略防御。[21]

SCADA系统在现代基础设施中的可靠功能可能对公共卫生和安全至关重要。因此，对这些系统的攻击可能直接或间接地威胁到公共卫生和安全。这种袭击已经发生，在澳大利亚昆士兰州的Maroochy Shire委员会污水控制系统上进行。[22] 2000年1月承包商安装SCADA系统后不久，系统组件开始运行不正常。泵不需要时运行，没有报警。更严重的是，污水淹没了附近的一个公园，污染了一个开放的地表水排水沟，并流向500米到潮汐渠。当设计协议保持关闭时，SCADA系统正在引导污水阀打开。最初这被认为是一个系统错误。监控系统日志显示，网络攻击造成的故障。调查人员在确定罪犯之前报告了46次不正当的恶意外部干涉事件。攻击是由安装了SCADA系统的公司的不满的前雇员做出的。前雇员希望由公用事业全职雇用，以维持该制度。

2008年4月，评估美国威胁电磁脉冲（EMP）攻击的委员会发布了一个关键的基础设施报告，该报告讨论了SCADA系统对电磁脉冲（EMP）事件的极端脆弱性。经过测试和分析，委员会得出结论：“SCADA系统容易受到EMP事件的影响，所有国家关键基础设施的大量和广泛依赖这些系统对EMP事件后继续运行构成系统性的威胁，重新启动，修复或更换大量分散在地理上分散的系统的必要性将严重阻碍该国从这种袭击中复苏。“[23]

SCADA和控制产品的许多供应商已经开始通过开发用于基于TCP / IP的SCADA网络以及外部SCADA监控和记录设备的专用工业防火墙和VPN解决方案来解决未经授权的访问所带来的风险。国际自动化学会（ISA）于2007年与工作组第四工作组开始正式确定SCADA安全要求。 WG4“专门针对评估和确保工业自动化和控制系统设备的安全弹性和性能所需的独特技术要求，测量和其他功能”。[24]

对SCADA漏洞的兴趣增加，导致漏洞研究人员发现商业SCADA软件的漏洞和更普遍的进攻性SCADA技术呈现给一般安全机构。[25]在电力和煤气公用事业SCADA系统中，有时和无线串行通信链路的大型安装基础的脆弱性在某些情况下通过应用使用认证和高级加密标准加密的无线设备来解决，而不是替换所有现有的节点[26]

2010年6月，防病毒安全公司VirusBlokAda报告第一次检测到在Windows操作系统上运行的SCADA系统（西门子WinCC / PCS 7系统）的恶意软件。恶意软件被称为Stuxnet，并使用四个零日攻击来安装一个rootkit，然后再登录到SCADA的数据库并窃取设计和控制文件。[27] [28]恶意软件还能够更改控制系统并隐藏这些更改。恶意软件被发现在14个系统上，其中大部分位于伊朗。[29]

2013年10月，国家地理局发布了一个名为“美国停电”的文件，涉及对SCADA和美国电网的大规模网络攻击。[30]

另见

DNP3

IEC 60870

Modbus

BACnet

LonWorks

EPICS

参考文献

Boys, Walt (18 August 2009). "Back to Basics: SCADA". Automation TV: Control Global - Control Design.

Jump up to: a b "Cyberthreats, Vulnerabilities and Attacks on SCADA Networks" (PDF). Rosa Tang, berkeley.edu. Archived from the original (PDF) on 13 August 2012. Retrieved 1 August 2012.

Boyer, Stuart A. (2010). SCADA Supervisory Control and Data Acquisition. USA: ISA - International Society of Automation. p. 179. ISBN 978-1-936007-09-7.

Jeff Hieb (2008). Security Hardened Remote Terminal Units for SCADA Networks. University of Louisville.

Aquino-Santos, Raul (30 November 2010). Emerging Technologies in Wireless Ad-hoc Networks: Applications and Future Development: Applications and Future Development. IGI Global. pp. 43–. ISBN 978-1-60960-029-7.

"Introduction to Industrial Control Networks" (PDF). IEEE Communications Surveys and Tutorials. 2012.

Bergan, Christian (August 2011). "Demystifying Satellite for the Smart Grid: Four Common Misconceptions". Electric Light & Powers. Utility Automation & Engineering T&D. Tulsa, OK: PennWell. 16 (8). Four. Retrieved 2 May 2012. satellite is a cost-effective and secure solution that can provide backup communications and easily support core smart grid applications like SCADA, telemetry, AMI backhaul and distribution automation

OFFICE OF THE MANAGER NATIONAL COMMUNICATIONS SYSTEMctober 2004. "Supervisory Control and Data Acquisition (SCADA) Systems" (PDF). NATIONAL COMMUNICATIONS SYSTEM.

"SCADA Systems april 2014".

J. Russel. "A Brief History of SCADA/EMS (2015)".

Jump up to: a b Security Hardened Remote Terminal Units for SCADA Networks. ProQuest. 2008. pp. 12–. ISBN 978-0-549-54831-7.

"SCADA as a service approach for interoperability of micro-grid platforms". Sustainable Energy, Grids and Network. 2016. doi:10.1016/j.segan.2016.08.001.

How The "Internet Of Things" Is Turning Cities Into Living Organisms Retrieved September 16, 2013

"The History of Data Modeling". Exforsys Inc. 11 January 2007.

"CIM and OPC UA for interoperability of micro-grid platforms". Proceeding of the IEEE ISGT 2016 Conference. 6 September 2016.

Boyes, Walt (2011). Instrumentation Reference Book, 4th Edition. USA: Butterworth-Heinemann. p. 27. ISBN 0-7506-8308-2.

"ICSA-11-231-01—INDUCTIVE AUTOMATION IGNITION INFORMATION DISCLOSURE VULNERABILITY" (PDF). 19 Aug 2011. Retrieved 21 Jan 2013.

"ICSA-11-094-01—WONDERWARE INBATCH CLIENT ACTIVEX BUFFER OVERFLOW" (PDF). 13 Apr 2011. Retrieved 26 Mar 2013.

D. Maynor and R. Graham (2006). "SCADA Security and Terrorism: We're Not Crying Wolf" (PDF).

Robert Lemos (26 July 2006). "SCADA system makers pushed toward security". SecurityFocus. Retrieved 9 May 2007.

"Industrial Security Best Practices" (PDF). Rockwell Automation. Retrieved 26 Mar 2013.

Slay, J.; Miller, M. (November 2007). "Chpt 6: Lessons Learned from the Maroochy Water Breach". Critical infrastructure protection (Online-Ausg. ed.). Springer Boston. pp. 73–82. ISBN 978-0-387-75461-1. Retrieved 2 May 2012.

http://www.empcommission.org/docs/A2473-EMP_Commission-7MB.pdf

"Security for all". InTech. June 2008. Retrieved 2 May 2012.

"SCADA Security – Generic Electric Grid Malware Design". Archived from the original on 7 January 2009.

KEMA, Inc. (November 2006). "Substation Communications: Enabler of Automation / An Assessment of Communications Technologies". UTC – United Telecom Council: 3–21.

Mills, Elinor (21 July 2010). "Details of the first-ever control system malware (FAQ)". CNET. Retrieved 21 July 2010.

"SIMATIC WinCC / SIMATIC PCS 7: Information concerning Malware / Virus / Trojan". Siemens. 21 July 2010. Retrieved 22 July 2010. malware (trojan) which affects the visualization system WinCC SCADA.

"Siemens: Stuxnet worm hit industrial systems". Retrieved 16 September 2010.[dead link]

"American Blackout". National Geographic Channel. Retrieved 14 October 2016.

介绍

监控和数据采集（SCADA）是一种允许主设备操作员监视和控制分布在各个远程站点之间的进程的系统。

正确设计的SCADA系统通过消除维修人员访问每个站点进行检查，数据收集/记录或进行调整的需要，节省了时间和金钱。使用EPG具有成本效益的远程终端单元和易于使用的主控软件，您可以消除耗时，昂贵的现场访问并控制单个主位置的所有进程。实时监控，系统修改，故障排除，设备寿命延长，自动生成报表。 。 。这些只是今天SCADA系统带来的好处。

SCADA系统提供的其他优点：

降低运营成本

提供系统性能的即时知识

提高系统效率和性能

提高设备寿命

减少昂贵的维修费用

减少故障排除或维修所需的工时（人工成本）

释放人员进行其他重要任务

通过自动生成报告促进监管机构的遵守

和更多 。 。 。

随着技术的不断发展，SCADA系统将被公认为任何处理站点的标准。但是从今天数百个系统提供商可以听到哪一个？什么系统适合您的应用？你会选择与谁合作，为什么？

选择一个可以设计适合您需求的系统的SCADA系统提供商可能是一个压倒性的，令人困惑的任务。对SCADA和数据采集系统的了解甚少或不完整的系统前评估，所做出的决定可能是代价高昂的错误。这些决定常常是基于的。 。 。

价钱：

当供应商渴望获得低投标时，工作和组件的质量受损。然后，供应商将不分青红皂白地寻找仍然可以获利的方法。你得到你所付出的！

专有设备：

不要消除你的选择。专有设备安装为系统的“标准”后，客户可能被扣为人质，被迫付出了高昂的代价。另外，一个封闭的协议使最终用户有更少的选择来集成供应商的未来设备，并且容易受到缺乏支持和由于过时和/或公司关闭而无法替换故障组件的弱点。

过度复杂或定制设备：

系统专家表示许多运营商对其SCADA系统的所有功能进行了“哇”。安装后，系统太复杂，无法理解，操作和支持。您将拥有的是一个非常昂贵的系统运行，而运营商继续工作的老习惯。唯一的诉求是购买昂贵的培训和/或服务合同，这并不总是保证及时和专业的服务。一些SCADA系统已经关闭了几个月，等待单一的技术支持来源到达。尽可能保持简单。

多年经验：

小心。有许多声誉良好的SCADA提供商，拥有多年的经验和丰富的专业知识，设计出过于广泛，昂贵和/或不起作用的系统。许多公司使用这条线，好像它把它们与其余的一样。经验和知识是重要的，但只有在确定什么供应商适合您时才能作为出发点。

销售人员和/或Flashy营销：

良好的销售和营销策略旨在产生“顶尖”，“脚踏实地”的结果。他们可能引诱你或压力，而不是根据影响最佳系统性能的所有因素来配备您做出正确的决定。

这些和其他昂贵的错误可以通过了解，理解和仔细评估您的特定需求来避免。对于某些人来说，这可能意味着撇开这篇文章，然后专注于本文末尾所提到的“要考虑的问题”。对于其他人，SCADA知识很少或没有，您应该阅读并熟悉以下提供的背景信息。

EPG公司公司已经准备了该SCADA系统评估，以帮助您确定什么SCADA或数据采集系统适合您。如果您在审查此评估后有任何问题或意见，请致电800-443-7426，并要求SCADA或数据采集专家。我们服务于20多年的制造系统，节省时间和金钱，易于使用，并提供多年可靠的过程控制。

一个简短的历史

随着遥测技术的出现，SCADA的发展可以追溯到二十世纪初。遥测涉及通过感测实时条件获得的数据的传输和采集。随着电力，电报，电话和无线通信技术的融合，遥控条件的监测变得可能。在上个世纪，更多的工业，如天然气，电力和水务公司，使用遥测系统来监测偏远地区的进程。

SCADA始于六十年代初，作为在主站和远程终端单元（RTU）站之间作为输入/输出（I / O）信号传输的电子系统。主站将通过遥测网络从RTU接收I / O传输，然后将数据存储在主机上。

在七十年代初期，开发了DCS（分布式控制系统）。 ISAS5.1标准将分布式控制系统定义为在功能集成的同时由一个子系统组成的系统，这些子系统可以在物理上分开并且彼此远离。大型制造商和工艺设备利用DCS主要是因为需要大量的模拟控制。

进一步开发使分布式控制系统能够使用比RTU更智能的可编程逻辑控制器（PLC）能够控制站点而不从主站获取方向。

在九十年代后期，SCADA与DCS之间的差异模糊。 SCADA系统具有DCS功能。 DCS具有SCADA功能。系统根据设计师内置的某些控制功能进行定制。现在随着互联网被更多地用作通信工具，一旦旧的遥测系统变得越来越先进，互连和可访问的控制功能。正在开发自动软件产品以利用互联网的互连性，某些门户可以连接到SCADA系统并下载信息或控制流程。

今天，良好的SCADA系统不仅可以控制流程，还可用于测量，预测，计费，分析和规划。今天的SCADA系统必须满足一个全新的控制自动化水平，与昨天的过时设备连接，灵活性足以适应未来的变化。

无论您需要新系统还是升级旧系统，重要的是在决定与谁通话之前了解系统组件，以及您将为特定应用程序需要哪些设备。

系统组件

SCADA系统通常有四个主要元素：

主终端单元（MTU）

远程终端单元（RTU）

通讯设备

SCADA软件

1.主终端单元（MTU）

主站终端单元通常定义为SCADA系统的主站或主站，位于运营商的中央控制设施。 MTU几乎可以发起所有与远程站点的通信和与操作员的接口。将远程现场设备（泵，阀门，报警器等）的数据发送到MTU进行处理，存储和/或发送到其他系统。例如，MTU可以将数据发送到操作员的显示控制台，存储信息，然后将操作员的启动命令发送到现场泵的RTU。

2.远程终端单元（RTU）

远程终端单元通常定义为SCADA系统内的通信卫星，位于远程站点。 RTU从内存中的现场设备（泵，阀门，报警器等）收集数据，直到MTU启动发送命令。一些RTU设计有微型计算机和可编程逻辑控制器（PLC），可以在远程站点执行功能，而无需MTU的任何方向。此外，PLC可以是模块化和可扩展的，用于监控和控制其他现场设备。在RTU内部是从通信设备使用的协议接收数据流的中央处理单元（CPU）。该协议可以像Modbus，传输控制协议和互联网协议（TCP / IP）或专有的闭路协议一样开放。当RTU看到其节点地址嵌入在协议中时，数据被解释，CPU指示指定的动作。

在六十年代，许多制造商开发了具有交互功能的RTU，执行了一些特定任务，如监视和控制数字和模拟现场设备。这些“一体化”RTU需要与MTU持续通信才能运行。使用了众所周知或不支持的各种编程语言。在八十年代，第一个“微型”PLC被引入作为第一个“开放式架构”技术，它已经发展并获得了接受，作为今天被关闭的专有系统的首选。

一些制造商，如EPG的SCADA部门NBT，现在专门为SCADA和数据采集应用设计了远程访问PLC（RAPLC）。使用NBT的PLC系统，您可以：

执行控制

检查现场条件

随时随地重新编程

有任何闹钟或事件触发您的个人电脑的电话

这可以从单个主站点完成，系统可以控制一个或多个站点。行业代表和客户都欢迎这些“智能”PLC，因为它们提供远程可编程功能，同时保留RTU的通信能力。

3.通讯设备

设置SCADA系统网络（拓扑）的方式可能会随着每个系统的不同而有所不同，但MTU和RTU之间必须有不间断的双向通信，以使SCADA或数据采集系统正常工作。这可以通过各种方式实现，例如专用线路，埋地电缆，电话，遥测硬件如无线电和调制解调器，微波盘，卫星或其他大气装置，并且多次系统采用多种通信方式远程站点。这可能包括拨号或专用语音级电话线，DSL（数字用户线），综合业务数字网（ISDN），电缆，光纤，WiFi或其他宽带服务。

选择合适的通讯设备时可以考虑多种选择，可以包括公共和/或私人媒体。公共媒体是一种通信服务，客户可以每月或每次或使用时间付费。私人媒体由用户拥有，许可，操作和服务。如果您选择使用私人媒体，请考虑支持系统技术和维护方面所需的员工需求。

私人媒体类型：

私人电线

有时在站点之间串联或埋葬自己的电缆是有意义的，以提供持续的沟通。这种类型的媒体通常限于低带宽调制解调器。

无线

（扩频无线电）

这种媒体类型是免授权的，在900 MHz和5.8GHz频段可供公众使用。系统使用的频率越高，它的“视线”越多。一些扩频遥测无线电单元能够通过重新加强下一个无线电在线的信号来跨越距离，像网络中的其他单元的中继器一样。扩频无线电调制解调器通常内置纠错，加密和其他功能，使其成为网络通信的可靠，安全和持久的解决方案。

（微波收音机）

微波收音机通过安装在塔楼或建筑物顶部的抛物面碟子以高频传播。该媒体使用点对点的视距技术，并且由于不对准和/或大气条件，通信可能会中断。

（VHF / UHF无线电）

VHF / UHF无线电是高达30英里的高频无线电是由特殊天线接收的频率为175MHz-450MGz-900MHz的电磁传输。必须获得FCC许可证，覆盖范围仅限于特殊的地理边界。

公共媒体类型：

（电话公司）

您的本地电话公司可提供不同的服务，包括：交换线路，私人专线，数字数据服务，蜂窝和PCS / CDPD。

交换线路：公共交换机电话网（PSTN）和通用交换电话网（GSTN）是本地电话公司提供的拨号语音和数据传输网络。

专用专用线路：专用专线（PLL）在两个或多个位置之间每天24小时永久连接，并用于模拟（连续变化的信号）数据传输。

数字数据业务：数字数据业务（DDS）是一种专用专线，具有特殊带宽，用于以更高的速度和更低的误码率传输数据。此服务适用于计算机与计算机的连接。

蜂窝：这项服务相当于陆上线路上的交换线路业务。

PCS / CDPD：该服务由蜂窝公司按月费用或流量量提供，并在需要持续通信时使用。

其他媒体类型：

（WiFi-SMR）

有时使用另一家公司的基础设施是有意义的。 WiFi设备利用高数据速率的宽带，并以“时间分配”的方式用于系统站点之间的通信。该媒体类型通常需要高级协议，如TCP / IP和网络类型连接。

（卫星同步/ LEO）

地球同步卫星的轨道与地球的轨道同步，并保持在相对于地球的相同位置。这些卫星使用抛物面天线接收的高频传输。低地球轨道（LEO）卫星将信号切换到其他卫星以进行连续的覆盖，而由于较低的轨道，等待时间小于地球同步卫星。

4.SCADA软件

典型的SCADA系统提供人机界面（HMI），允许操作员在系统运行时可视化所有功能。操作员还可以使用HMI来更改设定点，查看关键状态警报和警告，并分析，归档或呈现数据趋势。自Windows NT出现以来，HMI软件可以安装在PC硬件上，作为实际系统在工作中的可靠表示。

通用HMI软件包包括Cimplicity（GE-Fanuc），RSView（罗克韦尔自动化），IFIX（Intellution）和InTouch（Wonderware））。大多数这些软件包使用标准数据操纵/表示工具来报告和归档数据，并与Microsoft Excel，Access和Word完美集成。

基于Web的技术也被广泛接受。由SCADA系统收集的数据被发送到动态生成HTML页面的Web服务器。这些页面然后被发送到操作员站点的LAN系统或发布到因特网。

微处理器选项

既然您对SCADA系统组件有了基础的了解，您可能需要考虑在基本或低成本RTU遥测系统或专有系统上使用微处理器（MP）和/或基于PLC的SCADA系统，以实现以下功能原因：

像MTU这样的MP可以通过“智能”编程来连续收集，处理和存储数据，从MTU独立运行。此外，通过使用基于微处理器的EPG 2551型电平表（如图所示），您可以拥有一个强大的SCADA系统，同时具有主站和本地显示屏，可自动收集，处理和报告符合当地，州和联邦法规要求的数据在Microsoft Excel，Access和Word中集成的格式。

MP可以提供门开关，热和运动检测器的安全和监控。通过自动电子邮件，寻呼和拨号呼叫功能，每天24小时可以通知经理/运营商。可以轻松添加多个用户，如果使用开放式架构协议，则可以轻松集成未来的设备。由于MP没有移动部件，它们是非常可靠的，并且可以被设计为可以使用任何本地电气分配器供应的部件进行修理。

基于MP的SCADA系统可以减少现场视觉检查，调整，数据采集和记录所需的工时数。持续监控和排除潜在问题会增加设备使用寿命，减少服务电话，减少客户投诉并提高系统效率。简单地说，开放架构，基于MP的SCADA系统是过程控制设施节省时间和金钱的极好手段。

特点与优势

现在，您可以看一下从正确设计的基于PLC的SCADA系统获得的一些功能和优点。

特征：

PLC没有移动部件。它们非常坚固可靠。

如果与MTU的通信丢失，则基于PLC的RTU可以通过“智能”编程单独运行。

PLC程序易于理解和易于使用，可以通过简单和广泛的描述，技术编程和支持手册进行完整的记录。

PLC是模块化的，可以为未来的扩张和增长提供空间。

安全传感器的编程可以集成到PLC中，为门开关，热和运动检测器提供安全和监控。然后，SCADA系统可以根据规定自动通知。

无等待期更换电气元件。 SCADA系统可以设计为使用任何本地或国家电气分配器供应的组件。

内置诊断的标准可以在易于理解的文本中持续监控和显示所有状态和故障信息。

HMI（人机界面）软件可以提供广泛的屏幕文档，包括操作员手册，接线图，程序等。

基于PLC的SCADA系统可以自动收集和报告必要的数据，以符合Microsoft Excel，Access和Word集成的格式的本地，州和联邦法规。

收集的数据可以存储在PLC和MTU数据库中，提供更强大的报告系统。

SCADA系统可以通过自动电子邮件，寻呼和拨号呼叫功能，每天24小时通知管理人员和操作员。

泵，监控系统，液位和流量传感器等的未来升级和/或新安装可以轻松集成到系统中。

多个用户功能可以通过基于Web的技术轻松集成到SCADA系统中。

优点：

基于PLC的设备通常更可靠，可以无主控制方向运行。

操作员可以看到实时的系统故障。

客户投诉/查询的数量可以大幅度减少，例如：有关低压的来电或水系的水质差。

PLC SCADA系统节省时间和金钱。

可以通过持续监测水平来减少设备的磨损。

用于故障排除和/或维护的工时可以大大减少。

劳动力成本可以通过自动生成报表来减少。

与专有系统相比，使用基于PLC的SCADA系统可以降低运营成本，提高投资回报率（ROI）。

符合当地，州和联邦机构的要求比较容易。

维修技术人员的昂贵的服务电话可以消除。

本地系统集成商和电气分销商可以提供所需的支持。

NBT基于PLC的SCADA系统使用开放架构，非专有产品和协议。价格表出版，以消除“人质”，歧视性的价格固定。

您可能会想到适用于您自己的网站的其他一些好处。首先回答以下问题：

PLC SCADA系统可以为您的网站做什么？

在主站/远程站点执行什么类型的操作？

通过在您的站点安装PLC SCADA系统，您希望获得什么好处？

您需要哪些方面的SCADA系统？组织您的想法以备将来参考，然后如果您需要更多帮助，请给我们打电话。

在评论

今天的SCADA系统是过程控制站点运营商节省时间和金钱的绝佳手段。但是从数以千计的SCADA系统供应商可以选择，一个糟糕的决定可能会导致你走上无数沮丧的道路，低效率和不必要的费用。 EPG公司公司已经准备了这个系统前评估，以帮助您准备购买SCADA系统的方式，为您提供多年的成本效益和可靠的流程控制，同时为您开放明天的扩张和选择。最后考虑以下几点：

考虑的问题

正确设计的PLC SCADA系统产生的ROI（投资回报率）和优势将远远超过您选择正确的设备并正确安装的初始投资。为了帮助促进适当和有益的选择，请考虑回答以下内容：

现有设备

你有多少网站在运作？

目前所有场地都有什么类型的设备？ （泵，阀，显示器等）

将来会安装什么类型的设备？ （升级，添加，新站点等）

目前安装什么类型的遥测，数据采集或SCADA系统？ （专有，过时，基本遥测等）

目前有什么类型的遥测网络或通信路径？

拓扑：点对点，点对多点，多点到多点

传输模式：硬线，电话，光纤，无线电/微波

正在使用什么类型的协议，并且它将与未来的设备融合？

本系统正在使用什么类型的软件？它是否附带完整的文档和支持？将来可能会得到支持吗？

目前系统中有多少数据依赖用户？

您对现有系统的性能标准有多好？可靠吗

什么设备可以/将继续使用？ （现场设备，现有SCADA组件，软件等）

现有的设备和/或升级可以很好地整合并与新设备通信吗？

目前有什么类型的维护或服务安排？新设备如何改变？

您目前的检查，维护和修理费用是多少？如何改变成为具有成本效益的？新的SCADA或数据采集系统将如何改变？

如果对现有系统做出改变，外部供应商（电话公司，卫星链路等）的服务会发生变化，这些变化是什么？ （新传输模式，服务费等）

未来系统需求

（遥测/通信路径）

控制中心位于哪里？

您需要跨站点的距离是多少？

将来会增加额外的网站吗？

如果知道控制中心与现在和未来的现场之间有什么障碍？

什么拓扑和传输模式最适合您的应用？

什么传输媒体可用？ （每个网站可能会有所不同）

您的维护/服务需求是什么？你会分配自己的维修人员还是外包？

预算花多少钱？

（协议编码/译码）

将来的系统会使用现有的协议吗？ （如果新购买，请勿使用专有协议！您将减少用于集成未来设备的选项，如果可能，请使用Modbus协议。

有完整的文件吗？

您需要连接哪些现有设备？

您是否需要多厂商软件应用程序与各种制造商的设备进行通信？

考虑安全问题：需要什么类型的保护/保护措施，以防止黑客入侵，篡改，破坏和其他未经授权的使用。

（主控台）

您需要主站来控制本地输入/输出和备份操作吗？

您的应用程序需要多少站点和站点？

远程站是否收集与主站无关的数据？

采购原则

使用开放标准架构，即Modbus协议。

从知名的，成熟的制造商处购买。

设备必须与现有和未来的设备完美结合。

设备必须是可支持的并有详细记录。

设备和系统整体必须可靠。

设备必须易于使用，不会造成日常业务的干扰。

设备必须是非专有技术。

EPG设备采用开放架构的Modbus协议，具有良好的文档记录，并将集成到任何现有的系统中。 20多年来，我们为数以千计的行业专业人士制造了可靠，经济高效的过程控制解决方案。

0x1 简介

DNP(Distributed Network Protocol，分布式网络规约)是一种应用于自动化组件之间的通讯协议，常见于电力、水处理等行业。SCADA可以使用DNP协议与主站、RTU、及IED进行通讯。

DNP协议标准由IEEE提出，参考了IEC 870-5、以及其他一些IEC协议。主要为了解决SCADA行业中，协议混杂、没有公认标准的问题。

DNP协议有一定的可靠性，这种可靠性可以用来对抗恶劣环境中产生的电磁干扰、元件老化等信号失真现象，但不保证在黑客的攻击下、或者恶意破坏控制系统的情况下的可靠性。

DNP协议提供了对数据的分片、重组、数据校验、链路控制、优先级等一些列的服务，在协议中大量使用了CRC校验来保证数据的准确性。以下是一些DNP协议的特点：

• DNP3.0规约是一种分布式网络协议，适用于要求高度安全、中等速率和中等吞吐量的数据通信领域。

• DNP3.0规约以IEC870-5标准为基础，该规约非常灵活，满足目前和未来发展的要求，且与硬件结构无关。

• DNP3.0规约采用网络通信方式。

• DNP3.0规约支持点对点、一点多址、多点多址和对等的通信方式。

• DNP3.0规约支持问答式和自动上报数据传输方式。

• DNP3.0规约支持通信冲突碰撞避免/检测方式，能保证数据传输的可靠性。

• DNP3.0规约支持传送带时标的量，尤其有利于配电自动化系统采集分时电度值和分析事故原因。

• 灵活采取适当的扫描方式，DNP3.0规约可以在一定程度上实现实时优先级。

0x2 协议格式

DNP3.0规约的文本共分4部分：数据链路层规约，传输功能，应用层规约及数据对象库。

0x2.1 数据链路层规约

数据链路层规约文件规定了DNP3.0版的数据链路层，链路规约数据单元(LPDU)以及数据链路服务和传输规程。

数据链路层采用一种可变帧长格式：FT3。

一个FT3的帧被定义为一个固定长度的报头，随之以可选用的数据块。每个数据块附有一个16位的CRC校验码。固定的报头含有2个字节的起始字，1个字节的长度，1个字节的控制字，1个16位的目的址，1个16位的源地址和1个16位的CRC校验码。

0x2.2 传输功能

这部分定义对于DNP数据链路层充当伪传输层的传输层功能。伪传输层功能专门设计用于在原方站和副方站之间传送超出链路规约数据单元(LPDU)定义长度的信息。

0x2.2.1 传输层报头数据块

其中：传输层报头——传输控制字，1个字节；数据块——用户数据，1～249个字节。

0x2.3 应用规约

这部分定义了应用层报文(APDU)的格式。这里，主站被定义为发送请求报文的站，而外站则为从属设备。被请求回送报文的RTU或智能终端(IEDs)是事先规定了的。在DNP内，只有被指定的主站能够发送应用层的请求报文，而外站则只能发送应用层的响应报文。

0x2.3.1 应用报文格式

其中：请求(响应)报头——标识报文的目的，包含应用规约控制信息(APCI)；对象标题——标识后随的数据对象；数据——在对象标题内的指定类型的数据对象。

0x2.3.2 应用报文报头字段的定义

请求报头分应用控制、功能码两个字段。每个字段为8位的字节；响应报头分应用控制、功能码、内部信号字3个字段。每个字段也为8位的字节。

0x2.3.3 对象标题

报文的对象标题制定包含在报文中的数据对象或是被用来响应此报文的数据对象。

应用报文中，对象、限定词、变程的灵活使用，可以表示多种数据类型和数据表示格式，满足用户的不同需要。这也是DNP3.0规约的一大优点。

注：以上摘自网络

0x3 DNP设备识别方法

DNP3可通过TCP/UDP进行封装，以便在以太网上运行，支持DNP3协议的从设备默认会开放TCP的20000端口用于通信。DNP3协议在设计之初依然是没有考虑到安全、认证等的一些因素，以致后来出现了Secure DNP3（主要加强了认证）。在DNP3目前的应用、传输上个人的观点还是要比MODBUS可靠，DNP3在主站会话上需要约定目的地址、源地址，而从设备收到后需要验证目标地址，然后再进行处理，如果目的地址不相同则会根据在协议栈实现的处理上来决定是否不响应和关闭连接，或者返回异常功能报文等。想要精准识别运行在tcp的20000端口的服务是否为DNP3，可以使用DNP链路层协议(协议格式如下图)，

将其封装成需要发送的识别报文，这样便可以枚举出想要通信设备的目的地址，又能准确判断该端口运行有DNP3服务，并且报文构造相对简单。

在协议的控制字方面可以使用协议中的9号功能码请求链路状态，相应的设备如果响应回复一般则会返回11，如下图为控制字格式：

如下图为功能码取值：

需要注意的是正因为设备对非法连接(目的地址)请求的处理方式不一样，在应用到实际的全网扫描中不可能全部尝试到所有的地址(目的地址长2个字节，范围在0-65535)，另外还需要实现协议的CRC的算法。这样从实现到扫描整体的代价都会比较大。

那么我们可以看一下Shodan在DNP协议的识别这块是如何做的，如下图是在公网监听了tcp/20000端口后收到的包。

我们可以看到Shodan在针对DNP3协议在公网扫描识别上，也还是采用了枚举的方式，并且看似有些暴力，再根据下图你会发现Shodan总共尝试了101个地址，

故你会在Shodan检索port:20000时发现设备的源地址（Source address/对应主站的目的地址）都没有超过100。

那我们实现针对DNP的扫描插件时也可参照Shodan的做法，在组包时定义一段范围的地址来进行批量探测，并且探测1-100的目的地址组包大小有1010个字节，在批量扫描探测时还要受网络收发延时影响。所以Shodan目前能检索到的数据也不足1000，现在看来貌似也没有相对好的做法。

根据Shodan的套路这个扫描规则还是很好制定的，我们可以定义一个探测包，再定义判断返回报文的长度、包头部是否为DNP的协议头0x05，0x64，然后解析源、目的地址、功能码，非常简单就能实现一个与Shodan一模一样的针对DNP3协议扫描的基于NMAP的NSE插件。

0x4 调试及工具分享

如下工具可以快速帮你熟悉、调试、仿真、测试DNP3协议：

opendnp3

opendnp3是automatak开源的基于IEEE-1815 (DNP3)的开源协议栈。

Aegis™

Aegis™是automatak开源的一个针对工控协议进行模糊测试(Fuzz)的框架，其中包含对DNP3协议模糊测试的模块，官方的Project Robus项目曾经发布过多个应用在DNP3协议健壮性上的漏洞，官方在发布MODBUS模块后貌似没有再继续开源了。

Protocol Test Harness

Protocol Test Harness是Triangle MicroWorks公司开发的一款协议仿真、调试软件，软件可以仿真多种工控协议包括DNP3，可以方便你完成调试、仿真。

EtherNet/IP是由罗克韦尔自动化公司开发的工业以太网通讯协定，由开放DeviceNet厂商协会（ODVA）管理，可应用在程序控制及其他自动化的应用中，是通用工业协定（CIP）中的一部份

EtherNet/IP名称中的IP是“Industrial Protocol”（工业协议）的简称，和网际协议没有关系。

EtherNet/IP是应用层的协定，将网络上的设备视为许多的“物件”。EtherNet/IP为通用工业协定为基础而架构，可以存取来自ControlNet及DeviceNet网络上的物件。

EtherNet/IP使用以太网的物理层网络，也架构在TCP/IP的通讯协定上，用微处理器上的软件即可实现，不需特别的ASIC或FPGA。EtherNet/IP可以用在一些可容许偶尔出现少量非决定性的自动化网络。

EtherNet/IP很容易误解为Ethernet（以太网）及Internet Protocol（网际协议）的组合。不过EtherNet/IP是一个工业使用的应用层通讯协定，可以使控制系统及其元件之间建立通讯，例如可编程逻辑控制器、I/O模组等，EtherNet/IP中的IP是指工业协定。

历史

EtherNet/IP是在1990年后期由洛克威尔自动化公司开发．是洛克威尔工业以太网络方案的一部份。后来洛克威尔就和EtherNet/IP交给ODVA管理，ODVA管理EtherNet/IP通讯协定，并确认不同厂商开发的EtherNet/IP设备都符合EtherNet/IP通讯协定，确保多供应商的EtherNet/IP网络仍有互操作性。

技术细节

EtherNet/IP将以太网的设备以预定义的设备种类加以分类，每种设备有其特别的行为，此外，EtherNet/IP设备可以：

用用户数据报协议（UDP）的隐式报文传送基本I/O资料。用传输控制协议（TCP）的显式报文上传或下载参数、设定值、程式或配方。用主站轮询、从站周期性更新或是状态改变（COS）时更新的方式，方便主站监控从站的状态，讯息会用UDP的报文送出。用一对一、一对多或是广播的方式，透过用TCP的报文送出资料。EtherNet/IP使用TCP端口44818作为显式报文的处理，UDP端口2222作为隐式报文的处理。EtherNet/IP的应用层协定是以使用在DeviceNet、CompoNet及ControlNet的通用工业协定（CIP）为基础。

Modbus是一种串行通信协议，是Modicon于1979年，为使用可编程逻辑控制器（PLC）而发表的。MODBUS是工业领域通信协议的业界标准，并且现在是工业电子设备之间相当常用的连接方式。Modbus比其他通信协议使用的更广泛的主要原因有：

1、公开发表并且无版税要求

2、相对容易的工业网络部署

3、对供应商来说，修改移动原生的位元或字节没有很多限制

Modbus允许多个设备连接在同一个网络上进行通信，举个例子，一个由测量温度和湿度的装置，并且将结果发送给计算机。在数据采集与监视控制系统（SCADA）中，Modbus通常用来连接监控计算机和remote terminal unit (RTU)。

协议版本

Modbus协议目前存在用于串口、以太网以及其他支持互联网协议的网络的版本。

大多数Modbus设备通信通过串口EIA-485物理层进行。

对于串行连接，存在两个变种，它们在数值数据表示不同和协议细节上略有不同。Modbus RTU是一种紧凑的，采用二进制表示数据的方式，Modbus ASCII是一种人类可读的，冗长的表示方式。这两个变种都使用串行通讯（serial communication）方式。RTU格式后续的命令、数据带有循环冗余校验的校验和，而ASCII格式采用纵向冗余校验的校验和。被配置为RTU变种的节点不会和设置为ASCII变种的节点通信，反之亦然。

对于通过TCP/IP（例如以太网）的连接，存在多个Modbus/TCP变种，这种方式不需要校验和的计算。

对于所有的这三种通信协议在数据模型和功能调用上都是相同的，只有封装方式是不同的。

Modbus 有一个扩展版本 Modbus Plus(Modbus+或者MB+)，不过此协定是Modicon专有的，和 Modbus不同。它需要一个专门的协处理器来处理类似HDLC的高速令牌旋转。它使用1Mbit/s的双绞线，并且每个节点都有转换隔离装置，是一种采用转换/边缘触发而不是电压、水平触发的装置。连接Modbus Plus到计算机需要特别的接口，通常是支持ISA（SA85）,PCI或者PCMCIA总线的板卡。

通信和设备

Modbus协议是一个 master/slave 架构的协议。有一个节点是 master 节点，其他使用Modbus协议参与通信的节点是 slave 节点。每一个 slave 设备都有一个唯一的地址。在串行和MB+网络中，只有被指定为主节点的节点可以启动一个命令（在以太网上，任何一个设备都能发送一个Modbus命令，但是通常也只有一个主节点设备启动指令）。

一个ModBus命令包含了打算执行的设备的Modbus地址。所有设备都会收到命令，但只有指定位置的设备会执行及回应指令（地址 0例外，指定地址 0 的指令是广播指令，所有收到指令的设备都会执行，不过不回应指令）。所有的Modbus命令包含了检查码，以确定到达的命令没有被破坏。基本的ModBus命令能指令一个RTU改变它的寄存器的某个值，控制或者读取一个I/O端口，以及指挥设备回送一个或者多个其寄存器中的数据。

有许多modems和网关支持Modbus协议，因为Modbus协议很简单而且容易复制。它们当中一些为这个协议特别设计的。有使用有线、无线通信甚至短消息和GPRS的不同实现。不过设计者需要克服一些包括高延迟和时序的问题。

实现

几乎所有的实现都是官方标准的某种变体。不同的供应商设备之间可能无法正确的通信。一些主要的变化有：

数据类型

IEEE标准的浮点数

32 位整型数

8位数据

混合数据类型

整数中的位域

multipliers to change data to/from integer. 10, 100, 1000, 256 …

协议扩展

16位元的从站地址

32位的数据大小（1个地址 = 返回32位数据）

字交换数据

限制

Modbus是在1970年末为可编程逻辑控制器通信开发的，这些有限的数据类型在那个时代是可以被PLC理解的，大型二进制对象数据是不支持的。

对节点而言，没有一个标准的方法找到数据对象的描述信息，举个例子，确定一个寄存器数据是否表示一个介于30-175度之间的温度。

由于Modbus是一个主/从协议，没有办法要求设备“报告异常”（构建在以太网的TCP/IP协议之上，被称为open-mbus除外）- 主节点必须循环的询问每个节点设备，并查找数据中的变化。在带宽可能比较宝贵的应用中，这种方式在应用中消耗带宽和网络时间，例如在低速率的无线链路上。

Modbus在一个数据链路上只能处理247个地址，这种情况限制了可以连接到主控站点的设备数量（再一次指出以太网TCP/IP除外）

Modbus传输在远端通讯设备之间缓冲数据的方式进行，有对通信一定是连续的限制，避免了传输中的缓冲区漏洞的问题

简而言之，Modbus是通信协议，OPC是实现不同协议（如Modbus）的开放标准。

Modbus

http://www.modbus.org

OPC

http://www.opcfoundations.org

Modbus是从设备到设备的通信协议

OPC从软件到软件

例如，您可以在PLC（从站）和计算机（主站）之间或在PLC和远程I / O子系统之间，PLC和操作面板之间，或PLC与变频器之间使用Modbus。如果您进入Modbus，考虑到Modbus / TCP（以太网介质）而不是通过RS232 / RS485通过RS232 / RS485考虑速度。

您可以在Windows计算机上的硬件驱动程序软件（OPC服务器）和进程可视化软件（OPC客户端）之间使用OPC，也可以在其他客户端使用OPC，如高级控制，统计信息等。如果服务器和客户机应用程序位于不同的计算机中，则可以通过以太网。

对于Modbus，可以在寄存器中找到数据。每个设备都使用不同的寄存器，如果器件可编程，每个应用的寄存器也将不同。一些设备使用整数，而其他设备使用浮点数。

一些设备使用百分比，而其他设备使用工程单位。您需要参考设备文档来查找哪些信息在哪个寄存器中使用什么格式。这是相当乏味的进行更改经常创建

很多工作。

对于OPC，您可以浏览数据，查看可用的内容，而无需担心其位置和数据类型。这使它更容易使用。 OPC在Windows操作系统上运行，因此OPC取决于计算机的可靠性。

建议：使用Modbus进行闭环控制功能，例如如果来自一个包装单元的互锁信号需要在主控制系统或另一个包装单元的控制策略中起作用。在Modbus中映射几个信号是值得的。使用OPC与软件进行绑定，例如使用PIMS软件和图形显示器，因为PIMS和许多其他软件可能无法直接支持Modbus，并且绘制许多参数是很多工作。也就是说，您可能希望对控制中使用的信号使用Modbus和OPC：Modbus，而对于刚刚显示的信号，可能需要使用OPC。

注意不同的控制系统对OPC标签的收费。这里有很大的价格差。一些费用仅在任何时间（本地或远程）显示的标签总数，而其他费用为所有OPC标签，即使当前不显示。

无论是Modbus还是OPC，都将进行一些映射，尽管OPC更少。

要了解OPC，请查看“自动化软件：体系结构，集成和安全性”一书。预览，查看内容，并在线购买：

http://www.isa.org/autosoftware

即使您在两块硬件之间使用Modbus，一般在使用OPC软件时使用OPC。您可能需要两种技术。在许多情况下，它们相辅相成。

OPC用于软件到软件的通信，用于操作员显示，而Modbus / Profibus用于硬件到硬件进行控制的通信。 OPC主要是驱动程序之间的标准接口软件，主要用于网络和设备硬件，还包括数据库，以及应用程序显示，例如HMI /过程可视化软件。尽管来自许多制造商的应用程序有数百种，其基于OPC的功能不同。

OPC：

OPC在Windows的环境中是从服务器I / O到其他应用程序的数据的原理，例如过程控制，软警报，图形，趋势，高级控制，自动调整，统计等。无论如何应用程序正在不同的实现或相同的计算机。

OPC不是控制器之间联锁通信和闭环的最佳选择。因为它不是完全确定性的或实时的。

您可以使用Windows NT4和2000在安装繁荣，它的工作和运行。 OPC客户端和服务器也实现了可怕的实现，主要是在OPC的早期阶段。如果你使用Windows并不意味着你必须使用OPC。虽然我们必须同意Windows 95和98比任何发布的产品更不稳定。 Windows 2000是非常坚实的，它不能说是造成任何麻烦。您可以简单地在两台Windows机器之间应用Modbus / TCP。不工作OPC通常是由于内存泄漏，由于服务器或客户端中的软件错误。服务器关机是常见问题。

Modbus：

您可以使用Modbus，Profibus或任何其他现场总线进行闭环控制，例如Foundation现场总线。 Modbus和Profibus从外部几乎相似，但有一些差异。 Modbus和Profibus是来自Modicon的西门子和Modbus的Profibus PLC世界。两者都使用RS-485介质，而Modbus也可以应用于RS-232。虽然由于要求Profibus需要专用卡接口，而Modbus可以使用RS-232 / RS-485转换器和标准PC串口。

两者都是主从协议，虽然Profibus构建了循环和非循环命令之间的特性。循环命令重复用于实时I / O，其中通过Profibus中的单个命令进行写入和读取。非循环命令用于非实时通信，如配置和诊断。

Modbus已经有大约多年了。它是所有软件驱动的，不需要任何扫描仪卡，只需RS-485或RS-232。许多公司为Modbus创建软件驱动程序。 Profibus已经存在了很久以前，但没有长达Modbus。这是一个很好的协议，但是需要扫描仪卡，GSD文件和软件配置。 OPC是一个软件界面，可以转换标签名称来告诉协议地址或扫描仪卡。例如：HMI软件的标签名称，OPC标签名称到地址，协议或扫描仪地址。 OPC可以构建生活简单的界面。

Modbus / TCP是互动通信和控制器之间闭环的田园诗。 Modbus / TCP不是计算机之间或应用软件之间通信的最佳选择。这是因为Modbus / TCP简单性来自缺乏逻辑对象结构和标准数据类型。 Modbus将数据分解为最低可行分母。这就是为什么它可以移动到任何地方，但是一旦需要，它会获得许多用户配置，尝试将Modbus注册到参数名称，并将它们合理地分组在对象中，并分离出所有类型的数据被认为是一切改为Modbus的字。对于一些参数是可行的，但是随着最新系统可以访问大量的信息，它不会飞行

 

 

厂商	产品	端口	协议/资料
AB罗克韦尔	Control logix	TCP/44818	EtherNet/IP
Compact	Logix	TCP/44818	EtherNet/IP
General Electric 通用电气	RX3i	TCP/18245	GE SRTP

 

 

Mitsubishi Electric三菱电机,Q Series,TCP/5007,MELSOFT protocol

UDP/5006,MELSOFT protocol

OPTO 22 奥普图,TCP/44818 ,EtherNet/IP

TCP/2001,OPTO 22 Ethernet

OMRON 欧姆龙,CJ2,TCP/44818,EtherNet/IP

UDP/9600,OMRON FINS

PHOENIX CONTACT菲尼克斯,Inline Series,TCP/1962,Unknown

TCP/20547,Unknown

Schneider Electric 施耐德,Quantum ,TCP/502,Modbus/TCP

Siemens 西门子,S7 Series ,TCP/102,ISO-TSAP

前言

目前遇到的各种客户多多少少都对工控安全的防御存在比较大的兴趣，团队里对这方面的研究还比较少。自己就抽空对整个工控安全体系进行了一段时间的学习，算是一个初步的认识。目前按照如下的进度学习相关的知识。仅从安全方面的角度去思考哪些层面可能存在问题，不是系统的工控知识学习。

1234	1、针对整个工控系统的组成进行分析2、工控系统涉及到的相关协议3、工控系统涉及的基础设备4、工控系统存在的安全漏洞

目前已经完成了基本的工控系统组成与modbus协议的分析与设备发现，对常见的安全漏洞也有一定的认识了。

工业控制系统简介

工业控制系统（ICS）在发展之初，使用的协议基本上都是基于串行链路的现场（总线）协议。 随着以太网的发展，早期的串行链路的现场（总线）协议基本都出现了基于以太网（或者互联网）的演化版本。这个演化是非常重要的，由于更多的设备联网，而相关人员的意识还停留在工控系统物理隔离、协议差异的概念里而导致了攻击者能有效的对相关设备、系统进行攻击。

工控行业涉及领域

123	电力行业市政：供水、供电、供暖、供气、水处理、交通等领域新兴：水利、铁路、化工、制造业等。

根据相关安全公司出具的报告现在电力行业中的工控设备联网量是非常多（虽然说是多，但由于基数少，对modbus协议的全国发现量还是不足1000个，不过由于其重要性与敏感性所以危害依然严重）

工控相关协议

123456

Modbus（基本上的行业标准）ProfibusDNP3IEC60870-5-101/104ICCP（IEC60870-6，TASE.2）IEC61850

区别于互联网上常见的http、ftp、dns等协议，工控的协议使用更多的是二进制形式的传输形式，单字节包含特定的含义，当然同样存在ASCII等可见字符的形式，不过前者使用更多。

工控安全脆弱点

12	一：工控协议自身特点所造成的固有问题。（未授权、认证、加密）二：演化至通用计算机、通用操作系统和TCP/IP后继承的问题。

工控中的协议由于其少见，且不像HTTP协议那样，发送端口请求即可得到响应信息，更多的是需要特定的协议通信包才能得到正确的返回，这样对识别联网的工控设备有更高的要求。其中存在较多的是未授权、未认证权限等问题，且大部分的数据是不经过加密处理的。笔者就发现了一些联网RTU/PLC设备可读（由于设备特征不明，读取了也不知道具体的信息指代什么意思，这也是相关的难点）

modbus协议问题若干：

缺乏认证、授权和加密等防护。仅需要一个合法的modbus地址（IP地址，默认端口502）和合法的功能码即可建立一个modbus会话，进行获取信息、写入数据、关停组件等操作，没有任何的访问控制机制，任意用户可执行任意的功能。地址与命令都是明文传输，很容易进行捕获和解析（解析需要对相关字段足够熟悉）。

操作系统、TCP/IP协议问题若干：

比如VxWorks实时操作系统的UDP端口诊断攻击。由于VxWorks的调试服务运行在UDP 17185端口，无需认证。攻击者可伪造服务器IP发送ICMP请求至广播地址引起拒绝服务（当然是个久远的漏洞了）。

同样在局域网中存在ARP攻击、中间人等问题一样存在于工控系统中。

工控系统组成

工控系统一般使用系统数据采集与监控系统（SCADA）进行控制，一般是指由监控程序及数据收集能力的电脑控制系统，其主要功能是监控及控制所有设备的集中式系统。大部分的控制是由远程终端控制系统（RTU）或可编程逻辑控制器（PLC）进行，主系统一般只用作系统监控的控制。SCADA系统包含如下子系统：

12345

人机界面（HMI）计算机远程终端控制系统（RTU），连接程序中的感测器。可编程逻辑控制器（PLC，因其价格便宜，用途广泛，常用作现场设备，替换RTU）通信线路（使用特定的工控通信协议）

SCADA的通信协议会设计的非常精简，设备只有在被主站轮询到才需要发送数据。典型早期的SCADA通信协议包括Modbus RTU、RP-570、Profibus及Conitel。

标准的通信协议包括IEC 60870-5、IEC 60850或是DNP3。

举个大家耳熟能详的例子就是在2010年6月时白俄罗斯的安全公司VirusBlokAda发现了第一个攻击SCADA系统的计算机蠕虫，名称为震网（Stuxnet）。震网攻击在Windows操作系统下运作的西门子WinCC/PCS7系统，利用4个0day漏洞）安装一个Rootkit，在SCADA系统中登录，并且窃取设计及控制的文件[6][7]。此蠕虫可以修改整个控制系统，隐藏其变动的内容。VirusBlokAda在许多系统中发现此蠕虫，大部分是在伊朗、印度及印尼。

监控和数据采集- SCADA是指用于控制基础设施流程（水处理，污水处理，天然气管道，风电场等）的ICS（工业控制系统），基于设施的过程（机场，空间站，船舶等） ）或工业流程（生产，制造，精炼，发电等）。

以下子系统通常存在于SCADA系统中：

•操作人员使用的仪器;所有处理的数据都被呈现给操作员

•监督系统，收集有关流程的所有必要数据

•连接到过程传感器的远程终端单元（RTU），有助于将传感器信号转换为数字数据，并将数据发送到监控流。

•可编程逻辑控制器（PLC）用作现场设备

•通信基础设施将远程终端单元连接到监控系统。

一般来说，SCADA系统不能实时控制进程 - 它通常是指实时协调进程的系统。

SCADA系统概念

SCADA是指控制和监控整个站点的集中式系统，或者是大面积扩展的复杂系统。几乎所有的控制动作由远程终端单元（RTU）或可编程逻辑控制器（PLC）自动执行。对主机控制功能的限制是监督级干预或基本覆盖。例如，PLC（在工业过程中）控制冷却水的流动，SCADA系统允许记录与报警条件和流量设定点（如高温，流量损失等）有关的任何变化记录并显示。

数据采集从PLC或RTU级开始，包括设备状态报告和仪表读数。然后，数据格式化，使得控制室的操作员可以通过使用HMI使监督决定覆盖或调整正常的PLC（RTU）控制。

SCADA系统主要实现称为标签数据库的分布式数据库，其中包含称为点或标签的数据元素。点是由系统控制或监视的单个输出或输入值。点是“软”或“硬”。

系统的实际输出或输入由硬点表示，而软点是应用于其他点的不同数学和逻辑运算的结果。这些点通常存储为时间戳值对。时间戳值对的系列给出了特定点的历史。使用标签存储额外的元数据是常见的（这些附加数据可以包括对设计时间的注释，报警信息，现场设备或PLC寄存器的路径）。

人机接口

HMI或人机界面是将经处理的数据提供给操作人员的装置。人类操作员使用HMI来控制过程。

HMI连接到SCADA系统的数据库，提供诊断数据，管理信息和趋势信息，如物流信息，特定机器或传感器的详细原理图，维护步骤和故障排除指南。

HMI向操作人员提供的信息是图形化的，以模拟图的形式。这意味着被控制的工厂的示意图可供操作者使用。例如，连接到管道的泵的图片显示该泵正在运行，并且还显示了在特定时刻通过管道泵送的流体的量。然后可以由操作员关闭泵。 HMI的软件实时显示管道中流体流量的下降。模拟图包括具有动画符号的过程设备的数字照片，或代表各种过程元素的原理图符号和线图。

SCADA系统的HMI软件包由系统维护人员或操作员使用的绘图程序组成，以更改接口中这些点的表示。这些表示可以像代表该地区实际交通信号灯状态的屏幕上的交通信号灯一样简单，或复杂，像代表摩天大楼铁路或电梯上所有列车的位置的多投影机显示。

SCADA系统通常用于报警系统。报警只有两个数字状态点，值为ALARM或NORMAL。当满足报警的要求时，激活将开始。例如，当汽车的燃油箱为空时，报警被激活并且光信号被打开。要警告SCADA操作员和管理员，发送短信和电子邮件以及报警激活。

SCADA硬件

SCADA系统可能具有分布式控制系统的组件。执行简单的逻辑过程而不涉及主计算机是可能的，因为使用“智能”PLC或RTU。（梯形图逻辑）（这是功能块编程语言，通常用于创建在PLC和RTU上运行的程序。 ）IEC 61131-3具有非常少的培训要求，与程序语言（如FORTRAN和C编程语言）不同。 SCADA系统工程师可以执行在PLC或RTU上执行的程序的实现和设计。紧凑型控制器，可编程自动化控制器（PAC），将基于PC的控制系统的功能和特性与典型的PLC相结合。 “分布式RTU”在各种变电站SCADA应用中，使用站台计算机或信息处理器与PAC，保护继电器和其他I / O设备进行通信。

自1998年以来，几乎所有大型PLC制造商都提供集成的HMI / SCADA系统。其中许多都在使用非专有和开放的通信协议。许多熟练的第三方HMI / SCADA包已经进入市场，提供与几个主要PLC的内置兼容性，允许电气工程师，机械工程师或技术人员独立配置HMI，而无需软件开发人员编写的定制程序。

远程终端单元（RTU）

RTU连接到物理设备。通常，RTU将来自设备的所有电信号转换为数字值，例如阀或开关的状态 - 打开/关闭状态，或流量，压力，电流或电压等测量值。通过将电信号转换和发送到设备，RTU可以控制设备，如关闭或打开阀门或开关，或设置泵的速度。

监控站

“监控站”是指负责与现场设备（PLC，RTU等）进行通信的软件和服务器，之后是在控制室或其他地方的工作站上运行的HMI软件。主站只能由一台PC（小型SCADA系统）组成。主站可以在较大的SCADA系统中拥有多个服务器，灾难恢复站点和分布式软件应用程序。为了提高系统完整性，多个服务器偶尔会配置为热备份或双冗余组合，从而在服务器故障期间提供监控和持续控制。

SCADA操作哲学

控制系统故障所产生的成本非常高。即使生命也许会迷失。对于几个SCADA系统，硬件具有坚固耐用性，可以承受温度，电压和振动极限，并且在许多关键安装中通过包括通信通道和冗余硬件来提高可靠性。可以识别失败的部分，并通过备份硬件自动执行功能。它可以被替换，而不会中断进程。

通信方法与基础设施

SCADA系统最初使用调制解调器连接或直接和无线串行的组合来满足通信要求，即使SONET / SDH上的IP和以太网也可以用于较大的站点，如发电站和铁路。 SCADA系统的监控功能或远程管理称为遥测。

SCADA协议被设计为非常紧凑，并且只有当主站轮询RTU时才将信息发送到主站。通常，SCADA协议的遗留包括Conitel，Profibus，Modbus RTU和RP-570。这些通信协议特别是SCADA供应商。标准协议是IEC 61850，DNP3和IEC 60870-5-101或104.这些协议被所有大型SCADA厂商认可和标准化。这些协议中有几个具有通过TCP / IP进行操作的扩展。

许多自动控制器设备和RTU的开发在互操作性的行业标准出现之前已经开始。

为了更好地在不同的软件和硬件之间进行通信，过程控制的PLE是一种被广泛接受的解决方案，允许最初不打算成为工业网络一部分的设备之间进行通信。

SCADA架构

整体：第一代

在第一代，大型机系统被用于计算。在开发SCADA时，网络不存在。因此，SCADA系统与其他系统没有任何连接，意味着它们是独立系统。后来，RTU供应商设计了有助于与RTU通信的广域网。当时的通信协议的使用是专有的。如果主机系统失败，则有一台备用主机，连接在总线上。

分布式：第二代

多台站之间的信息通过局域网实时共享，处理分布在各个站之间。与第一代相比，车站的成本和规模都有所减少。用于网络的协议仍然是专有的，这导致了SCADA系统的许多安全问题。由于协议的专有性质，实际上很少有人知道SCADA安装的安全性。

网络化：第三代

今天使用的SCADA系统属于这一代。系统与主站之间的通信通过WAN协议（IP协议）完成。由于使用的标准协议和网络化SCADA系统可以通过互联网进行访问，因此系统的脆弱性增加。然而，安全技术和标准协议的使用意味着可以在SCADA系统中应用安全性改进。

SCADA趋势

在20世纪90年代末，而不是使用RS-485，制造商使用诸如Modbus ASCII和Modbus RTU之类的开放式消息结构（均由Modicon开发）。到2000年，几乎所有的I O制造商都提供完全开放的接口，如Modbus TCP，而不是IP和以太网。

SCADA系统现在符合标准的网络技术。旧的专有标准正在被TCP / IP和以太网协议所取代。然而，由于基于帧的网络通信技术的某些特性，以太网已被HMI SCADA的大多数市场所接受。

使用XML Web服务和其他现代网络技术的“下一代”协议使自身更易于IT支持。这些协议的几个例子包括Wonderware的SuiteLink，GE Fanuc的Proficy，I Gear的数据传输实用程序，罗克韦尔自动化的FactoryTalk和OPC-UA。

一些供应商已经开始提供托管在互联网上的远程平台上的特定于应用程序的SCADA系统。因此，无需在用户端设备上安装系统。主要关注的是互联网连接的可靠性，安全性和延迟。

SCADA系统日益变得无所不在。但是，仍然存在一些安全问题。

SCADA安全问题

正在质疑基于SCADA的系统的安全性，因为它们是网络恐怖主义/网络战争攻击的潜在目标。

有一个错误的信念，SCADA网络是安全的，因为它们是物理保护的。也错误地认为SCADA网络足够安全，因为它们与互联网断开连接。

SCADA系统还用于监测和控制物流过程，如现代社会使用的水分配，交通信号灯，电力传输，天然气运输和油管等系统。安全是非常重要的，因为系统的破坏会产生非常糟糕的后果。

有两个主要的威胁。第一个是未经授权的访问软件，无论是人为访问还是故意引起的更改，病毒感染或其他可能影响控制主机的问题。第二种威胁与主机SCADA设备的网段的数据包接入有关。在许多情况下，实际的分组控制协议的安全性仍然较低或者没有;因此，任何向SCADA设备发送数据包的人都可以控制它。通常，SCADA用户推断VPN具有充分的保护，并且对于与SCADA相关的网络交换机和插座的物理访问提供了绕过控制软件和控制SCADA网络的安全性的能力。

SCADA供应商正在通过为基于TCP / IP的SCADA网络开发专门的工业VPN和防火墙解决方案来解决这些风险。此外，由于能够防止未经授权的应用程序更改，白名单解决方案已经实施。

事物互联（IoT）正在爆发成为主流，即使移动应用程序在企业中的广泛作用也在扩大。但是对移动和物联网安全性的担忧正在迅速发展。

简而言之，挑战在于，在物联网和移动安全方面，目前还没有明确的责任。应用程序由供应商开发和推出市场，很少或没有注意安全。然后，这些应用程序会流入到经常无法管理这些应用程序的组织中，并且确实在很大程度上不确定在其工作场所中使用哪些应用程序。

简而言之，移动和物流安全的问题在更好的情况下可能会变得更糟。

谁负责？

Ponemon研究所最近的一项研究显示，IBM Security和Arxan的挑战面临着企业面临的相关困难。据Infosec岛称，“在开发，测试和实施过程中谁拥有安全性的混乱仍然是有问题的。”

大多数组织（53％）表示担心通过移动设备遭到破坏，而较大多数（58％）表示担心通过IoT应用程序受到威胁。同时，44％的组织承认他们没有采取保护措施，11％的受访者表示不确定是否这样做。怀疑，在这种情况下，不是一个信心建设者。

这种不确定性，特别是在移动端，扩展到组织内正在使用的应用程序数量。全部75％的受访者表示，他们对自己员工使用的应用程式的认识不够自信。其中，占总数的一半或37％，报道“不信任”这一主题。其他调查结果强化了不确定性和被动性的画面。

赶上市场让尘埃的安全

如果对如何处理这些挑战的共识很少，就会有很大的共识。超过三分之二的受访者（69％）表示，移动应用程序的安全性较差，因为开发团队有压力让他们走出门路。四分之三将此称为易受害物质管理应用程序的原因。

安全图像进一步复杂化是谁拥有或者应该拥有IoT和移动安全的不确定性。只有5％的受访者表示认为CISO对物联网安全负有主要责任。相反，大多数受访者指向工程部门或业务部门。

确定IoT安全性的优先级

脱颖而出的两个挑战是移动和物联网市场的分化，以及应用程序开发人员将安全性视为事后考虑的压力。作为良好设计的基本原则，安全需要从一开始就纳入到安全性的开始之中，而不是随之而来。

一个大型，流动和竞争激烈的市场非常擅长创新技术，并将其带给消费者。但是，IoT的安全性和移动安全性正在逐渐消除，只有在安全社区和市场需要采取行动之前才会生成风险才会增长。

物联网（IoT）是一个越来越复杂的生态系统。这是下一波创新，将人性化我们生活中的每一个对象，它是我们使用的每个对象的下一个自动化水平。物联网每天都会将越来越多的事情带入数字折叠，这可能使近海物流在不久的将来成为一个万亿美元的行业。为了了解物联网（IoT）的兴趣规模，只是检查了近期关于物联网的会议，文章和研究的数量，这个兴趣在2016年已经达到发烧点，因为许多公司看到很大的机会，并且认为物联网承诺扩大和改善企业流程，加快增长。然而，物联网市场的快速发展已经引起了物联网解决方案的数量和多样化的爆炸式增长，随着行业的发展，这将带来真正的挑战，主要是迫切需要一个安全的物联网模型来执行常见任务，如传感，处理，存储和通信。通过任何想象力开发模型永远不会是一件容易的任务，真正安全的IoT模型面临着许多障碍和挑战。

IoT有许多观点，从“系统视图”将IoT分为块，即事物，网关，网络服务和云服务，到物联网的“业务视图”包括;平台，连接，业务模型和应用。不管我们如何描述物联网，所有视图中都有一个共同的线索，“安全是至关重要的”。

需要安全性的最重要的例子是2016年10月21日发生的大规模分布式拒绝服务攻击（DDoS）在美国各地破坏Twitter，Netflix和PayPal等流行服务的服务器。这是一个巨大的涉及数百万的互联网地址和恶意软件的攻击。攻击流量的一个来源是由未来的恶意软件感染的IoT设备，这是一个在线可用的简单程序。这次袭击是由于网络安全的担忧增加，互联网安全漏洞的数量不断增加。在这次攻击中，无数的互联网物联网（IoT）设备为诸如闭路摄像机和智能家居设备等日常生活技术劫持恶意软件，并被用于服务器。

安全型物联网模型的挑战

物联网安全面临的最大挑战来自当前物联网生态系统的架构;它都是基于称为服务器/客户端模型的集中式模型。所有设备都通过支持巨大处理和存储容量的云服务器来识别，认证和连接。设备之间的连接必须经过云端，即使它们恰好相隔几英尺。虽然这种模式连接了数十年的计算设备，并将继续支持今天的物联网，但它将无法应对未来巨大的物联网生态系统日益增长的需求。

成本是另一大障碍，特别是在扩大现有物联网解决方案时使用这种集中式模式。与集中式云，大型服务器场和网络设备相关的基础架构和维护成本较高。当物联网设备增长到数百亿美元时，必须处理的大量通信将大大增加这些成本。即使克服非凡的经济和制造挑战，物联网架构的每一个方面将仍然是可能破坏整个网络的瓶颈和故障点。

目前集中式物联网模型的其他问题是：对物联网设备的生命周期维护和管理的指导性有限，此外，物联网隐私问题是复杂的，并不总是很明显。此外，物联网技术的使用正在不断扩大和变化 - 往往在未知的水域。除了上述列表之外，还将需要新的安全技术来保护物联网设备和平台免受物理篡改，并应对新的挑战，例如模拟例如泄漏电池的“事情”或拒绝睡眠攻击。面对物联网新安全技术发展面临的另一个挑战性问题是许多“事情”使用简单的处理器和可能不支持复杂安全方法的操作系统。

区块链模型

区块链是一个保持不断增长的数据记录集的数据库。它分布在大自然中，意味着没有掌握整个链的主计算机。相反，参与节点具有链的副本。它也在不断增长 - 数据记录仅添加到链中。

当有人希望将交易添加到链中时，网络中的所有参与者都将对其进行验证。他们通过对事务应用一个算法来验证其有效性来做到这一点。 “有效”是什么理解由块链系统定义，系统之间可能有所不同。那么大部分参与者都认为交易是有效的。

一组批准的事务然后被捆绑在块中，该块被发送到网络中的所有节点。反过来，他们验证了新的块。每个连续的块包含前一个块的哈希，它是唯一的指纹。

图1块链技术的优点

图1：Blockchain技术的优点/信用

Blockchain的大优势是公开的。参与的每个人都可以看到其中存储的块和事务。然而，这并不意味着每个人都可以看到您的交易的实际内容;这被你的私钥保护。

一个Blockchain是分散的，所以没有一个权限可以批准交易或设置具体规则来接受交易。这意味着，由于网络中的所有参与者都必须达成共识以接受交易，因此涉及巨大的信任。

最重要的是，它是安全的。数据库只能扩展，以前的记录不能被更改（至少如果有人想改变以前的记录，则成本很高）。

区块链在物联网中的优点

图2使用块链的IoT的主要优点

图2：使用Blockchain进行IoT / Credits的主要优点

许多专家认为，Blockchain技术是在物联网中解决安全性，隐私和可靠性问题的缺失环节，也许可能是物联网行业所需要的银弹。它可以用于跟踪数十亿个连接的设备，支持处理事务和设备之间的协调;可以大大节省IoT行业制造商。这种分散的方法将消除单点故障，为设备运行创造更有弹性的生态系统。 Blockchains使用的加密算法会使消费者数据更加私密。

Blockchain中使用的分类帐是防篡改的，不能被恶意演员操纵，因为它不存在于任何一个位置，而中间人的攻击不能上演，因为有任何一个通信线程可以截获Blockchain使得无可比拟的对等消息传递成为可能，并且已经通过诸如Bitcoin这样的加密货币在金融服务世界中证明了它的价值，提供了保证的点对点支付服务，而不需要第三方经纪人，扰乱了我们打电话给FinTech。

Blockchain的分散，自主和无信任的功能使其成为成为IoT解决方案的基础要素的理想组件。企业IoT技术已经迅速成为Blockchain技术的早期采用者之一并不奇怪。

Blockchain可以保持IoT智能设备的历史无可争议的记录。该功能使智能设备自动运行，无需集中授权。因此，Blockchain打开了一系列非常困难的甚至不可能实施的物联网场景。

例如，通过利用Blockchain，IoT解决方案可以实现IoT网络中的设备之间的安全消息传递。在这个模型中，Blockchain将处理类似于比特币网络中的金融交易的设备之间的消息交换。为了实现消息交换，设备将利用聪明的合同，然后建立双方之间的协议。

Blockchain最令人激动的功能之一是能够维护一个正式分散的，信任的分类帐，其中一个网络中发生的所有交易。这种能力对于实现工业IoT（IIoT）应用的许多合规性和监管要求是必不可少的，而不需要依赖集中式模型。

总之，使用Blockchain技术来保护IoT的主要优点可以分为三点：建立信任，降低成本和加速交易。

物联网中块链的挑战

图3 IoT和Blockchain挑战

图3：IoT和Blockchain挑战/积分

尽管它的所有好处，Blockchain模式并没有缺点和缺点：

可扩展性问题;与Blockchain分类帐的大小有关，随着时间的推移，可能会导致集权化，并且需要一些对Blockchain技术的未来造成影响的记录管理。

处理能力和时间：对于涉及到基于块链的物联网生态系统中涉及的所有对象，需要执行加密算法，因为物联网生态系统非常多样化，并且包含具有非常不同计算能力的设备，并不是所有这些都具有以所需的速度运行相同的加密算法。

存储将是一个障碍：Blockchain消除了中央服务器存储事务和设备ID的需要，但分类帐必须存储在节点本身，并且分类帐将随着时间的推移而增加。这超出了诸如具有非常低的存储容量的传感器的各种智能设备的能力。

技能不足：很少有人了解Blockchain技术如何真正有效，当您将IoT添加到组合中时，数字将大幅缩小，创建一个具有挑战性的任务，聘请所需的团队来管理和运行Blockchain项目。

法律和合规问题：在任何方面都是一个新领域，没有任何合法或合规先例，这对于物联网制造商和服务提供商构成严重问题。这个挑战本身就会吓倒许多企业使用Blockchain技术。

最佳安全IoT模型

开发物联网的安全模型需要为每个物联网生态系统进行前所未有的协作，协调和连接。所有设备必须一起工作，与所有其他设备集成;所有设备必须与连接的系统和基础设施进行无缝通信和交互。创建这样的模型是可能的，但它可能是昂贵的，耗时的并且是困难的。

为了实现物联网的最佳安全模型，安全需要作为物联网生态系统的基础内置，具有严格的有效性检查，认证，数据验证，所有数据需要在各个层面进行加密。例如在应用层面，软件开发组织需要更好地编写稳定，有弹性和可信赖的代码，具有卓越的代码开发标准，培训和威胁分析和测试，

没有一个坚实的底层结构，我们将在向物联网添加的每个设备上创造更多的威胁。我们需要的是具有隐私保护的安全和安全的物联网。这是一个艰难的权衡，但并非不可能，如果我们能够克服其缺点，Blockchain技术是一个有吸引力的选择。

参考

http://www.cnbc.com/2016/10/22/ddos-attack-sophisticated-highly-distrib…

http://www.cio.com/article/3027522/internet-of-things/beyond-bitcoin-ca… -power-industrial-iot.html

http://dupress.com/articles/trends-Blockchain -bitcoin-security-transparency/

https://techcrunch.com/2016/06/28/decentralizing-iot-networks-through-B… /

http://www.Blockchain technologies.com/Blockchain -internet-of-things-iot

https://postscapes.com/Blockchain s-and-the-internet-of-things/

https://bdtechtalks.com/2016/06/09/the-benefits-and-challenges-of-using… -in-iot-development/

https://blogs.thomsonreuters.com/answerson/Blockchain -technology/

http://www.i-scoop.eu/internet-of-things/Blockchain -internet-things-big-benefits-expectations-challenges/

https://campustechnology.com/articles/2016/02/25/security-tops-list-of-…

http://dupress.com/

最新的Linux Foundation项目旨在为物联网公司创建一个共同框架，以提高物联网生态系统的互操作性和健康发展.

物联网在工业和企业领域发挥着非常关键的作用。运输公司正在使用它来跟踪集装箱。它被用于大型仓库，以更好地利用空间。它被用于工厂，建筑工地和矿山，以提高工人的安全。有很多用例。

消费者空间也逐渐走向成熟，尽管由于各种原因，主要受到缺乏商业模式的担忧，主要受到安全隐患的困扰。

普遍存在的一个挑战 - 从工业物联网到企业和消费者物联网 - 缺乏任何基于标准的平台或框架。 IoT公司正在做自己的事情，重复努力，编写自己的代码，自己的协议，创建碎片和互操作性挑战，因为他们做到了上述所有。

InfoWorld的Deep Dive技术报告和Computerworld的职业发展趋势报告，为您提供技术职业优势。到2017年1月15日获得15％的折扣：使用代码8TIISZ4Z。 ]

实际上阻碍了物联网的健康成长和采用。

Linux基金会想解决这个问题。 50多家公司在Linux基金会的EdgeX Foundry的旗帜下，共同组建了一个新的合作项目。

就像任何其他Linux Foundation合作项目一样，代工厂的目标是通过将利益相关者融合在一起，简化和标准化工业物联网边缘计算，同时允许每个供应商在共同基础之上创建自己的差异化产品。

Linux基金会IoT高级总监Philip DesAutels在接受采访时告诉我，EdgeX Foundry的核心软件组件是戴尔的项目保险丝，该公司开放采购并捐赠给Linux基金会。

EdgeX Foundry旨在将这些优势带到物联网空间：

终端客户可以快速，轻松地部署IoT Edge解决方案，灵活灵活地适应不断变化的业务需求;

硬件制造商可以通过可互操作的合作伙伴生态系统和更强大的安全性和系统管理来加快扩张速度;

独立软件供应商可以受益于与第三方应用程序和硬件的互操作性，而无需重新创建连接;

传感器/设备制造商可以使用SDK编写具有选定协议的应用级设备驱动程序，并从所有解决方案提供商处获取;

系统集成商可以通过即插即用的成分加上自己的专有发明来更快地上市。

由于EdgeX Foundry的重点是工业IoT：当被问及如何帮助消费者IoT时，他表示消费者与工业IoT之间的界限模糊不清。

Desautels说：“当我们研究消费者空间时，我们会看到独立的产品，其中生成了生态系统。” “Comcast和Verizon出售了一大堆家庭自动化产品。这些产品范围从安全系统，智能门锁，烟雾报警器 - 解决人们真正问题的产品。在这种情况下，消费者空间看起来很像很小的工业或小企业问题。“

物联网实际上超出了我们所能理解的范围。 DesAutels举办了摇滚音乐会和百老汇演出的戏剧式IoT公司，其平台必须近乎实时。一切都必须同步 - 现场表演和音乐。

IoT设备正在为公司节省数百万美元的生产损失。总经理Jason Shepherd表示：“威尔集团是一家拥有150年历史的工业泵制造商，拥有超过15万件现货资产，已转向戴尔技术公司，以数字方式在现场设备设备，从猜测转向了解这些关键资产的服务时间。戴尔IoT解决方案与合作伙伴关系。 “如果泵故障，停机时间可能会迅速超过数百万美元的生产损失，紧急服务事件的成本非常高，一些需要直升机的服务。

DesAutels表示，我们也将看到BYOT（带上自己的东西）在像能源管理系统这样的场景中，人们可以把消费级设备与建筑系统整合在一起，以监测空气质量或者没有的东西。工业和消费者之间将会有很多交叉点。

处理所有这些情况的最佳方式是创建一个通用框架，即EdgeX Foundry。

然而，面向用户的设备不是IoT的唯一方程，它其实只是冰山一角，真正的冰山是后端，数据中心，为这些设备运行的云。

这就是为什么平台即服务项目像Cloud Foundry也是EdgeX Foundry的一部分。

面向IoT设备的用户位于网络边缘，这使得事情变得复杂。您可以在云端运行大量分析，同时需要较小的分析权，因为您不希望将数据发送到云端，您只需向云端发送一些更高级别的信息即可处理。

牧羊人给了这样的用例的一个很好的例子，“堰连接未连接到边缘网关，并使用传感器数据的边缘分析来预测何时会发生泵故障。核心和云中的分析使他们的客户能够查看运营趋势在所有资产的同时，如果他们愿意保留数据，最后，威尔正在使用所有这些新数据来优化产品开发决策并更有效地进行竞争。

“Cloud Foundry是标准化基础架构，其云计算的标准化模型和Edge计算的标准化模型中的EdgeX代工厂之间的真正赞誉，然后您在中间有那么一点灰色的地方，超过这个边缘，渗透屏障，“DesAautels说。

EdgeX Foundry的目标并不是停止在创建这个框架，它超越了这一点。铸造厂将关注的另外两个关键领域是认证和合规性。 “一旦您首次发布了EdgeX代工厂，这个核心框架，您如何开始认证与兼容性兼容？

Linux基金会是许多物联网/云计算项目的所在地，包括Cloud Foundry。作为同一组织的一部分，不仅允许这些项目在更深层次上相互合作，还允许这些项目利用在其他领域（包括合规性，认证和教育课程）不断增长的专业知识。

该项目将以典型的Linux基金会的方式管理：将有一个技术指导委员会来驱动代码并提供项目的技术指导，然后将有一个理事会来推动业务决策，营销和确保技术社区和成员。

在开创性的开发过程中，Linux基金会和另外50家公司宣布推出开源物联网（IoT）互操作性框架，通过新的开源联盟EdgeX Foundry对边缘计算进行标准化和简化。由于缺乏合规性和零碎的边缘计算开发导致应用程序和安全保留的不兼容性，IoT尚未获得预期的正面市场增长。将IoT技术应用于业务需求由于单独的开发和不协调的系统而面临着困难和整合问题。然而，边缘计算的演进提供了一个标准化的框架，用于集成重要增值或独立系统的业务应用程序。

随着这个开源框架即将到来，企业可以更好地分配资源，而不是浪费时间为其所需的应用程序开发边缘解决方案，有机会为已经开发的界面定制和添加功能。

透过现象

没有一个共同的框架，物联网市场的发展一直呆滞，其潜力尚未得到实现。目前范式的复杂性目前正在扼杀进步，但是EdgeX似乎提供了一个解决方案。该技术提供了一个平台，使消费者能够快速创建IoT Edge解决方案，而不是从头开始构建集成，而开放源代码允许用户将IoT应用程序适应不同的商业需求。

EdgeX Foundry尝试提供可互操作的组件具有即插即用功能，有望改变IoT游戏的面貌。结果将是一个简单的互操作性框架，支持任何硬件和应用程序，促进设备，应用程序和服务器之间的连接。

Linux基金会IoT高级总监Philip DesAutels指出，EdgeX旨在通过即插即用功能来促进互操作组件的生态系统。这将允许开发人员更好地分配资源来驱动业务价值，而不是集成IoT组件。

最终用户的优势包括灵活性和部署速度，可以适应业务需求的变化。从安全角度来看，开放源码软件本质上是游戏领域的水平，提供了开发更强大的安全系统的机会，而不是数百个分散的附加组件和修补程序。

螺母和螺栓

到2020年，预计有204亿个连接的“事情”，潜在网络流量的巨大数量正在推动边缘计算的转变。这不需要设备连接到云或中央数据中心，而是通过本地网关设备，允许更快的数据分析和降低网络压力。工业IoT技术的应用包括瞬时决策至关重要的应用。对于Opto 22，EdgeX铸造厂的创始成员之一，向边缘计算的转变是促进工业自动化和过程控制以及加速物联网工业应用进步的战略性投资。

戴尔的FUSE已经使用Apache 2.0奠定了基础。该代码提供了一个层，可以有效提供传感器网络，云端和服务器之间的集成接口。这种堆叠方式的优点是易于集成，并且可以在任何系统和所需的增值之间实现互操作。可以轻松集成第三方应用程序，无需重新设计连接。

未来的开源互操作性

IoT具有无可辩驳的潜力，通过自动化和分析提高效率和收入来提升业务价值。 这引起了这个系统是否能够保护其能够收集的数据的问题，例如企业家签证的申请。 而在那里就是磨擦。 IoT能力正在变得可承受，更快，更可用。 任何可以连接到互联网的东西都将需要一个减少歧义的框架，加快上市时间并促进规模化。 所有这些都属于EdgeX Foundry的保证。

EdgeX给桌面带来了相当大的态度，如果能够实现，它将开辟许多途径。 为供应商和消费者提供一个稳定，一致和安全的平台，当涉及边缘计算和调整物联网采用和业务目标时，EdgeX是正确方向的一步。

自从互联网以来，行业专家一直在谈论物联网。但是，从那时起，我们已经花了将近20年的时间才能开始谈论真正的解决方案和实际价值。挑战的一部分是在技术方面，只是弄清楚移动和互联网连接的设备和大数据。其中一部分已经成熟，到那里有足够的物联网设备，人们可以开始在一个显示技术真正能力的规模上进行实验。

零售不能免于这些演变。从2003年沃尔玛设想不明的RFID授权，到早期谈到店内制冷机组报警器，用于主动维护或与草莓混合使用的温度传感器时，有一些适用于零售业的物联网用例。然而，从沃尔玛的任务开始将近15年，在这里，我们几乎没有取得任何进展。

那么现在我们可以在零售店谈谈物联网有什么变化，并且断言这不仅仅是一个管道梦想？首先，零售商的焦点在过去15年中发生了重大变化。在物联网早期使用案例侧重于供应链和运营效率的情况下，零售商现在似乎侧重于全渠道和客户体验。不要误会，他们仍然希望库存可见性和准确性，而且他们仍然希望使商店成为消费者购物的有效场所，但他们也希望物联网提供与商店中的消费者进行数字交互的方式，而他们想要这些其他东西，以便他们可以更好地连接商店到在线体验 - 通过向在线购物者提供商店库存。换句话说，他们希望IoT今天不是为了提高运营效率，而是为了实现客户服务。

但即使零售商表示，他们非常看好物联网机会来帮助他们实现这些目标，他们也报告说，他们在实施物联网方面并没有取得很大进展。主要原因是因为IT：对于零售商如何为技术进行大笔投资而设计的太多的不确定性，以及目前用于支持物联网产生的数据量的现有基础设施太少。这些问题在15年前就存在，虽然零售商还没有为克服这些挑战而投资并不惊讶，但事态也在变化。十五年前，零售商不得不将自己的解决方案与相对较大，稳定的技术公司提供的技术结合在一起，以及最佳实验的创新解决方案，如果几乎不超过研究生论文中的一些算法。

云计算，边缘处理网络，大数据分析，甚至人造智能都为物联网增加了新的维度，使梦想远远超过15年前的解决方案。而像英特尔，IBM，SAP，微软，SAS和软件公司等最大的供应商已经组建了合作伙伴和平台，使投资于实际的“物联网解决方案”今天更加现实。

然而，即使是零售业的一切，仍然存在教育执行团队可能的问题。在研究中分享其物联网目标的许多零售商也表示，他们正在探索物联网可以为其业务做些什么。很明显，“IoT”真的意味着什么呢 - 在我们的调查中，86％的受访者将消费者的智能手机识别为物联网，而只有43％的人认为信标应该归类为物联网。

也就是说，零售商对物联网的看法似乎在今天融合在五个主要用途上。他们仍然没有投入大量的这些真正的，但更多的是试验其中的一些，而不是我们以前看到的，这很重要：你不能学习，如果你不在学习曲线。

全渠道实现

在许多方面，全方位的实现是一个旧故事 - 和RFID故事。而且肯定有很多零售商试用RFID或将其推出，而不是提供供应链的效率，而是跟踪店内的库存。而在这里忙碌的大多数公司都是服装公司，RFID似乎可以兼容技术。这些也不是巧合，这些公司也正在全力推动实施店内库存的在线可见性并从商店出货。他们需要最准确的店内库存视图，如果他们想要向存货外的订单承诺库存，他们可以获得。

接触消费者设备

在2016年初，信标将成为店内购物体验的英雄，现在他们似乎已经变为零。 有很多原因，但我认为一个大的来自零售商滥用信标。 每一种新技术，零售商首先要做的就是尝试通过它来发送促销活动。 消费者在零售商的一些新的迭代中收到非个人化的垃圾邮件后，马上试图阻止它。 因此，可能潜在地被用于更多的技术 - 而且促销活动可能是最不重要的用途 - 被委托给店内技术的垃圾箱，而不是因为它不起作用，而是因为零售商没有 不要使用它可能实际上是有益的。

也就是说，需要接触消费者，并通过最简单的渠道在商店中使用手机 - 他们的手机 - 并没有减少任何费用。事实上，在商店中吸引消费者可能变得更加重要，并且想出如何将这种覆盖范围扩展到消费者的手机上。作为将购物者的数字生活与商店中的物理位置（或产品）相连接的机制，IoT将在这种互动中发挥一定的作用 - 这太容易忽视了。无论我们在谈论NFC，信标，QR码或消费者触发手机的AR提示，零售商都会想出一些将消费者，商店和手机连接在一起的方式。如果零售商可以通过促销来控制他们对垃圾消费者的冲动，那么他们实际上可以成功地使用IoT来创建一个从事店内体验。

员工为物联网

虽然零售商可能专注于跟踪商店中的客户，但实际上有一个有趣的用例来跟踪商店中的资产。雇员是商店中最重要的资产，零售商正在越来越多地探索使用案例，这些用例涉及允许客户在应用程序中按下按钮来召集商店中的帮助，而不是在商店某处找到一个呼叫站。消费者将乐意放弃店铺的位置，跟踪员工是否帮助零售商了解使用情况 - 员工真正花费多少时间来帮助客户在商店中进行运营任务呢？

员工不是唯一的资产 - 购物车通常可以用于商店中客户位置的代理，帮助零售商以不亲自识别客户的方式了解人行道追踪。只要小心你所测量的，但是在00年的一个购物车研究方法中得出结论，消费者并没有真正走在杂货店的中心商店，因为RFID跟踪的购物车最终停在了通道但事实证明，杂货店在过道处暂停展示了许多临时显示器，消费者将车停放在两端，没有他们走过。

个性化和本地化

IoT不是个性化的最重要的使能技术，但它是整个平台的重要组成部分。这是灯塔故事 - 如果在正确的时间和正确的情况下，它不会让它成为正确的购物者，世界上最具个性化的产品就是无用的。对于购物者和零售商而言，移动电话越来越多的选择格式。但它不一定只是提供这个的信标。零售商也正在探索涉及QR码或NFC的用例，消费者通过活跃的选择激活或触发不是通过邻近的提议。移动应用程序在这里仍然很重要，因为通过正确的选择加入，按位置触发的推送通知可以实现所有相同的目的，而不需要单个信标。

生态系统机会

越来越多的电子产品，家居用品和一般商品零售商正在商店中建立智能家居或家庭自动化部门 - 因为企业不是唯一需要实施物联网的公司。零售商有机会在生态系统中担任销售支持，服务支持，甚至是在消费者家庭中由IoT传感器生成的自动化订单的接收端。亚马逊已经努力成为您可能会要求Alexa所做的任何事情的选择方式，该公司正在向可以将其扩展到可能创建的智能设备或服务的开发人员开放平台。我不认为Kroger会很高兴将智能冰箱自动重新排序到Alexa，只是因为它是默认的语音订购功能...

底线

有很多业务需求驱使零售商对物联网的兴趣，现在有几个用例可以带动价值 - 如果零售商可以克服内部IT挑战。供应商正在加紧平台，零售商热衷于机会，但在物联网零售业仍然存在漫长的道路，无处不在。

Nikki Baird是零售系统研究（Retail Systems Research）的管理合伙人，零售系统研究是一家专注于零售趋势的市场情报公司。

伦敦，2017年5月03日（美通社通过COMTEX的欧洲通讯社） - 窄带IoT技术的商业化正在扩大增长机会，发现Frost＆Sullivan的数字转型团队

2017年5月3日电伦敦新加坡/ - 由物联网（IoT）市场增长，随着发射，投资和合作伙伴关系的增长，2017年将随着窄带IoT（NB-IoT）的商业化而加速发展。这种蜂窝通信技术使用许可频谱，并提供标准化的低功率，广域网（LPWAN），可以捕获以前未开发的市场部分。此外，机器学习和块链技术正在与不同的行业（如金融服务和能源）相结合。在欧洲，到2021年，物联网的关系将达到90亿以上。专门用于物联网发展的风险基金将有助于创造一个有利于该地区创业公司发展的生态系统。

数字转型研究分析师Yiru Zhong表示：“IoT应用将消费者整合到更广泛的连接系统中，以反映真正的智慧社会。 “过去18个月的大量资金表明，物联网市场准备再次转变，下一个演变将是使用数据对事件作出反应，使用有用工具和认知或”预测计算“，因此IoT 2.0将最终使自我连接系统中的“紧急事件”。

欧洲物联网市场展望，2017年，来自Frost＆Sullivan的互联行业的新研究[http://ww2.frost.com/research/industry/information-communications-techn…，应用和关键市场参与者以及预测开发领域。该研究考察了企业对物联网采用的态度，并为2017年及以后的物联网提供了八个市场预测。

物联网的五个新兴增长领域是：

钟骏表示：“2016年第三季度，大型行业参与者纷纷涌现，共同推动物联网生态系统建立伙伴关系。” “消费者对ITA的采用需要有形的产品和优势展示，Avanci [http://avanci.com/]，Chronicled [https://chronicled.com/]和苏黎世保险[https://www.zurich.com/ ]出现了对IoT开发至关重要的新命题; Vodafone [http://www.vodafone.com/content/index.html]和Cocoon [https://cocoon.life/]带领了概念和保险的证明分手。

 

在Link Labs，我们帮助了数十家大小企业创建，推出和扩展其物联网产品。这包括安全关键系统，如Stanley，Black和Decker的Shelter Lock控制系统和大型分布式智能仪表系统。

以下是几个重要的经验教训，对于刚开始创建IoT产品的团队，团队可能并不那么明显。

1.不要优化原型中的成本，尽可能快地构建。

成本是几乎所有物联网项目中非常重要的一员。关于物联网产品的商业案例通常取决于系统总成本的增加所产生的增量收入或成本节约。

然而，优化硬件和连接成本是一项艰巨而耗时的工作。团队往往被管理层迫切地来到桌面（有时早在思想阶段），其成本受到高度限制的解决方案。

一个更好的方法是建立“最小可行”原型，以帮助解决商业案例，并花时间建立路线图来降低成本。

一旦真正的物联网产品在客户和销售团队面前，就会发生大量的学习。这种反馈在形成释放产品方面将是非常宝贵的。您所做的任何延迟或复杂化的反馈周期将会减慢产品上市。

2.没有IoT平台将完全适用于您的应用程序。

IoT平台通常解决一个问题，如摄取数据，转换它，存储它等。如果您的产品是如此常见或通用，即可使用现成的应用程序堆栈，这可能不是一个大的成功无论如何。

正如我们在第1课中分享的那样，创建一些基本和简单的应用程序，从那里开始构建。您可能会考虑以下几个因素：供应，黑名单，警报，仪表板等，这些因素将在您开发原型时出现。

有人将不得不写“真正的软件”来添加您正在寻找的应用程序逻辑，花费在寻找完美平台的时间可能会被浪费。您选择的开发团队可能会拥有自己的强烈偏好。也就是说，有一些良好的设计标准来考虑可扩展性和可扩展性。

3.把电子放在盒子里比你想象的更加昂贵和昂贵。

工业设计，可制造性设计和测试设计是整个学科。对于企业和消费者实体产品，电子产品的外壳在产品的感知方面起着重要的作用。如果你离开工业设计直到项目结束，它将显示。虽然我们不建议等待，直到你有一个注塑美容准备好进入原型阶段，不要拖延让你的团队的一部分平方米。

另外，像UL和FCC这样的认证可以在游戏的后期创造出心痛，如果你不小心。确保与一个了解规则的团队合作，以便合规测试只是一个检查框，而不是在第11个小时的昂贵的惊喜。

4.不，你不能使用WiFi。

许多客户开始假设他们可以使用企业内部的WiFi网络或工业设置来回传其物联网数据。再想一想。出于安全考虑，大多数IT团队都有一个零容忍策略的IoT设备连接到他们的基础架构。如果这还不够糟糕，只需在网络上设置设备是一个真正的挑战。

相反，请查看低成本蜂窝电话，例如像Symphony Link这样的LTE-M1或LPWA技术，可以以非常低的成本连接到电池供电的设备。

5.不要以为您的内部工程团队最了解。

对于一些团队来说，这可能是一个艰难的任务，但是我们发现，即使是大型上市公司的OEM也没有一个经验丰富的跨职能团队，涵盖了每个物联网学科，并准备好新的产品或解决方案的创新。

要小心，您的团队不会总是知道解决技术问题的最佳方法。你最了解的一件事是你的业务和你如何去市场。在物联网方面比许多团队意识到更重要。

机器逐渐变得与人类一样聪明。这可以通过以下事实来证明：在当前时间可能知道您的货物如何向目的地移动，或ATM机是否需要重新充值，或者在家里的RO系统需要维修或以什么样的速度消耗不同类型每天在地球上的能量。

近来，我们看到数字空间发生了重大转变，在现场也将不断发展。物联网（IoT）也许是数字空间的最新进入者。机器对机器（M2M）技术使得有线和无线系统可以进行交互，而不需要任何手动参与。

物联网（IoT）是具有标识符的嵌入式对象/设备的无缝连接网络，其中使用标准和可互操作的通信协议可以进行M2M通信，无需任何人为干预。

随着物联网的出现，连接的传感器的数量将会达到数万亿，与数十亿智能系统的无缝应用相结合将带动新的消费者和商业行为。印度政府正在以印度的数字印度计划为重点。数字印度计划旨在“将印度转化为数字授权社会和知识经济”是其中一个最大的举措之一，它将为发展该国的物联网产业生态系统提供必要的动力。

其他方面，物联网可以通过远程连接的设备，帮助自动化解决诸如农业，卫生服务，能源，安全和灾害管理等各个行业面临的各种问题的解决方案。 IoT为电信运营商和系统集成商提供了显着提升收入的渠道，从而引领了其采用该技术提供的物联网应用和服务。除了直接的物联网应用外，IT行业还有机会提供与物联网相关的服务，分析和应用。

物联网涉及三个不同的阶段：

收集数据的传感器（包括识别和寻址传感器/设备）。

收集和分析此数据以进一步整合的应用程序。

决策和数据传输到决策服务器。

分析引擎和大数据可用于决策过程。像美国，韩国，中国等几个国家已经率先为了利用物联网做好准备。

根据估计，预计印度物联网行业将达到150亿美元，到2020年将280亿台设备连接到互联网。印度的无线网络正在发展的跨越式发展。因此，关于机器到机器的沟通的争论正在加快。今天，当连接比以往任何时候都更强大，我们将电脑并入我们的日常生活中时，物联网生态系统就进入了对话。

每个网关都可以配备通信传感器，并配备Wi-Fi，ZigBee，3G和蓝牙等网络选项。许多网关都配有智能平台管理界面（IPMI），使得设备的远程管理和维护变得更加容易。

鉴于物联网的潜力，印度政府也将重点放在该地区。作为数字印度计划启动的一部分，总理纳伦德拉·莫迪（Narendra Modi）最近宣布在班加罗尔推出关于物联网的卓越中心（CoE），以便能够快速采用物联网技术，并促进新的增长战略。

由国家软件和服务公司协会（Nasscom），电子与信息技术部（DEITY）和教育与研究网络（ERNET）组成的合资企业，该公司将由公共私营合伙公司（PPP）模型。

政府计划利用物联网解决运输系统，停车，电力，废物管理，水管理和妇女安全等问题，创造智能城市的潜力。也意识到物联网可以通过远程连接的设备，帮助自动化解决农业，卫生服务，能源，安全和灾害管理等各个行业面临的各种问题。

根据政府“2015年物联网政策草案”，2011年互联网设备（125亿）的数量超过了全球人口（70亿），到2020年互联网设备预计将达到全球数量在260亿到500亿之间。因此，通过适当的推广和支持机制，利用印度作为全球服务业领导者的实力，制定了物联网政策草案，在全国建立了物联网生态系统。

什么是云？

一个简短的历史

早在上个世纪七十年代，企业用大型主机计算机系统租用时间很受欢迎。这些系统是非常大的和昂贵的，所以对于企业本身拥有计算能力来说，经济上没有意义。相反，它们由大公司，政府机构和大学所有。

微处理器技术允许大幅减少尺寸和费用，导致个人电脑的出现，这在20世纪80年代爆炸式增长。突然间，企业可能（并且已经）在内部带来计算。

然而，随着高速连接的普及，趋势已经逆转：企业再次从其他组织租用计算能力。但是为什么呢？

而不是在内部购买昂贵的硬件进行存储和处理，因此在云中便宜地租用它。云是一个巨大的互联网络，强大的服务器，为企业和人员提供服务。

今天

最大的云提供商是亚马逊，谷歌和微软，他们拥有庞大的服务器场，他们作为云服务的一部分租给企业。

对于具有可变需求的企业（大多数时候他们不需要太多的计算机，但是现在他们需要很多时间），这是成本有效的，因为他们可以根据需要付钱。

当涉及到人们时，我们一直使用这些云服务。您可以将文件存储在Google云端硬盘而不是您的个人计算机上。 Google云端硬盘当然是使用Google的云端服务。

或者您可以在Spotify上收听歌曲，而不是将歌曲下载到您的电脑或手机。了解亚马逊云服务的使用情况。

通常情况下，在“云端”中发生的任何活动都是通过互联网连接而不是设备本身发生的。

物联网和云

由于像云存储和数据处理这样的活动，而不是在设备本身，这对物联网有重大的影响。

许多物联网系统利用大量的传感器来收集数据，然后做出智能决策（想知道物联网系统如何实际运作？）。

使用云对于从数据中聚合数据和绘制洞察力很重要。例如，一个聪明的农业公司将能够在种植相同种子后比较堪萨斯州和科罗拉多州的土壤水分传感器。没有云，比较更广泛地区的数据要困难得多。

使用云还可以实现高可扩展性。当您有数百万，甚至数百万传感器，每个传感器上投入大量的计算能力将是非常昂贵和耗能的。相反，数据可以从所有这些传感器传递到云，并在那里进行处理。

对于大多数物联网，系统的头（或大脑）在云中。传感器和设备收集数据并执行操作，但是处理/命令/分析（也称为“智能”）通常发生在云端。

物联网所需的云也是如此吗？

技术上，答案是否定的。数据处理和命令可以在本地进行，而不是通过互联网连接在云端。这被称为“雾计算”或“边缘计算”，这对于一些IoT应用程序来说实际上是很有意义的。

然而，对于许多IoT应用程序，使用云可以获得实质的好处。选择不使用云将由于成本的增加而大大减慢了行业。

重要的是，成本和可扩展性不是唯一的因素。这给我们带来了一个更加困难的问题

云是否适合IoT？

到目前为止，我们只讨论了使用云作为物联网的好处。我们先来简要地总结一下他们之前的探讨：

• 成本下降，包括前期和基础设施

• 存储/计算的按需支付

• 高系统可扩展性和可用性

• 提高电池供电传感器/设备的使用寿命

• 能够聚合大量数据

• 任何具有互联网连接的东西都可以变成“聪明”

然而，云使用有合理的担忧：

• 数据所有权。当您将数据存储在公司的云服务中时，您是否拥有数据或云提供商？这对涉及私人数据（如医疗保健或智能家居）的物联网应用来说可能非常重要。

• 潜在的崩溃。如果连接中断或云服务本身崩溃，则IoT应用程序将无法正常工作。短期的无操作性可能对某些物联网应用来说可能不是很大的事情，比如智能农业，但对别人来说可能是毁灭性的。您不希望涉及健康或安全的应用程序几秒钟就会崩溃，更不用说几个小时了。

• 延迟。将数据发送到云并需要返回设备的时间。在某些IoT应用中，这些毫秒可能是重要的，例如健康和安全。自主车辆的一个很好的例子。如果碰撞即将来临，您不必等待汽车与云端通话，然后再作出决定。

所以当我们询问云是否适用于物联网：这取决于。

物联网是一个广泛的领域，包括令人难以置信的各种应用。没有一个适合所有的解决方案，所以IoT公司在决定云是否有意义时需要考虑其具体应用。这实际上是我的Leverege公司存在的原因之一，帮助那些想要建立一个物联网系统的企业贯穿整个过程。

数据科学是对大数据或物联网（IoT）环境进行的任何分析练习的核心。数据科学涉及广泛的技术，业务和机器学习算法。数据科学的目的不仅是做机器学习或统计分析，而且还可以从没有统计知识的用户理解的数据中得出洞察。

在诸如大数据和物联网等快节奏的环境中，数据类型可能随时间而变化，变得难以每次都维护和重新建立模型。这个差距需要一种自动化的方式来管理这些环境中的数据科学算法。数据科学的兴起旨在将我们从基于规则的系统转移到机器自身学习规则的系统中。机器学习使数据科学固有地部分自动化。需要手动干预的数据科学的一半仍然是自动化的。然而，这些领域涉及到人们的经验和智慧：数据科学家，商业专家，软件开发人员，数据集成商，目前有助于使数据科学项目运作的人。这使得数据科学的各个方面都难以实现自动化。但是，我们可以将数据科学自动化视为两级架构，其中：

- 不同的数据科学学科/组件是自动化的

- 所有单独的自动化组件都是互连的，以形成一个连贯的数据科学系统

我们可以将数据科学系统视为自动化，只要它们足够能够在我们抛出数据集时解决我们的问题。此外，应该足够聪明地向我们提供我们可以理解的语言中的所有可能的解决方案。

数据准备，机器学习，领域知识和结果解释是成功执行数据科学项目所需的四个主要任务。所有这些任务都必须转换为自动化模块，以创建一个自动化的数据科学系统（图1）。

数据准备自动化

数据准备是每次创建模型时必须完成的重复任务。数据提取，数据清理和数据转换（例如估算空值和算法特定转换）是属于此类别的一些任务。许多组织将这些任务自动化，并将引擎标记为数据科学自动化工具。但是，大多数这些工具使用基于规则的逻辑来自动执行数据预处理任务。这是正确的做法吗？我们是否需要基于规则的系统来自动化数据科学，这是终止基于规则的系统诞生的？不，我们需要通过机器学习自动进行数据预处理。例如，关于什么预处理功能必须应用于问题的数据的决定是由机器本身做出的。

特征工程是需要自动化的另一个数据准备领域。特征工程是将原始数据转换为属性/预测变量的技术，可提高机器学习项目的准确性。特征工程自动化仍处于初级阶段，也是一个积极的研究领域。麻省理工学院的数据科学家正在开发一种能够从原始数据生成特征的“深度特征综合”算法取得了令人难以置信的进步。

自动机器学习/统计

这是统计程序自动化的数据科学自动化领域。系统根据提供的数据集执行最佳算法。它隐藏了用户的复杂性和算法的数学复杂性，使其向群众提供。用户需要向自动统计学家提供数据。它了解数据，创建不同的数学模型，并根据最能说明数据的模型返回结果。自动统计学家是一个复杂的科学，因为它需要系统学习输入数据模式，找到最佳拟合值，并使用几种统计和机器学习算法自我优化其参数。这需要各种算法约束的推广和巨大的计算能力。

通过利用基于云的服务器来管理高计算能力的需求，自动机器学习逐渐成熟。创建数据产品的组织逐渐包括诸如元学习的功能，基于数据集的元数据自动选择合适的机器学习算法的过程。像H2O.ai这样的组织通过引入几个内置功能来推广模型构建过程，并提供了许多模型调整选项，可以更好地控制算法。此外，他们已经将超参数调优作为几乎所有算法的特征，使数据科学家免于使用不同参数测试模型的繁琐过程。超参数调整是使机器学习模型重新运行多次的自动化尝试和错误的过程，以确定数据集上的模型的适当参数。

洞察产生自动化

数据科学项目的结果直到和除非业务用户或没有统计知识的观众理解它才有用。数据科学活动的奶油是讲故事的部分，数据科学家以全面透明的方式向人们解释结果。自动化此任务需要从统计学家友好的结果自动生成用户友好的文本。自然语言生成（NLG）是当前的前沿框架，可以帮助将语言翻译成自然语言。 Nlgserv和simplenlg是我们可以用于此任务的两个NLG框架。此外，我们可以使用马尔科夫链自动生成句子和制作故事。

数据科学自动化的创新已经开始，并将在未来几年逐渐演变。我们目前正处于一个阶段，我们已经开始处理个别数据科学模块的自动化。从这里，我们需要转移到更通用的数据科学平台，所有模块都自动化并集成在一起。这是一个变化的开始，就像房间大小的计算机被转换为信用卡大小的计算机一样。

权力下放问题

在企业环境中，信息技术（IT）解决方案和服务的买家已经很成熟，已知。但是当谈到物联网解决方案时，实际上购买的是谁，而且如何出售IoT也不甚清楚。

这些新的解决方案属于IT，业务部门，运营和服务集团之间的“无人地带”。与集中的IT采购模式不同，物联网解决方案的采购在很大程度上是分散化的，而采购商居住在几个内部组织之一。

这是因为物联网对于组织的许多部分通常是有价值的。

如果您为工业级洗衣机制造商提供遥感和监测解决方案，收集的数据对售后单位，产品设计单位和销售和营销单位来说是有价值的。

售后部门将使用数据来确定何时需要服务，并发现早期的麻烦迹象。产品设计单位将使用数据来改进下一个模型。销售和营销部门将使用这些数据来了解客户使用最多的功能，从而使他们开发更有效的信息。

那么谁实际购买了IoT解决方案呢？

绝大多数公司没有一个集中的组织，例如物联网办公室，为这些解决方案做出购买决定。

买方可能是一家制造商，产品设计集团与另一家制造商的传统IT组织，以及另一家制造商的售后服务机构。由于缺乏集中采购组织，解决方案供应商难以找到“正确”的买家，并减慢销售过程。

IT和IoT处理不同的组织域

为了了解为什么IoT采购是分散的，考虑一个企业的价值链（图1）。小型或大型公司进行一系列为客户创造价值的活动（例如，生产客户购买的产品或服务）。

主要活动是直接参与创建和交付产品或服务的功能。这些功能包括采购原材料，将其转化为成品或服务，分销这些商品，销售和营销，并支持这些商品的售后服务。

支持活动并不直接参与到初级价值创造活动中，而是支持组织和职能。其中包括IT，财务，人力资源，法律和采购。

IoT解决方案直接涉及主要活动。

在上述的遥感解决方案示例中，制造商的售后团队使用数据来检测早期的故障迹象。然后，它主动地订购替换零件并安排与客户进行现场服务呼叫，以在洗衣机故障之前解决问题。

预测和主动维护的这一步直接为客户创造价值。相比之下，IT可以维护存储客户数据的数据库，或构建允许数据与备件订单管理系统和服务约会预约系统连接的集成。

尽管IoT解决方案具有网络性，但IoT并不是IT。

IoT更像是工业技术，或者是操作技术而不是信息技术。正是由于这个原因，物联网占据与IT不同的领域，为什么物联网购买流程是分散的。

物联网和IT必须协调和协调

在今天的公司中，IoT是由三个不同组织 - IT，业务部门以及运营，制造，营销和工程（图2）等主要的价值创造功能的合作。主要买家将来自其中一个组织。

为了实际购买，这些组织必须在角色和责任之间进行协调，预算分配和转移以及资源分配。其中一些谈判和规划可能发生在一个结构化的论坛，例如在月度业务部门 - IT协调委员会或指导委员会。

由于物联网的管理和采购在当今大多数公司中都是分散化的，所以这种合作购买流程是司空见惯的。虽然这增加了复杂性并减慢了采用过程，但它也将IoT的价值暴露给了更多的受众，引发了整个公司的兴趣，并促进了未来的购买努力。

如何出售IoT - 6个IoT供应商的最佳实践

1.了解您的解决方案适合企业价值链。

无论您是销售内部部署还是基于SaaS的IoT解决方案，都可以确定IT和IoT在特定IoT解决方案的背景下的适合性。这将帮助您了解主要买家以及二手买家以及IT和各种业务功能的作用。

2.聘请企业数字，转型创新办事处。

在分散的物联网解决方案的采购环境中，这些办事处（如果存在）对许多跨功能创新计划（通常涉及与您的IoT解决方案相关的相同功能组织）的可见性和影响力。他们会为您节省大量时间，并指出正确的方向。

3.接触您的解决方案所触及的每一个功能。

这些组织中的每一个都是您的解决方案的潜在买家（主要和次要）。在分散的购买环境中，他们必须相互合作来汇集其预算和资源。您需要确保所有这些组织了解并支持您的解决方案。

4.连接买家的点。

您的解决方案位于IT，业务部门和各种操作功能之间。您的买家将无法获得部署解决方案的支持和资源。帮助您的买方计划内部协作会议。确定其他团队需要什么资源，支持和预算。酌情提供接口，样品协议，角色和可交付成果的列表。

5.围绕分散采购流程制定销售追求计划。

这是一个更复杂的销售参与，需要与多个组织进行互动。围绕更长的销售周期构建和规划您的资源和支持。

6.如果您是创业公司，请帮助您的买家了解如何从您那里购买。

从初创公司购买IoT解决方案时，使用传统的企业采购流程是无效的，只会增加买方的风险。帮助您的潜在客户在从初创公司购买解决方案时开发新的采购实践

现场服务行业巨大，包括遍布世界各地的2000多万辆面包车的现场技术人员，从医院设备到办公电梯，重型制造机械，风力发电机组等各个领域都有很多的效率。

在这个规模上，对诸如进行维修所花费的时间等变量的微小调整可能会产生巨大的后果，而IoT技术 - 传感器和实时监控 - 可以给出应该调整的重要线索。

ServiceMax是现场服务管理（FSM）的市场领导者，每天都会通过客户的异地或移动机械设备来解决数千个问题。

一年前，它与PTC合作启动了物联网（IoT）驱动的云服务管理平台。通过这个平台，作为连接式现场服务（CFS）销售，公司能够跨越“预测性维护” - 在发生问题之前解决问题。

那么在推出这项技术之后，一年中看到什么样的结果呢？根据ServiceMax创始人和CSO Athani Krishna的说法，这是非常令人鼓舞的。

“在许多情况下，我们仍然看到飞行员和实验，但有些公司正在超越这些，”他告诉我。

预测性维护

医疗设备制造商Medivators是一个这样的成功故事。通过在国际业务中实施CFS，公司已经看到可以远程诊断和纠正的服务事件数量增加了78％，无需派遣现场技术人员。

存在Shutterstock

克里希纳说：“现在，他们有可能发生的事情，他们能够更好地远程诊断问题，并发送一个软件补丁或修复程序，而不必推出一个卡车来解决它。

事实上，根据ServiceMax的第一年业绩报告，客户在生产率，效率，增长，收入，客户体验和合规性转变为连接策略之后已经报告了收益。

迈向预测或主动维护和服务范式的潜力是现代分析和数据捕获技术对制造和维修行业最诱人的承诺之一。

并不是每个组织都可以准备好立即跳跃 - 从头开始，彻底了解数据如何影响业务，这是必须的 - 但是逐步采取小步骤来改进措施往往是构建连接策略的有用策略克里希纳说，一旦这样做，那么像预测维护这样的想法成为一种可行的可能性。

“在许多情况下，如果你看服务行业的状况，有很多”滞后者“。

“如果不是数百名技术人员，那么你们还是有几十家公司，而且这个组织本来就是用笔，纸和传真来运行的。

“从这里跳跃到连接的战略是一个巨大的飞跃 - 所以企业需要多个镜头才能进入一个现代化的集中式平台，您可以自动化工作流程并以数字方式捕获所有信息。

通过更快的报告来提高现金流

医务人员的另一个效率是减少技术人员在事件发生后大约两周到两天的时间。

这是一个有价值的指标，因为它大大减少了客户之间的延迟 - 在Medivators案例中，使用其设备的医疗保健提供者可以为服务事件付费。

克里希纳说：“最终目标是在24小时内向客户提供账单，这将真正改善现金收购。”

最近注册使用ServiceMax技术的另一个客户是Jones和Frank，美国最大的加油泵和设备的安装和维修人员。它希望基于云的移动分析和管理系统能够在以前受依赖旧系统和孤立数据阻碍的领域中提高效率。

也希望运行CFS或类似技术的现场服务机构最终能够为关键任务环境中的机器和设备提供100％的正常运行时间保证 - 当然是费用。

最终采用连接策略并不限于购买一种产品或服务，就像克里希纳所说的那样，这是关于利用这个机会来考虑“整个商业模式升级”。

“公司如何上市，如何赚取利润，如何根据服务进行区分，以及如何建立和保持与客户的长期关系 - 它必须是一个全公司的举措。

“任何看这样的人都有机会成功。”

电子工程师和物联网（IoT）的产品和系统的应用程序开发人员都有一个几乎令人迷惑的连接选项。

许多通信技术是众所周知的，如WiFi，蓝牙，ZigBee和2G / 3G / 4G蜂窝，但也有几个新兴的新兴网络选项，如线程作为家庭自动化应用的替代品，以及在主要城市实施的空白电视技术用于更广泛的基于IoT的用例。根据应用，范围，数据要求，安全性和功率需求以及电池寿命等因素将决定某种形式的技术组合的选择。这些是向开发人员提供的一些主要通信技术。

蓝牙

重要的短距离通信技术当然是蓝牙技术，在计算和许多消费品市场中已经变得非常重要。预计这是可穿戴产品的关键，特别是连接到物联网，尽管可能通过智能手机在许多情况下。新的蓝牙低功耗（BLE）或蓝牙智能（如现在已被标注）是物联网应用的重要协议。重要的是，虽然它提供了与蓝牙类似的范围，但它的设计旨在显着降低功耗。

但是，Smart / BLE并不是真正设计用于文件传输，更适合于小块数据。鉴于其在智能手机和许多其他移动设备上的广泛集成，因此在许多竞争技术的个人设备环境中肯定具有重大优势。根据蓝牙SIG，超过90％的蓝牙智能手机，包括iOS，Android和Windows的型号，预计到2018年将“智能就绪”。

使用蓝牙智能功能的设备包含了基于射频收发器，基带和协议栈的基本数据速率和低能量核心配置的蓝牙核心规范版本4.0（或更高版本 - 2014年底最新版本4.2） 。重要的是，版本4.2通过其互联网协议支持配置文件将允许蓝牙智能传感器通过6LoWPAN连接直接访问互联网（下面更多）。这种IP连接使得可以使用现有的IP基础设施来管理蓝牙智能边缘设备。有关蓝牙4.2的更多信息，可从RS获得各种蓝牙模块。

标准：蓝牙4.2核心规格

频率：2.4GHz（ISM）

范围：50-150米（智能/ BLE）

数据速率：1Mbps（智能/ BLE）

Zigbee

ZigBee像蓝牙一样具有大量的操作基础，尽管传统上在工业环境中也是如此。 ZigBee PRO和ZigBee远程控制（RF4CE）以及其他可用的ZigBee配置文件均基于IEEE802.15.4协议，该协议是以2.4GHz为目标的行业标准无线网络技术，针对的应用程序需要相对不频繁的数据交换，在限制区域内的距离在100米范围内，例如在家庭或建筑物中。

ZigBee / RF4CE在复杂系统中具有一些显着的优势，提供低功耗操作，高安全性，鲁棒性和高可扩展性，具有高节点数量，并且有能力利用M2M和IoT应用中的无线控制和传感器网络。 ZigBee的最新版本是最近推出的3.0版本，它基本上是将各种ZigBee无线标准统一为单一标准。 ZigBee开发的示例产品和套件包括TI的CC2538SF53RTQT ZigBee片上系统集成电路和CC2538 ZigBee开发套件。

标准：基于IEEE802.15.4的ZigBee 3.0

频率：2.4GHz

范围：10-100米

数据速率：250kbps

Z波

Z-Wave是一种低功耗射频通信技术，主要用于诸如灯控制器和传感器之类的产品的家庭自动化。针对数据速率高达100kbit / s的小数据数据包的可靠和低延迟通信进行了优化，其工作在1GHz频段，并且不受WiFi和其他无线技术在2.4 GHz范围内的干扰，如蓝牙或ZigBee。它支持全网状网络，而不需要协调器节点，并且是非常可扩展的，可以控制多达232个设备。 Z-Wave使用比其他一些更简单的协议，可以实现更快更简单的开发，但与其他无线技术（如ZigBee等）的多种来源相比，唯一的芯片制造商是Sigma Designs。

标准：Z-Wave Alliance ZAD12837 / ITU-T G.9959

频率：900MHz（ISM）

范围：30m

数据速率：9.6 / 40 / 100kbit / s

6LowPAN

基于IP（Internet Protocol）的技术是6LowPAN（IPv6低功率无线个人区域网络）。 6LowPAN不是像蓝牙或ZigBee这样的IoT应用协议技术，而是一种定义封装和头压缩机制的网络协议。该标准具有频带和物理层的自由度，也可以在多种通信平台上使用，包括以太网，Wi-Fi，802.15.4和sub-1GHz ISM。一个关键的属性是IPv6（互联网协议版本6）堆栈，这是近年来非常重要的介绍，以实现物联网。 IPv6是IPv4的后继者，为世界上每个人提供大约5 x 1028个地址，使世界上任何嵌入式对象或设备都拥有自己的唯一IP地址并连接到互联网。例如，IPv6专为家庭或楼宇自动化设计，提供了一种基本的传输机制，可以通过低功耗无线网络以成本效益的方式生产复杂的控制系统和与设备进行通信。

该标准旨在通过基于IEEE802.15.4的网络发送IPv6数据包，并实施开放IP标准，包括TCP，UDP，HTTP，COAP，MQTT和Websockets，该标准提供端对端可寻址节点，允许路由器将网络连接到IP。 6LowPAN是一种网状网络，具有强大的可扩展性和自愈性。网状路由器设备可以路由指定给其他设备的数据，而主机能够长时间睡眠。这里有6LowPAN的解释，TI提供。

标准：RFC6282

频率：（适用于各种其他网络媒体，包括蓝牙智能（2.4GHz）或ZigBee或低功率射频（亚1GHz）

范围：N / A

数据速率：N / A

线程

线程是一种针对家庭自动化环境的新型基于IP的IPv6网络协议。基于6LowPAN，也喜欢它，它不是像蓝牙或ZigBee这样的IoT应用协议。然而，从应用的角度来看，它主要被设计为WiFi的补充，因为它识别出WiFi对于许多消费者设备而言是有利的，它在家庭自动化设置中使用的限制。

线程组于2014年中推出，免版税协议基于各种标准，包括IEEE802.15.4（作为无线空中接口协议），IPv6和6LoWPAN，并为物联网提供了一种弹性的基于IP的解决方案。 Thread专为从现有的IEEE802.15.4无线芯片供应商（如飞思卡尔和Silicon Labs）工作，Thread支持使用IEEE802.15.4无线电收发器的网状网络，能够处理多达250个具有高级别身份验证和加密的节点。相对简单的软件升级应允许用户在现有的支持IEEE802.15.4的设备上运行线程。

标准：线程，基于IEEE802.15.4和6LowPAN

频率：2.4GHz（ISM）

范围：N / A

数据速率：N / A

无线上网(WIFI）

WiFi连接通常是许多开发人员的明显选择，特别是考虑到局域网内家庭环境中WiFi的普及。除了明确指出，现有基础架构广泛，并提供快速的数据传输和处理大量数据的能力，这不需要进一步的解释。

目前，在家庭和许多企业中使用的最常见的WiFi标准是802.11n，其提供了在数百兆比特每秒的严格吞吐量，这对于文件传输是很好的，但对于许多IoT应用来说可能太耗电了。 RS提供了一系列用于构建基于WiFi的应用的RF开发套件。

标准：基于802.11n（今天最常见的用途）

频率：2.4GHz和5GHz频段

范围：约50m

数据速率：最大600 Mbps，但根据所使用的通道频率和天线数量（最新的802.11-ac标准应提供500Mbps至1Gbps），150-200Mbps更为典型。

蜂窝

需要更长距离运行的IoT应用程序可以利用GSM / 3G / 4G蜂窝通信功能。虽然蜂窝电话显然能够发送大量的数据，特别是对于4G，但对于许多应用来说，费用和功耗将会太高，但是对于传输速度非常低的基于传感器的低带宽数据项目来说，这是非常理想的互联网上的数据量。该领域的一个关键产品是SparqEE系列产品，包括原始的小型CELLv1.0低成本开发板和一系列与Raspberry Pi和Arduino平台一起使用的屏蔽连接板。

标准：GSM / GPRS / EDGE（2G），UMTS / HSPA（3G），LTE（4G）

频率：900/1800/1900 / 2100MHz

范围：GSM最大35km; HSPA最长200公里

数据速率（典型下载）：35-170kps（GPRS），120-384kbps（EDGE），384Kbps-2Mbps（UMTS），600kbps-10Mbps（HSPA），3-10Mbps

NFC

NFC（近场通信）是一种技术，能够实现电子设备之间的简单和安全的双向交互，特别适用于智能手机，允许消费者执行非接触式支付交易，访问数字内容和连接电子设备。本质上它扩展了非接触式卡技术的能力，并使设备能够在距离小于4cm的情况下共享信息。此处提供更多信息。

标准：ISO / IEC 18000-3

频率：13.56MHz（ISM）

范围：10厘米

数据速率：100-420kbps

Sigfox

标题另一种广泛的技术是Sigfox，它的范围在WiFi和蜂窝之间。它使用可免费使用的ISM频带，而不需要获取许可证，以便在非常窄的频谱范围内将数据传输到连接对象和从连接对象传输数据。 Sigfox的想法是，对于运行在小型电池上的许多M2M应用程序，只需要低级别的数据传输，则WiFi的范围太短，而蜂窝电话太贵，并且功耗太大。 Sigfox使用一种称为超窄带（UNB）的技术，仅用于处理每秒10至1,000位的低数据传输速度。与5000微瓦相比，蜂窝通信消耗的电量仅为50微瓦，或者可以通过2.5Ah电池提供典型的待机时间20年，而蜂窝电话仅为0.2年。

已经部署在成千上万个连接对象中，该网络目前正在欧洲主要城市推出，其中包括英国的十个城市。该网络提供了一个强大的，功率高效和可扩展的网络，可以与数百万个电池供电设备在几平方公里的区域进行通信，使其适用于预期包括智能电表，病人监视器，安全设备，街道照明和环境传感器。 Sigfox系统使用Silicon Labs等EZRadioPro无线收发器等硅片，为在1GHz以下频段工作的无线网络应用提供行业领先的无线性能，扩展范围和超低功耗。

标准：Sigfox

频率：900MHz

范围：30-50公里（农村环境），3-10公里（城市环境）

数据速率：10-1000bps

Neul

与Sigfox相似，在1GHz频段内运行，Neul利用电视白空间频谱的小片，提供高可扩展性，高覆盖率，低功耗和低成本无线网络。系统基于Iceni芯片，其使用白色空间无线电进行通信，以访问高质量的UHF频谱，由于模拟到数字电视转换，现在可用。通信技术称为无重量，是一种为IoT设计的新型广域无线网络技术，与现有的GPRS，3G，CDMA和LTE WAN解决方案大有竞争。数据速率可以是在同一个单一链路上从每秒几位到100kbps的任何数据速率;并且设备可以从2xAA电池消耗少至20至30mA，这意味着在现场10至15年。

标准：Neul

频率：900MHz（ISM），458MHz（英国），470-790MHz（白色空间）

范围：10公里

数据速率：最少可达100kbps

LoRaWAN

Again在某些方面与Sigfox和Neul类似，LoRaWAN针对广域网（WAN）应用，旨在为具有特定功能的低功率WAN提供支持，以便在IoT，M2M和M2M中支持低成本移动安全双向通信智能城市和工业应用。针对低功耗优化并支持具有数百万和数百万台设备的大型网络，数据速率范围为0.3 kbps至50 kbps。

标准：LoRaWAN

频率：各种

范围：2-5公里（城市环境），15公里（郊区环境）

数据速率：0.3-50 kbps。

在之前关于我们的示例保险公司ArchiSurance的“数字客户亲密度”战略的博客中，我们概述了他们打算使用更详细的客户数据来改善客户互动和满意度，并确定定制的保险费。 为此，他们希望使用物联网，从智能互联设备获取数据，如个人健身追踪器，车辆中的黑匣子，家庭自动化网关，车队管理系统，店内RFID设备或智能建筑传感器。

下图显示了他们的意图; 个人客户的保险费部分取决于他们从不同设备获得的数据。 处理此数据以创建客户特定的配置文件，这些配置文件输入到其保险费的计算中。 在总体水平上，这些数据还用于开发新型保险产品，并评估和调整公司的整体风险敞口。

为了支持这一点，ArchiSurance建立了一个数据采集网关，可以连接到生成相关数据的各种智能设备。 这些设备在新的ArchiMate 3.0标准中被建模为设备。 反过来，设备可以位于设施; 在下面的例子中，我们看到家庭报警系统和智能恒温器作为智能家居的一部分。 最后，智能恒温器本身连接到能量网络，模拟为ArchiMate中的分配网络。

ArchiSurance数据采集的实施基于微服务架构。 物联网设备可以通过REST API向网关注册自己。 它还使用API上的服务来通知网关它获取的数据。 该网关由平台即服务（PaaS）支持，为部署，集成，服务生命周期管理，会计，安全性，负载平衡，存储，虚拟化等提供服务。 对于每个已注册的设备，数据获取功能的实例将在容器中运行。 请注意，在体系结构模型中，我们通常不会描述设备的各个实例，而是专注于它们的类型。 如图3所示，它还展示了ArchiMate 3.0的改进分组概念，该概念聚合了其内容并允许与组之间的关系。

这些示例显示了物理和信息技术（现在由ArchiMate 3.0支持）之间的集成如何用于模拟物联网，工业4.0和云计算等创新技术。 BiZZdesign Enterprise Studio支持的不同模型内部和之间的完全可追溯性将允许您将这些技术与其支持的业务流程和产品相关联，并从那里与组织的战略功能，业务成果和业务模型相关联。 这使您可以非常了解创新对您组织的潜在机会和战略影响。

在以后的博客中，我们将展示更多此类示例。 请继续关注更多！

 

原文：https://bizzdesign.com/blog/archimate-3-0-internet-of-things/

本文：http://pub.intelligentx.net/iot-archimater-30-internet-things

讨论： 请加入知识星球【首席架构师圈】

INTERNET OF THINGS

IEEE标准协会（IEEE-SA）认识到物联网对工业的价值以及这项技术创新给公众带来的好处，这些标准，项目和事件与创造充满活力的物联网所需的环境直接相关。 该领域为与物联网有关的所有事物提供参考。

---

IEEE-SA IoT Ecosystem Study

IEEE-SA吸引了世界重点地区的利益相关者，创建了一个物联网生态系统研究。 该研究包括市场，技术和标准三个主要领域，以及对学术研究的作用和用户接受的重要性的考察。 该研究的执行摘要可用。

---

IEEE P2413, Draft Standard for an Architectural Framework for the Internet of Things Working Group

该标准草案定义了物联网（IoT）的架构框架，包括各种IoT域的描述，IoT域抽象的定义以及不同IoT域之间的共同点的识别。 要参与本标准的开发，请访问IEEE P2413工作组页面。

物联网相关标准

以下是与物联网有关的IEEE标准的部分列表。

IEEE 754™-2008 - IEEE浮点算法标准

IEEE 802.1AS™-2011 - 本地和城域网的IEEE标准 - 桥接局域网中时间敏感应用的时序和同步

IEEE 802.1Q TM -2011 - 用于本地和城域网的IEEE标准 - 媒体访问控制（MAC）桥接和虚拟桥接局域网

IEEE 802.3™-2012 - IEEE标准以太网

IEEE 802.3.1™-2011 - 以太网管理信息库（MIB）定义的IEEE标准

IEEE 802.11™-2012 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第11部分：无线局域网媒体访问控制（MAC）和物理层（PHY）规范修订10网状网络

IEEE 802.11ad™-2012 - 用于本地和城域网的IEEE标准 - 具体要求 - 第11部分：无线LAN介质访问控制（MAC）和物理层（PHY）规范 - 修订3：60 GHz中极高吞吐量的增强带

IEEE 802.15.1™-2005 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求。 - 第15.1部分：无线个人局域网（WPAN）的无线介质访问控制（MAC）和物理层（PHY）规范

IEEE 802.15.2™-2003 - IEEE推荐的信息技术实践 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第15.2节：无线个人区域网络与其他无线设备共存在非授权频带

IEEE 802.15.3™-2003 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第15.3节：高速率无线的无线媒体接入控制（MAC）和物理层（PHY）规范个人区域网络（WPAN）修订1：Mac子层

IEEE 802.15.3c™-2009 - IEEE信息技术标准 - 本地和城域网 - 具体要求 - 第15.3部分：修正2：基于毫米波的替代物理层扩展

IEEE 802.15.4™-2011 - 用于本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）

IEEE 802.15.4e™-2012 - 本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）修订1：MAC子层

IEEE 802.15.4f™-2012 - 本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）修订2：有源射频识别（RFID）系统物理层（PHY）

IEEE 802.15.4g™-2012 - 本地和城域网的IEEE标准 - 第15.4节：低速率无线个人区域网络（LR-WPAN）修订3：低数据速率，无线的物理层（PHY）规范智能计量公用事业网络

IEEE 802.15.4j™-2013 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求 - 第15.4节：低速率的无线介质访问控制（MAC）和物理层（PHY）规范无线个人局域网（WPAN）修订：替代物理层扩展，支持在2360-2400 MHz频带内运行的医疗身体局域网（MBAN）业务

IEEE 802.15.5™-2009 - 信息技术推荐实践 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第15.5节：无线个人区域网络中的网状拓扑能力（WPAN）

IEEE 802.15.6™-2012 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求 - 第15.6节：无线个人无线介质访问控制（MAC）和物理层（PHY）规范在身体内或周围使用的区域网络（WPAN）

IEEE 802.15.7™-2011 - 本地和城域网的IEEE标准 - 第15.7节：使用可见光的短距离无线光通信

IEEE 802.16™-2012 - IEEE宽带无线接入系统空中接口标准

IEEE 802.16p™-2012 - IEEE宽带无线接入系统空中接口标准修订：对机器到机器应用的增强

IEEE 802.16.1b™-2012 - 用于宽带无线接入系统的无线高级空中接口的IEEE标准 - 修订：对机器到机器应用的增强

IEEE 802.22™-2011 - IEEE信息技术标准 - 系统之间的电信和信息交换无线区域网络（WRAN） - 具体要求第22部分：认知无线RAN媒体接入控制（MAC）和物理层（PHY）规范：电视频道的运作政策和程序

IEEE 802.22.1™-2010 - 信息技术IEEE标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第22.1部分：为在电视中运行的低功率许可设备增强有害干扰保护的标准广播频带

IEEE 802.22.2™-2012 - IEEE信息技术标准 - 系统之间的电信和信息交换 - 本地和城域网 - 具体要求第22.2部分：IEEE 802.22系统的安装和部署

IEEE 1284 TM -2000 - 用于个人计算机的双向并行外围接口的IEEE标准信令方法

IEEE 1285 TM -2005 - 可扩展存储接口的IEEE标准（S / SUP 2 / I）

IEEE 1301.3™-1992 - 用于微型计算机的公制设备实践的IEEE标准 - 带2.5mm连接器的对流冷却

IEEE 1377™-2012 - 用于实用工业计量通信协议应用层（终端设备数据表）的IEEE标准

IEEE 1394™-2008 - 用于高性能串行总线的IEEE标准

IEEE 1451.0™-2007 - 用于传感器和执行器智能传感器接口的IEEE标准 - 通用功能，通信协议和传感器电子数据表（TEDS）格式

IEEE 1547™-2003 - IEEE电力系统互连分布式资源标准

IEEE 1547.1 TM -2005 - 用于将分布式资源与电力系统相互连接的IEEE标准一致性测试程序

IEEE 1547.2™-2008 - IEEE Std 1547™IEEE应用指南，IEEE电力系统分配资源互连标准

IEEE 1547.3™-2007 - IEEE电力系统互连监控，信息交换和分布式资源控制指南

IEEE 1547.4™-2011 - IEEE电力系统分布式资源岛系统设计，运行和集成指南

IEEE 1547.6™-2011 - IEEE分布式资源与电力系统分配二级网络互连的推荐做法

IEEE 1609.2™-2013 - 车载环境中的无线接入IEEE标准 - 应用和管理消息的安全服务

IEEE 1609.3™-2010 - IEEE车载环境无线接入标准（WAVE） - 网络服务

IEEE 1609.4™-2010 - IEEE车载环境无线接入标准（WAVE） - 多通道操作

IEEE 1609.11™-2010 - 车载环境无线接入IEEE标准（WAVE） - 智能交通系统（ITS）的空中电子支付数据交换协议

IEEE 1609.12™-2012 - 车载环境中的无线接入IEEE标准（WAVE） - 标识符分配

IEEE 1675™-2008 - 电力线硬件宽带IEEE标准1900.1-2008 IEEE标准动态频谱接入定义和概念：与新兴无线网络，系统功能和频谱管理有关的术语

IEEE 1701™-2011 - 用于光端口通信协议的IEEE标准，用于补充实用工业终端设备数据表

IEEE 1702™-2011 - 用于电话调制解调器通信协议的IEEE标准，用于补充实用工业终端设备数据表

IEEE 1703™-2012 - 用于局域网/广域网（LAN / WAN）节点通信协议的IEEE标准，以补充实用工业终端设备数据表

IEEE 1775™-2010 - 电力线通信设备IEEE标准 - 电磁兼容性（EMC）要求 - 测试和测量方法

IEEE 1815™-2012 - IEEE电力系统标准通信 - 分布式网络协议（DNP3）2200-2012 IEEE标准协议，用于媒体客户端设备中的流管理

IEEE 1888™-2011 - 用于无处不在的绿色社区控制网络协议的IEEE标准

IEEE 1900.1 TM -2008 - 用于动态频谱接入的IEEE标准定义和概念：与新兴无线网络有关的术语，系统功能和频谱管理

IEEE 1900.2™-2008 - IEEE推荐的无线电系统带内和相邻频带干扰与共存分析的实践

IEEE 1900.4™-2009 - IEEE建筑构架标准，为非均匀无线接入网络中优化的无线电资源使用实现网络设备分布式决策

IEEE 1900.4a™-2011 - IEEE建筑构架标准为异构无线接入网络中优化的无线电资源使用实现网络设备分布式决策修订1：白色空间频段中动态频谱接入网络的架构和接口

IEEE 1901™-2010 - IEEE电力线网络宽带标准：介质访问控制和物理层规范

IEEE 1902.1™-2009 - IEEE标准的长波无线网络协议

IEEE 1905.1 TM -2013 - 用于异构技术的融合数字家庭网络IEEE标准

IEEE 2200™-2012 - 媒体客户端设备中流管理的IEEE标准协议

IEEE 2030™-2011 - IEEE电力系统（EPS），终端应用和负载能源技术与信息技术操作智能电网互操作指南

IEEE 2030.5™-2013 - IEEE采用Smart Energy Profile 2.0应用协议标准

IEEE 11073-00101™-2008 - IEEE卫生信息学标准 - PoC医疗设备通信 - 第00101部分：指南 - 使用射频无线技术的指南

IEEE 11073-10102™-2012 - IEEE健康信息标准 - 医疗器械通讯点 - 命名 - 注释心电图

IEEE 11073-10103™-2012 - IEEE健康信息标准 - 医疗器械通信点 - 术语 - 可植入器件，心脏

IEEE 11073-10201™-2004 - IEEE健康信息标准 - 医疗器械通信点 - 第10201部分：域信息模型

IEEE 11073-10404™-2010 - IEEE健康信息标准 - 个人健康设备通信第10404部分：设备专用 - 脉搏血氧仪

IEEE 11073-10406™-2011 - IEEE健康信息标准 - 个人健康设备通信第10406部分：设备专业化 - 基本心电图仪（ECG）（1到3导联ECG）

IEEE 11073-10407™-2010 - IEEE健康信息标准个人健康设备通信第10407部分：设备专业化血压计

IEEE 11073-10408™-2010 - IEEE健康信息标准个人健康设备通信第10408部分：设备专用温度计

IEEE 11073-10415™-2010 - IEEE健康信息标准个人健康设备通信第10415部分：设备专用称重标尺11073-10420-2010 IEEE健康信息标准 - 个人健康设备通信第10420部分：设备专业化 - 身体成分分析仪

IEEE 11073-10417™-2011 - IEEE健康信息标准个人健康设备通信第10417部分：设备专业化葡萄糖计

IEEE 11073-10418™-2011 - IEEE健康信息标准 - 个人健康设备通信 - 设备专业化 - 国际标准化比率（INR）监测

IEEE 11073-10420™-2010 - IEEE健康信息标准 - 个人健康设备通信第10420部分：设备专业化 - 身体成分分析仪

IEEE 11073-10441™-2008 - IEEE健康信息学标准 - 个人健康设备通信 - 第10441部分：设备专业化 - 心血管健康和活动监测

IEEE 11073-30300™-2004 - IEEE健康信息标准 - 医疗器械通信点 - 运输配置文件 - 红外线

IEEE 11073-30400™-2010 - IEEE卫生信息标准 - 医疗器械通信点第30400部分：接口配置文件 - 电缆以太网

IEEE 14575™-2000 - 用于异构互连（HIC）的IEEE标准（用于并行系统构建的低成本，低延迟可伸缩串行互连）

IEEE 21450™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 通用功能，通信协议和传感器电子数据表（TEDS）格式

IEEE 21451-1™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 第1部分：网络能力应用处理器（NCAP）信息模型

IEEE 21451-2™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 第2部分：传感器到微处理器通信协议和传感器电子数据表（TEDS）格式

IEEE 21451-4™-2010 - IEEE信息技术标准 - 传感器和执行器的智能传感器接口 - 第4部分：混合模式通信协议和传感器电子数据表（TEDS）格式

IEEE 21451-7™-2011 - 用于传感器和执行器的智能传感器接口IEEE标准 - 射频识别（RFID）系统的传感器通信协议和传感器电子数据表格式

为什么我们不用c++重写我们的物联网应用程序

这是关于我们dwell如何在Rust中重写他们的物联网网关软件的系列文章的第2部分。这个系列从这里开始，下一章在这里。

我本来打算写为什么我们在dwell不选择c++来重写物联网，但后来我意识到还有一个更广泛的问题需要讨论。我想把这个决定放在历史上我们所有的错误代码的背景下，作为一个物种。在80年代和90年代，我们使用了普罗米修斯的天赋——C语言来为世界各地的每个嵌入式系统编写软件。我们所能完成的事情是没有限制的。但很多我们当时认为很聪明的做法，现在回想起来显然是糟糕的习惯。这些熟悉的错误在几十年后继续造成痛苦和破坏。我将提出我在C和c++的产品代码中看到的一些无可争辩的可怕的东西。我将讨论我所犯过和看到过的错误，在下一章中，我们将讨论简单的语言选择如何彻底地消除大量错误，同时仍然给我们足够的灵活性来编写低级软件。

我们本可以用c++重写我们的物联网平台应用程序。它检查了所有的箱子。这对我来说很熟悉，甚至很容易。但这也会让我或其他人很容易犯错误。使用C就像用蜡烛来照明。它的基本特性是众所周知的，它从人类文明开始就存在了，如果你滥用它，它会点燃你周围的房子。(在这个比喻中，c++是“所有可以被点燃产生光的事物的集合”。)

在过去的30年里，我读了很多糟糕的代码。我也写了不少。没有人是完美的程序员，我们应该选择能够反映这种谦逊的工具。让我们看看您是否熟悉这些陷阱。

神秘指针参数

void myfunc(char* c);

char c;

myfunc(&c);

myfunc的参数是输入吗?一个输出?都有?它实际上是一个以空结尾的数组吗?所有的代码路径都初始化传递的值吗?myfunc segfault如果我传递它为空?函数会保留我传入的指针并在以后使用它吗?查看函数定义并确定它将做什么是不可能的，因为它允许做很多事情。对于小程序来说，这有点烦人。对于拥有超过12个函数的程序，很快就不可能推断出程序的正确性，我们不得不依赖API文档。我们都知道，文档总是正确和最新的。

我敢肯定，你们当中的学究们都在对监视器大喊:如果指针参数只是作为输入，那么签名应该采用const指针。虽然这是正确的，但我从未使用过正确且一致声明参数为const的遗留代码库。(注意:我不确定这是因为古代的编译器不支持const关键字，还是因为在过去的几十年里，一些集体的关节炎让输入这些额外的字符变得很痛苦。无论如何，这在旧代码中很常见。)

Const正确性仍然没有解决房间里的另一个大象……

空指针

const char* foo = 0; /* I remembered to initialize my variable! */

printf(foo);

我将假设您已经读过关于十亿美元错误的文章，并且您已经在您的编程经验中看到过“Segmentation Fault”或“NullPointerException”。如果还没有，请点击上面的链接。我还会在这里。

回来了吗?太棒了。

我要在这里说:托尼·霍尔爵士不仅才华横溢，而且非常谦虚。很少有计算机科学家或软件工程师会直截了当地承认一个设计决策是错误的。不幸的是，这个起源于20世纪60年代的错误非常普遍，我相信许多人看到上面的代码时会想，“编译器会警告您，有什么大不了的?”

当你在8个不同的文件中通过10个不同的函数从A到B到C传递指针参数时，问题就来了，对于编译器(或审阅者)来说，你刚刚在函数上下文之间传递了空指针或未初始化的指针并不是很明显。

您没有在运行时检查每个函数条目是否有非零指针，我没有，标准库肯定也没有。我们不要自欺欺人了。

好吧，让我们使用c++引用

#include <string>bool isEqualToLast(const std::string& s) {
  static const char * last = "";
  bool foo = s.compare(last) == 0;
  last = s.c_str();
  return foo;
}

这段代码在GCC 8上使用-Wextra编译时没有警告，我们正确地使用了const，并且知道参数指向真实数据。只要每个参数都是静态分配的，或者是堆分配的，而不是提前释放，它就可以正常工作。无Bug，直到您使用堆栈变量调用它一次后调用为止。

隐式投射的缺陷（Implicit Cast Bugs）

char data[ENORMOUS_BUF_SZ];

for (int i = 0; i < sizeof(data); ++i) {

/* do stuff */

}

C语言中最具创新性的概念之一是类型系统。每个表达式都有一个类型，例如，如果在需要整数的地方尝试使用字符数组，就会得到一个编译错误。这通常可以防止您犯严重的错误，比如混淆函数参数的顺序。然而，编译器有时会通过静默地将8位类型转换为32位类型、有符号类型转换为无符号类型、稍微篡改类型直到它们对齐来“帮助”它们。需要遵循某些隐含的强制转换规则，即使这些规则可能与您的直觉不符。因为这是预期的行为，所以编译器在这样做时不需要警告您。

我们使用size_t已经有几十年了。不幸的是，现代代码中仍然充斥着应该使用size_t却使用int或unsigned int的循环，而且错误指定的函数实参类型比比皆是。它工作得很好，直到它不再工作。不要让我开始讲time_t的错误用法。

显式类型转换错误

const int data[512] = {0};

volatile uint32_t* WDT_REG = 0xFFFFFFE0;

/* ... */

byte_sending_function((char *)data, sizeof(data));

handle_watchdog((uint32_t *)WDT_REG);

byte_sending_function的转换应该是(const char *)， handle_watchdog的签名需要接受一个volatile指针。

是的，我知道c++中的static_cast和reinterpret_cast。但是C风格的强制类型转换仍然存在于书本和课堂中，而且它们仍在将其写入新的c++代码中。在我所见过的所有编译器中，抛弃const或volatile都是完全合法的。

谁需要错误处理呢?

#include <stdio.h>
#include <stdlib.h>int main() {
   FILE * fp = fopen("file.txt", "w+");
   fprintf(fp, "This cannot possibly go wrong.\n");
   fclose(fp);
   
   return 0;
}

这个可爱的例子来自谷歌#1的“fopen example”(稍微重新格式化一下)，它并没有费心去检查我们是否真的可以打开文件，编译器也不要求甚至不提醒我们这么做。对我来说工作，不是一个bug，赶快编译，因为我有更多的潜在段错误，我需要添加到这个代码库。砍砍。

(在查看这篇文章时，我意识到fprintf和fclose也可以返回负值来表示失败。我忘记了，因为即使是正确验证fopen句柄的代码，也经常不检查单个fprintf返回值。忽略这个检查不会出现segfault，但是代码也不会知道它是否不能正确地写入文件。)

Buffer overfl$%^&#\b0x9328A7F0Segmentation fault

本段执行了非法操作，必须终止。

如果您认为您看到的是错误的信息，请联系技术支持。

联盟类型（Union types）

union {
  int id;
  void * widget_ptr;
} widget;#ifdef LINUX
widget.id = 42;
#else
widget.widget_ptr = malloc(64);
#endif/* many lines later... */
/* I'm quite certain I stored a pointer in here */
free(widget.widget_ptr);

伙计们，我要把这个按钮和一个小牌子放在这里，上面写着“请勿触摸”。“只要没人滥用它，我们就没事。”

线程安全

我甚至不打算深入可重入函数、副作用、原子性、互斥和信号量、内存屏障等细节。C和c++是为单线程命令式编程而设计的——你给计算机一个按顺序执行的计算列表。如果你想聪明一点，在多线程应用程序中使用它，那么你就有责任熟练使用指针、别名和共享状态，避免在代码中的任何地方犯任何错误。如果它成功了，你将拥有世界上最快的商业应用。如果没有，会有人在你离开之前发现问题吗?据说，天才和疯狂是一枚硬币的两面;让我们来探讨一下这个界限。下面是您的最佳实践指南。瓦尔哈拉殿堂等待。

好吧，我懂了。但是我喜欢C语言，我们不能直接修复C/ c++吗?

大量的工作已经投入到使警告更智能、改进文字、记录最佳实践等方面。c++ 11/14/17中有一些非常有用的新特性:unique_ptr、基于范围的for循环和RAII，它们都可以帮助防止bug(如果你使用它们的话)。有像MISRA这样的标准组织和像CERT这样的安全组织来帮助你发现和修复关键的安全和安全问题，如果你的团队中的每个人都严格遵守这些建议的话。但K&R C的尖锐碎片仍在地板上乱扔，没有什么能阻止你或你旁边的人无视警戒线，绊倒在上面。

尽管在工具和过程上投入了大量的努力，C标准仍然有大量未定义的行为。总之，驱动世界上大多数软件的这两种编程语言都被微妙而又根本地破坏了，因为受过训练的、聪明的专业人员在生产过程中总是犯代价高昂的错误。我们共同努力掩盖这个问题，这证明了仅两位贝尔实验室工程师的惊人技能，他们的语言足够灵活，可以让我们尝试所有这些修复!但我们确实需要解决根本的结构性问题。而且，不幸的是，我们不能在不破坏向后兼容性的情况下修复C语言。

C和c++代码管理你的汽车的油门控制，安全气囊，和防抱死制动系统。它是关键和非关键客机的航空电子软件的基础。它悄无声息地在一堆你不加思索地使用的东西上运行嵌入式操作系统，你所期望的东西是如此简单，它们应该是默认的安全和稳定的。信用卡终端。电力电网系统。电梯。军事硬件。无线路由器。自动取款机。投票机。作为一个以编写嵌入式软件为生的不可靠的人，这让我感到害怕。

总的来说，我们之所以使用这些工具，是因为它们很熟悉，但经验表明，我们无法安全地使用它们。我喜欢C语言，我们非常感谢它的遗产。但我们也有责任用能够帮助我们克服自身缺点的语言来写作。问题不在于我们在道路上安装照明弹来照亮我们的房子，而煤气灯更合适，尽管周围确实有足够的煤气灯。问题是我们根本不应该使用火。我们现在有LED手电筒。是时候停止点蜡烛了。

 

原文：https://medium.com/dwelo-r-d/abusing-fire-for-light-a6e6774289fd

本文：http://jiagoushi.pro/node/1439

讨论：请加入知识星球【全栈和低代码开发】或者微信【it_training】或者QQ群【10777】

亚马逊回声。 FitBit。甚至你的咖啡壶。

虽然你可能会认为“这些事情之一不像其他的东西”，但它们都是物联网（IoT）的例子。

它们都是可以连接到互联网并被其他设备识别并向数据库提供信息的日常物品。物联网描述了Internet V.2，其中数据是由事物创建的。

数字创新专家凯文·阿什顿（Kevin Ashton）被认为是用这个术语来定义物联网的定义：

“如果我们有电脑知道所有事情，就可以从他们所收集到的数据中获取信息，我们将能跟踪和计算一切，大大减少浪费，损失和成本。我们会知道什么时候需要更换，修理或召回，以及他们是新鲜还是过去最好的。“

既然物联网已经使物理世界成为一个庞大的信息系统，物联网将如何影响到2017年的业务？

这只是物联网的开端

虽然有些人会认为IoT以比预期的更低的采用率开始了一个摇滚的开始，但大多数人会同意IoT正在增长，并将在2017年及以后继续增长。到2020年到2020年连接设备的高端预测还有待观察，但我坚信，学习利用物联网创造的数据的企业是未来将会生存和发展的企业。

由于物联网，现在有几种新产品和创新。

更智慧的家园

2016年智能家居技术肯定会有很大的应用;专家认为，亚马逊在2016年假期的销售量比去年同期高出9倍。智能家居技术调查显示，智能家居技术在2017年将变得更加重要。根据智能家居技术调查，智能家居技术调查显示，70％的购买智能家居设备的人认为他们更有可能购买更多。

穿戴技术

2015年销售的可穿戴产品有7810万件，到2020年市场预计将增长到4.11亿。所有可穿戴技术，包括智能手表，健身追踪器，VR耳机等，都能产生大量企业刚刚了解的数据可能性和潜在应用。

智能车

据估计，到2021年，令人惊讶的82％的汽车将连接到互联网。应用程序集成，导航和诊断工具，甚至自驾车将是物联网改变汽车行业的方式。汽车行业正在大力投入决定下一届IofT创新。

改变我们做生意的方式

我们只是抓住了物联网为消费者提供新产品和可能性的方式，但也会影响我们的业务。这里只是几种方法：

1. 库存管理：任何花了工作日或周计数小部件的人都会欣赏物联网对库存管理的美感。智能设备最终将能够自动跟踪广告资源。

2. 消费者需求：消费者将习惯于智能设备，并开始期待他们生活中各方面的“聪明”行为。发明家将有一个实地的日子，提供新的小工具，家具，家电等，以满足这种新的需求，并为企业提供新的收入来源。

3. 较短的购买周期：企业将需要以更短的购买周期和消费者对物联网支持的即时满足度的期望来达成。

4. 从数据中学习：从智能设备生成的数据量可帮助企业了解如何以及创新的最大影响。

5. 远程工作：随着物联网变得更加集成，可以为需要现场完成工作的任务提供更多的远程工作机会。

毫无疑问，物联网刚刚开始。现在开始在其产品，服务和运营中开发或扩展物联网技术的企业是实现竞争优势的企业。

当然，与大多数新创新一样，IoT也有缺点;目前，大多数IoT设备都没有安全保护，使其成为黑客的轻松目标。去年，数百万个物联网设备遭到黑客入侵，被用来占用互联网的一些基础设施。未来，物联网制造商将会更加注重安全性，用户应采取一切预防措施来保护设备。

 

无论您是IoT还是经验丰富的老将，您可能以前听说过“IoT Platform”一词。毕竟，去年有超过300个物联网平台，这个数字继续快速增长（我听说现在有700多个）。物联网平台市场的复合年增长率（CAGR）为33％，预计在2021年将达到16亿美元。

物联网平台是物联网生态系统的关键组成部分，但是我发现，对于许多人来说，目前还不清楚什么是物联网平台或者它们之间的区别。

在这篇文章中，我将为IoT平台提供一个简单的，非技术性的解释。它们是什么，当企业使用它们时，以及在众多选项之间进行选择时的重要考虑。

那么什么是IoT平台呢？

要了解什么是物联网平台，首先您需要了解一个完整的IoT系统的组件。我以前的帖子，“物联网系统如何工作？”是一个很好的学习方式，但我将在这里快速总结。

1. 完整的IoT系统需要硬件，如传感器或设备。这些传感器和设备从环境（例如水分传感器）收集数据或在环境中执行动作（例如浇水作物）。

2. 完整的IoT系统需要连接。硬件需要一种将所有数据传输到云端的方法（例如发送湿度数据）或需要一种从云接收命令的方法（例如，现在对作物播种）。对于一些IoT系统，可以在硬件和连接到云之间的中间步骤，例如网关或路由器。

3. 完整的IoT系统需要软件。该软件托管在云端（什么是云端），并且负责分析从传感器收集的数据并作出决定（例如，从湿度数据知道刚刚下雨，然后告诉灌溉系统今天不打开） 。

4. 最后，完整的IoT系统需要用户界面。为了使所有这些都有用，需要一种方式让用户与IoT系统进行交互（例如，具有显示湿度趋势的仪表板的Web应用程序，并允许用户手动打开或关闭灌溉系统）。

IoT平台是连接IoT系统中的所有内容的支持软件。 IoT平台有助于通信，数据流，设备管理和应用功能。

IoT平台存在于第3部分中，通常是上述内容的第4部分。随着所有不同种类的硬件和不同的连接选项，需要一种使所有工作在一起的方式，这就是IoT平台所做的工作。

IoT平台帮助：

• 连接硬件

• 处理不同的通讯协议

• 为设备和用户提供安全和身份验证

• 收集，可视化和分析数据

• 与其他Web服务集成

您的业务何时应用物联网平台？

由于IoT是一个系统系统，因此在所有相关领域拥有专长的组织很少见。存在物联网平台，可帮助企业克服技术挑战，而无需将其全部归咎于内部。

例如，您的业务可能真的很好的构建硬件，并决定要使您的硬件“聪明”。而不是雇用软件开发人员在内部构建一切的昂贵和耗时的过程，您可以使用IoT平台快速，更经济地开始运行。

但是，有一个权衡。 IoT平台可以节省您的时间，从长远来看，价格可能会更高，这取决于它们的价格。这是因为他们收取使用和/或订阅费用，这些费用可能随着时间的推移而增加。但是，您仍然可以获得显着降低前期成本（无资本支出）的好处。

在前期廉价的IoT平台可能会花费你的时间。这可以回到同样的一点，粗体上面，你花更少的工作，你必须自己做，这需要时间。

Low-power Wide-area Networks: Enabling Geo-IoT

Although the term ‘Internet of Things’ (IoT) has actually been around since the end of the last millennium, the true potential of IoT has only started to unfold beyond the interest of pioneers in the last couple of years. One of the reasons IoT is now booming is the emergence of more low-power wide-area networks (LPWANs) that enable location-aware devices to interconnect in a power-efficient manner. This Technology in Focus article explains the concept of LPWANs and the link to geographic information.

(By Sabine de Milliano, contributing editor, GIM International)

LPWANsare designed to allow wireless communication over a long range at a low data rate. These two distinctive characteristics open up a whole new range of applications, in particular because of the lower power consumption and lower costs that are associated with LPWANs as opposed to traditional machine-to-machine (M2M) communication using SIM cards. For example, installing and maintaining numerous water-quality sensors in a river, canal or other water body becomes a lot more cost efficient if you do not have to replace batteries every few months nor pay for an expensive mobile data subscription for each of your sensors. Provided the hardware is designed efficiently, you could now leave sensors unattended in the field for up to several years, plus the network costs per sensor drop significantly. Additional emerging technologies such as energy harvesting – in which devices collect small amounts of energy in various ways to replenish their power – can even potentially make sensors and devices completely autonomous throughout their entire product lifetime.

Protocols

There are various types of LPWANs, and both the technology and the commercial market are still in development. For the purpose of simplicity, this article will briefly compare the most widely known LPWANs: LoRaWAN, Sigfox, Narrow-Band IoT (NB-IOT) and LTE-M. These LPWANs all differ in their communication implementation, individual power consumption, bandwidth and type of band, geolocation capabilities, type of native security, current coverage for deployment and whether they make use of open standards or proprietary technology. LoRaWAN, for example, is a wideband system that requires a specialised chip developed by Semtech (which implies it is not an open standard), but there are a couple of network suppliers to choose from. The French system Sigfox, which is a type of ultra-narrow band (UNB) network, is considered to be one of the most power-efficient networks currently available but its bandwidth is very limited and more suitable for one-way than two-way communication. And although it uses an open standard – so anyone can potentially develop a device for use with Sigfox – it still requires you to use the Sigfox network. Both NB-IOT and LTE-M differ from LoRaWAN and UNB in that they make use of existing cellular networks. For example, NB-IOT reallocates part of the 4G band for the LPWAN. This means there is no new network infrastructure required, as the technology uses existing cellular network towers.

Competition

Table 1 gives an overview of the relative advantages and disadvantages of the four LPWANs. The question that often arises from such comparisons is: who is going to win the LPWAN battle? Sigfox and LoRaWAN have the time advantage as they are currently more mature than NB-IOT and LTE-M. The latter two, however, will probably become strong competitors (if – arguably – not winners eventually) thanks to their different business model and promising technical characteristics. But the future battle is not just between the four IoT enablers discussed here; there are also various current initiatives to launch an IoT network into space based on small (nano-) satellites that together deliver global coverage for internet access and tracking services. It is just a matter of time before these plans become reality.

Table 1, Some properties of LPWAN technologies that determine their fitness for use for a particular application.

	LoRaWAN	Sigfox	NB-IOT	LTE-M
Power consumption	low	very low	very low	low
Amount of data transfer	low, amount depends on local providers	very low, mainly suitable for one-way communication	low	medium
Native localisation available	yes, differential time of arrival calculated at network	yes, differential time of arrival calculated at network	possible to inherit from existing LTE positioning	possible to inherit from existing LTE positioning
Suitable for time-critical applications	no	yes	yes	yes
Type of band	unlicensed	unlicensed	licensed	licensed
Potential choice of network	multiple network initiatives	requires Sigfox network to be used	delivered by cellular network providers	delivered by cellular network providers
Potential choice of hardware	requires Semtech chip	no restrictions	no restrictions	no restrictions
Current coverage for deployment	initiatives worldwide, but still mainly operational in Europe	parts of Europe, some other countries planned for roll-out	first trials operational	still in development phase

Positioning

One service that is of particular interest to the geomatics industry is the delivery of positioning by LPWAN providers without the need for GNSS. LoRaWAN and Sigfox enable medium-accuracy geolocation of devices through different time of arrival that is carried out by the network itself, which sends back the location information to the device. In this way, the device requires no additional hardware or power to become a smart, location-aware end node. Similarly, NB-IOT and LTE-M can inherit the existing LTE positioning technology to provide native localisation.

Location is key

The market for new IoT applications is expected to become very big. LPWANs enable many new applications with a geographic component. The growing number of devices can either gather large amounts of geographic data, or they can be triggered to perform specific actions based on their location. In both cases geographic data plays a vital role, which opens up a wide range of opportunities for the geomatics industry to enter the world of geo-IoT.

正如我在之前的#askIoT文章中所探讨的那样，几乎每个IoT系统都需要一些方法来将传感器/设备连接到云端，以便数据可以在它们之间来回传递。 IoT网关在使连接成为可能方面至关重要，但是什么是网关？

网关作为传感器/设备和云端之间的桥梁。

许多传感器/设备会与网关“通话”，网关将把所有信息和“谈话”给云（什么是云？）。

但为什么额外的步骤？

现在你知道一个网关是什么，你可能会想知道在传感器/设备和云之间采取额外的步骤有什么好处。结果有几个好处：

• 电池寿命

如果传感器/设备位于远程区域，则可能需要远程连接，例如卫星连接才能与云端通话。如这里所述，较长的范围通常意味着增加的功耗（和成本）;这对于具有有限电池寿命的小型传感器/设备来说可能是一个问题。

如果您正在做Smart Agriculture，您希望您的现场传感器能够持续数年，而不是数月或数周。通过使用安装在外围或谷仓仓顶部附近的高架网关，传感器/设备只需要将数据发送到网关的距离很短，并且网关可以通过单个更高带宽的连接将数据回传到云端。

网关允许传感器/设备在较短距离内进行通信，从而提高电池寿命。

• 不同的协议

完整的IoT应用可能涉及许多不同种类的传感器和设备。再次使用智能农业，您可能需要传感器的温度，湿度和阳光以及自动灌溉和肥料系统等设备。

所有不同的传感器和设备都可以使用不同的传输协议（基本上是传输信息的规则和格式）。协议包括LPWAN，Wi-Fi，蓝牙和Zigbee等等。

网关可以通过不同协议与传感器/设备进行通信，然后将该数据转换为标准协议（如MQTT），以发送到云端。

• 未过滤的数据

有时，传感器/设备可以产生如此多的数据，这是数据压倒在系统上或传输和存储成本极高的情况。通常在这种情况下，只有一小部分数据实际上是有价值的。例如，安全摄像机不需要发送空走廊的视频数据。

网关可以预处理和过滤由传感器/设备生成的数据，以减少传输，处理和存储要求。

• 高延迟

在上周的#askIoT文章中，我解释说，时间对于某些IoT应用来说可能至关重要;传感器/设备无法将数据传输到云端，并在采取行动之前等待获得响应。对于医疗领域的生命或死亡情况或汽车等快速移动的物体，这是真的。

通过处理网关上的数据并在本地发出命令可以避免更高的延迟。然而，IoT应用中的许多传感器/设备太小，电池太低，无法进行处理。

网关可以通过在网关本身而不是在云中执行处理来减少时间关键应用程序的延迟。

• 安全

连接到互联网的每个传感器/设备都容易被黑客入侵。被劫持的传感器/设备是坏的。不只是为业主，而是为所有人。

几周前，名叫未来的恶意软件被用来攻击和控制数以千计的物联网设备。然后，这种“机器人网络”的设备被用来占用互联网的主要部分（更多关于未来）。

网关减少了连接到互联网的传感器/设备的数量，因为传感器/设备仅连接到网关。然而，这使得网关本身成为目标，也是第一道防线。这就是为什么安全需要成为任何网关的优先考虑的原因。

七月份，黑客在每小时70英里的时候关闭一辆汽车。 8月份，研究人员开启了ZigBee网络协议，为从Philips Hue灯泡到Kwikset智能锁的所有工具铺平了道路。今年的DEF CON安全会议由三个全天的物联网（IoT）黑客研讨会和研讨会组成，从不祥之地的“摇篮摇篮：劫持IoT婴儿监视器”开始。

下载报告研究：物联网安全状态

物联网背面有一头牛仔，很容易看出为什么：由于没有中心的物联网标准，没有真正的监督开发，Gartner估计将在今年年底前使用的近50亿智能设备是诱惑的目标是那些想要破坏或更糟糕的人。

IoT标准可以救我们吗？

IoT标准谈话始于2013年初，但到目前为止，可能已经太晚了。技术行业在制定标准时不是闲置的。在标准接近批准之前，太多的技术战争获胜或失败。 Betamax的鬼魂仍然困扰着这个行业。

通常情况下，标准谈话已经开始，各种联盟已经形成，一些党派，更独立。到2014年，这些标准中的少数已经成熟，今天有几个标准甚至在有限的基础上开始认证产品。

也就是说，大家都同意我们距离通用的物联网标准还有很长的路要走，实际上很少有人希望单一的标准将会像Wi-Fi和DVD这样的标准成为主流。其中一部分是物联网本身的挑战。甚至对物联网的内容甚至没有一个共同的定义 - 灯泡标准如何与起搏器标准协调一致？

相关性丢失

围绕标准的其他对话是我们是否需要它们的问题。我们越来越多地发现Wi-Fi，IFTTT，SmartThings和其他旨在将不相容的技术结合在一起的创新，无论他们是否有意合并。除了与诸如蓝牙，ZigBee和Z-Wave之类的一些成熟的通信协议的兼容性之外，许多人正在询问物联网标准是否可能是无关紧要的。

space150首席技术官Marc Jensen和一名严重的物联网骇客，他说：“这里还是野外狂野的西部。 InfoTech Solutions for Business的系统集成商创始人兼首席执行官Matti Kon补充说：“马已经出来之后，我们正试图关闭谷仓的门。”

北卡罗来纳州无线研究中心的总经理拉里·史蒂夫恩（Larry Steffann）是一个区域性的非营利性无线研究小组，对这个问题采取了市场化的做法：“我们鼓励人们继续发展，不要等待任何标准。 “

那么有几个人仍然关心标准 - 主要是那些继续发展的标准。一个关键的事情是，物联网需要大量技术从无线通信到数据安全，以及与其他设备的通信。单一标准不可能涵盖所有这一切，只有单一标准涵盖了笔记本电脑的工作方式。

AT＆T Foundry运营总监Craig Lee全力以赴。 “在物联网标准领域，我们可以考虑四个标准正在运行的层次：第一个是应用层，研究开发IoT应用的协议，正在IETF，OASIS，OMA和W3C等标准体系中开发第二个是服务层开发支持IoT服务的框架。“Lee继续说道。

这些框架正由一个M2M，OIC和AllSeen开发。下一层是网络，它正在查看支持IoT的优化。最后，有访问技术希望优化与IoT服务一起使用的应用程序和框架层，并访问网络特定的优化。这些访问优化正在由3GPP，IEEE 802.11和802.15，Bluetooth SIG，Weightless SIG等开发。

这是很多标准，在这里不可能覆盖所有的标准。考虑到这一点，让我们来看看在这个频谱范围内开发的一些主要标准在2015年中期的位置，以及每个人的预后。

线程组

线程是最小的标准组合之一，但可以说是最有势头的，这得益于IoT（现在由Google母公司由Alphabet拥有）的海报小组Nest的支持。线程是一个雄心勃勃的，以无线为中心的标准，涵盖网络，节能，安全和产品兼容性。此外，每个线程认证的设备都获得IPv6地址，这可以最终缓解IoT设备的网络问题，因为IPv6获得更多的牵引力。

Grid Connect公司的副总裁Adam Connect表示：“线上公司正在为智能传感器提供工业和住宅用途，”Thread现在有了一个规范，并且正在推出2016年发布的产品。线程看起来是一个有希望的新型无线网络标准应该对ZigBee和Z-Wave进行网状网络的改进。“ ZigBee联盟最近与Thread合作，这将为新标准提供更多的可见性。

CipherCloud的云安全和策略副总裁陈曦补充说，线程有很大的潜力。 “线程的基于IP的网状网络协议在业界得到了很好的体现，并且在业界得到广泛应用。网状网络的概念在互连设备环境中运行良好，在这些环境中，没有任何设备成为单点故障。看好这个协议的未来。“

拥有超过80个成员，包括三星和飞利浦，现在已经成为集团的一部分，尽管青年时代，Thread还是标准组织的前瞻性。

AllSeen联盟/ AllJoyn

AllJoyn协议最初由高通公司设计，现在由Linux基金会管理，是成为AllSeen联盟的标准，该联盟是第一个正式启动的重要的IoT标准组织。 AllJoyn是一个开源框架，用于指导IoT设备的连接和服务层操作，以“创建可与其他附近设备，系统和服务直接发现，连接和交互的互操作产品，而不管传输层，设备类型，平台，操作系统或品牌。“具体来说，AllJoyn并不是一个无线电协议，不同于线程，所以这两个可能能够和平共存。

IoT安全设备平台开发商IControl Networks首席技术官Corey Gates指出：

AllJoyn定义了一种安全加入协议，可以实现Wi-Fi网络中的对等设备之间的通信。虽然没有明确要求Wi-Fi，AllJoyn是开发Wi-Fi的。 AllJoyn定义了设备可以实现的服务接口，以实现各种功能。 AllJoyn没有专门定义设备类型，而是设备可以支持或交互的服务。几家公司已经建立了概念证明，AllJoyn兼容设备，但很少有上市。目前，大部分重点是音频流和控制以及家庭路由服务。

正义指出，尽管今天，AllSeen联盟拥有170多个成员，其中包括微软，索尼和Lowe，“在产品出货和宣传AllJoyn兼容性方面，市场上看不到太多。”也就是说，该集团继续快速增长，定期拾起蓝筹股，而且在今年的消费电子展（CES）上确实有一席之地。

开放互连联盟/ IoTivity

英特尔在线上同时成立了开放互连联盟，但吸引力和兴趣并没有像Nest支持的组织那样高。伊斯兰会议组织在很大程度上被视为对AllSeen巨人的回应。更具体地说，它被视为对高通的直接攻击。今年的大部分标准对话涉及到这两个知识产权集团之间的冲突，最终导致AllSeen联盟承诺，任何一个成员都不会起诉任何使用AllSeen标志进行专利侵权的人。

今年早些时候，OIC发布了一个名为IoTivity的规范，即设备到设备通信的另一个框架，以及AllJoyn的直接竞争对手，尽管IoTivity设备尚未进入市场。 （IoTivity博客仍然只有一个帖子，日期为2014年12月）

也就是说，AllSeen没有太多的开始，伊斯兰会议组织继续成为会员。据我所知，该集团目前拥有近100名成员，其中包括与DLNA和UPnP论坛的重要联络协议。

工业互联网联盟

顾名思义，工业互联网联盟（IIC）成立于2014年3月，正在制定与物联网的工业应用相关的指导原则。主要由GE，IBM，思科，AT＆T以及英特尔等大型企业支持。 （这五家公司在IIC指导委员会有常任理事国。）

IIC表示，它不是开发自己的标准，而是正在通过识别，组装和推广最佳实践，汇集加速工业互联网发展所必需的组织和技术。“ Gartner质疑了联盟的相关性，但IIC在今年夏天早些时候发布了其工业互联网参考架构。虽然不是标准，但是该文件“概述了工业互联网系统的关键特征，在部署工业互联网解决方案之前必须考虑的各种观点，以及对工业互联网的关键问题的分析，包括安全和隐私，互操作性和连接性， “根据美国商业资讯。行业回应尚未确定。

ITU-T SG20

国际电信联盟成立于2015年6月，其新兴标准不仅涵盖了物联网，还包括“聪明的城市和社区（SC＆C）”。 SG20标准“负责国际标准，以实现物联网技术的协调发展，包括机对机通信和普遍存在的传感器网络。

ITU-T标准的一个问题是美国没有任何重大的参与，但是Kon是一个粉丝，他说：“我认为SG20将会出现，他们拥有最大的权力和最大的支持[在全球范围内]，但是当世界已经实施物联网时，他们仍处于研究阶段。“

IEEE P2413

自然而然，IEEE正在采取行动，而有名的组织则指出：“在IEEE中，有适用于IoT的350多种IEEE标准，其中40项正在修订，以更好地支持IoT。此外，还有更多的在不同的发展阶段超过110个新的IoT相关的IEEE标准，IEEE也赞助了10个或更多不同的IoT倡导和支持组织。

这是很多的标准化，但它是IEEE项目P2413作为所有这一切的伞。再次，积极的目标是建立一个“涵盖基础架构构建块的定义及其集成到多层系统的能力”的参考架构。

IoT服务公司Greenwave Systems的首席科学家和技术传播者Jim Hunter指出，与IEEE一样，我们看到了一个趋势的开始，这种趋势往往会影响标准制定：伙伴关系和协作。 “某些标准组织正在开始合作，”他表示，“将出现一个更广泛扩散的标准，最引人注目的是，IEEE IoT Architecture小组为定义IoT的架构标准所做的巨大工作范围，P2413正在建立联络IIC，2MM以及其他几个IoT工作组，这里的工作很早，主要集中在研究和数据收集阶段。

Apple HomeKit

苹果公司的折扣将是愚蠢的，苹果公司的HomeKit是“在用户家庭中与连接配件进行通信和控制的框架”。当然，这并不像苹果专有的做事方式那么标准。应用开发商和硬件制造商可以选择加入俱乐部或留在围墙花园外面。

不过，Hunter说“HomeKit”并没有像预期的那样起飞，其中一个重要原因似乎是苹果公司坚持采用尖端的3072位加密密钥和由Wi-Fi和蓝牙设备使用的Apple认证的芯片。现有设备必须决定是否重新设计现有的产品线，以便启用HomeKit支持。“

另一方面：HomeKit设备实际上是运输，没有什么比货架上的实际产品更符合标准。

摇摆不可避免

最终，这些标准中的一个以上可能会减少，但是他们是否在市场上有很大的不同之处还有待观察：“所有这些标准都处于通量状态，”首席技术官Dave Evans说，的Stringify。 “现在说哪些都会被留下来还为时过早，其中一些甚至在12至18个月前都没有存在，毫无疑问，在接下来的几年里，我们会看到更多的东西。

物联网（IoT）是一个相互关联的计算设备，机械和数字机器，物体，动物或人类的系统，它们具有唯一的标识符，并且能够通过网络传输数据，而不需要人与人或人 电脑互动“。

- 物联网议程上的“物联网”。

仍然不知道物联网系统如何运作？

我不怪你虽然快速的Google搜索将会提供大量的文章和帖子，解释物联网是什么以及其许多潜在的好处，但是并没有明确物联网系统如何实际运作。

作为Leverege的业务发展总监，我经常发现自己澄清那些非技术性的人。所以，作为一个非技术性的人，我自己（在布朗，我是哲学专业），这里是一个以简单的非技术术语解释的物联网。

物联网解释

完整的IoT系统集成了四个不同的组件：传感器/设备，连接，数据处理和用户界面。下面我将简要介绍一下每个组件及其功能。

1）传感器/设备

首先，传感器或设备从他们的环境中收集数据。这可能像温度读数一样简单，或者像完整的视频馈送一样复杂。

我使用“传感器/设备”，因为可以将多个传感器捆绑在一起，或者传感器可以作为不仅仅是检测事物的设备的一部分。例如，您的手机是具有多个传感器（相机，加速度计，GPS等）的设备，但您的手机不仅仅是传感器。

然而，无论是独立的传感器还是完整的设备，在第一步中，数据是从环境中收集的。

2）连接

接下来，这些数据被发送到云端（什么是云端），但它需要一种方式才能到达！

传感器/设备可以通过多种方式连接到云端，包括：蜂窝，卫星，WiFi，蓝牙，低功耗广域网（LPWAN），或通过以太网直接连接到互联网。

每个选项在功耗，范围和带宽之间进行权衡（这里是一个简单的解释）。选择哪个连接选项最好归结于特定的IoT应用程序，但它们都完成了相同的任务：将数据传输到云端。

3）数据处理

一旦数据进入云端，软件就可以进行某种处理。

这可能非常简单，例如检查温度读数是否在可接受范围内。或者也可能非常复杂，例如使用视频上的计算机视觉来识别物体（如您家中的入侵者）。

但是，当温度过高或者家中是否有入侵者会发生什么？这就是用户进来的地方。

4）用户界面

接下来，这些信息以某种方式对终端用户有用。这可能是通过对用户的警报（电子邮件，文本，通知等）。例如，当公司的冷库中的温度过高时，文字提醒。

此外，用户可能有一个允许他们主动登录系统的界面。例如，用户可能想要通过电话应用程序或网络浏览器检查他们家中的视频馈送。

但是，并不总是单向街道。根据IoT应用，用户也可以执行动作并影响系统。例如，用户可以通过手机上的应用程序远程调节冷库中的温度。

并且自动执行一些操作。而不是等待您调整温度，系统可以通过预定义的规则自动进行。而不是只是打电话给你提醒你一个入侵者，物联网系统也可以自动通知有关当局。

概述 - 物联网系统如何运作

IoT系统由通过某种连接与云“通话”的传感器/设备组成。一旦数据进入云端，软件就会处理它，然后可能决定执行一个动作，例如发送警报或自动调整传感器/设备，而不需要用户。

但是如果需要用户输入，或者用户只需要在系统上登录，用户界面就可以这样做。然后，用户进行的任何调整或操作都将以相反的方向通过系统发送：从用户界面到云端，并返回到传感器/设备进行某种更改。

真正的物联网（IoT）要求“事物”能够使用互联网协议。互联网上一直存在着各种各样的“事情”，数据中心和家庭的通用计算机通常可以使用互联网协议，因为它们已经被定义了。然而，将互联网扩展到通常需要优化版本或特殊使用这些协议的更受约束的设备具有相当大的价值。

背景

在过去十年中，已经开展了各种IETF活动，以便广泛的事情使用互操作技术进行通信，从相当小的微控制器传感器到数据中心的大型计算机。

当我们在2010年IETF杂志上写到关于IoT的文章时，有三个IETF工作组（WG）专注于约束设备和网络的IoT：6LoWPAN，它定义适合于受限无线电链路的IPv6适配层和报头压缩; ROLL专注于约束节点网络的路由协议;和CoRE，旨在将Web架构扩展到大多数受限网络和嵌入式设备。关于物联网的活动自2010年以来有所增加，今天我们有七个工作组积极研究物联网的各个方面（另外两个已经完成），以及专注于开放式物流研究问题的互联网研究任务组（IRTF）研究小组。

IETF IoT活动

第一个IETF IoT工作组，IPv6 over低功耗WPAN（6LoWPAN），于2005年3月被授权。它定义了将IPv6适配到使用非常小的数据包大小的IEEE 802.15.4（WPAN）网络的方法，通过头压缩和优化为邻居发现。 6LoWPAN工作组于2014年完成，6Lo工作组取而代之的是将相似的适应机制应用于更广泛的无线电技术，包括“蓝牙低能耗”（RFC 7668），ITU-T G.9959（Z-Wave ，RFC 7428）和数字增强无绳电信（DECT）超低能耗（ULE）无绳电话标准以及低成本有线网络技术主从通/令牌传递（MS / TP），广泛应用于RS- 485楼宇自动化。

低功耗和有损网络路由（ROLL）WG为RPL协议“低功耗和有损网络的IPv6路由协议”（RFC 6550）制定了一系列相关扩展，包括各种路由度量，目标函数，和组播。 ROLL的另一个输出是一些需求文件和适用性声明，术语文档和安全威胁分析。

受约束的RESTful环境（CoRE）WG仍然是最活跃的IoT组之一。其主要产品围绕“约束应用协议”（CoAP，RFC 7252），基于UDP的基于UDP的模拟。 CoAP扩展功能可以实现组通信（RFC 7390）和低复杂度服务器推送资源观察（RFC 7641）。这是基于适用于约束设备（RFC 6690）的weblink格式的发现和自我描述机制的补充。当前的工作组活动侧重于扩展，可以传输大量资源，使用资源目录来协调发现，可重用的接口描述以及通过TCP和TLS传输CoAP。 CoRE工作组正在重新考虑，包括RESTCONF风格的管理职能和通过CoAP发布订阅风格的沟通。 CoRE还在研究一种表示传感器测量的数据格式，这将受益于“简明二进制对象表示”（CBOR）（RFC 7049），这是针对二进制数据和低资源实现进行优化的JSON模拟器。

自2010年以来，很明显，物联网在没有安全保障的情况下不会奏效。因此，大多数新的物联网工作组已在安全区域中添加。受约束环境（DICE）工作组（DICE）工作组（已完成）的DTLS生成了适用于受限制的物联网设备的TLS / DTLS配置文件。约束环境的认证和授权（ACE）WG正在开发用于访问受限环境中服务器上托管的资源的身份验证授权机制，并且最近完成了一个综合用例文档（RFC 7744）。这项工作得到了最近授权的COSE工作组的支持，该工作组正在为JOSE工作组开发的JSON对象签名和加密方法构建简化的CBOR模拟。

作为一项特别的开发，超过了6Lo的工作，6TiSCH WG（IPv6 over TSCH模式的IEEE 802.15.4e）在2014年被授权，以使IPv6能够实现最近添加到IEEE的时隙信道跳跃（TSCH）模式802.15.4网络。这项工作旨在利用TSCH的确定性，实时导向特征，并包括架构，信息模型和配置方面。 6TiSCH概述和问题陈述文件（RFC 7554）于2015年发布;一个最小配置接口的规范是下一行。

除了由IETF工作组开发的新协议和其他机制之外，受限环境的互联网协议常常受益于有效实施技术和其他考虑的其他指导。轻量级实施指导（LWIG）工作组正在开展此类文件，包括CoAP和IKEv2协议，非对称加密技术和蜂窝网络中的CoAP。 LWIG工作组发布了RFC 7228，它定义了受限节点网络的常用术语。

除IETF专门关注物联网方案之外，整个Web协议栈正在快速发展，其他IETF工作组开发的许多新技术也将最终也被用于物联网。由于具有更紧凑的线格式和简化的处理规则，HTTPbis WG最近确定了HTTP / 2协议的规范，该规范比早期版本的HTTP更适合于IoT场景。 TLS工作组正在定义TLS版本1.3，包括DTLS 1.3，可以更有效地建立安全的传输会话，因此更适合于物联网。 Homenet工作组正在致力于在家庭及其他地方自动配置IPv6网络。与IETF的标准化工作相似，IRTF的两个研究小组特别感兴趣：ICNRG（信息中心网络），探讨其技术在物联网场景中的适用性，以及进行先进加密基础的CFRG（Crypto Forum），如新椭圆曲线加密（ECC）曲线将更适合于IoT用例。最后，互联网架构委员会（IAB）正在组织多个相关研讨会（例如关于安全性，架构和语义互操作性），并发布了诸如“智能对象网络中的架构注意事项”（RFC 7452）等信息文件。

虽然以物联网为导向的IETF工作组已经产生了关于物联网成熟标准的第一波浪潮，但是基于这些标准的使用，正在出现新的研究问题。 IRTF Thing-to-Thing研究组（T2TRG）于2015年被授权，以调查物联网的开放性研究问题，重点关注在IETF展示标准化潜力的问题。正在探讨的主题包括受限节点网络的管理和运行，安全和生命周期管理，在物联网场景中使用REST范式的方法以及语义互操作性。对于在物联网地区活跃的其他团体的追随和贡献也有很大的兴趣。例如，W3C Web of Things（WoT）兴趣小组最近开始了活动，两个小组一直在共同探讨物联网和Web技术的未来。

结论

IETF已经有十年的历史，指定和记录关键的物联网标准和指导，今天在物联网方面比以往任何时候都有更多的活动。从事物联网的其他组织和联盟已经采用互联网协议栈作为其解决方案的基础。 IP，特别是IPv6是网络的明显选择，但IETF IoT堆栈的其余部分，包括CoAP和DTLS也被广泛使用。今天在RFC中发布的基础IETF IoT协议栈是成熟的，适合部署。标准化的其他需求正在出现，IETF和IRTF的活跃团体正在努力确保其被识别和解决。

物联网设备和应用程序涉及协议的概述。 帮助澄清IoT层技术栈和头对头比较。

物联网涵盖了广泛的行业和用例，从单一受限制的设备扩展到大量跨平台部署嵌入式技术和实时连接的云系统。

将它们捆绑在一起是许多传统和新兴的通信协议，允许设备和服务器以新的，更互联的方式相互通信。

同时，数十个联盟和联盟正在形成，希望能够统一断层和有机的物联网景观。

以下频道指南：

提供有助于IoT设备，应用程序和应用程序的热门协议和标准的概述列表

深入了解特定层次或行业特定协议

列出流行协议的头对头比较（即：mqtt vs xmpp）

协议

我们已经将协议分解成以下层，以提供一定程度的组织，而不是试图将所有的IoT协议都适合现有的体系结构模型（如OSI模型）

基础设施（例如：6LowPAN，IPv4 / IPv6，RPL）

识别（例如：EPC，uCode，IPv6，URI）

通讯/交通（例如：Wifi，蓝牙，LPWAN）

发现（例如：Physical Web，mDNS，DNS-SD）

数据协议（例如：MQTT，CoAP，AMQP，Websocket，Node）

设备管理（例如：TR-069，OMA-DM）

语义（例如：JSON-LD，Web Thing模型）

多层框架（例如：Alljoyn，IoTivity，Weave，Homekit）

安全

行业垂直（连接家庭，工业等）

基础设施

IPv6- “IPv6，是用于分组交换网络互联的互联网层协议，并提供跨多个IP网络的端到端数据报传输。

6LoWPAN - “6LoWPAN是IPv6低功耗无线个人区域网络的首字母缩略词，它是适用于IPv6 over IEEE802.15.4链路的适配层，该协议仅在2.4 GHz频率范围内运行，传输速率为250 kbps。

UDP（用户数据报协议） - 基于互联网协议（IP）的客户端/服务器网络应用程序的简单OSI传输层协议。 UDP是TCP的主要替代品，并且是1980年引入的最早的网络协议之一。UDP经常用于专门用于实时性能的应用中。

- QUIC（快速UDP Internet连接，发音为quick）支持通过用户数据报协议（UDP）的两个端点之间的一组多路复用连接，旨在提供与TLS / SSL相当的安全保护以及减少的连接和传输延迟，以及带宽估计在每个方向避免拥塞。

- Aeron - 高效可靠的UDP单播，UDP组播和IPC消息传输。

uIP - uIP是一种可用于微型8位和16位微控制器的开源TCP / IP协议栈。它最初由瑞典计算机科学研究所“网络嵌入式系统”组织的Adam Dunkels开发，根据BSD样式许可证许可，并由广泛的开发人员进一步开发。

DTLS（数据报传输层） - “DTLS协议为数据报协议提供通信隐私协议允许客户端/服务器应用程序以防止窃听，篡改或消息伪造的方式进行通信，DTLS协议基于传输层安全（TLS）协议，并提供等效的安全保证。“

ROLL / RPL（低功耗/有损网络的IPv6路由）

NanoIP

“NanoIP代表了”纳米互联网协议“，这个概念是为嵌入式和传感器设备提供类似互联网的服务，而无需TCP / IP的开销。NanoIP的设计是以最少的开销，无线网络和本地铭记在心“。

以内容为中心的网络（CCN） - 技术概述

“下一代网络架构解决了内容分发可扩展性，移动性和安全性方面的挑战。

CCN直接在网络的数据包层级路由和传递命名的内容，从而在内存中自动进行应用中立的缓存，无论它位于网络中。结果？无论何时何地需要，内容的高效有效的传递。由于架构可以将这些缓存效应作为分组传送的自动副作用，因此可以使用内存，而无需构建昂贵的应用程序级缓存服务。

时间同步网格协议（TSMP）

一种用于自组织网络的通信协议，称为无线设备。 TSMP设备保持彼此同步并在时隙中进行通信，与其他TDM（时分复用）系统类似。

发现

mDNS（组播域名系统） - 将主机名解析为不包含本地名称服务器的小型网络内的IP地址。

物理Web - 物理Web可以让您看到一个使用蓝牙低能耗（BLE）信标在您周围环境中的对象广播的URL列表。

HyperCat -一种开放，轻量级的基于JSON的超媒体目录格式，用于显示URI的集合。

UPnP（通用即插即用） - 现在由Open Connectivity Foundation管理的是一组网络协议，允许网络设备无缝地发现对方在网络上的存在，并建立用于数据共享，通信和娱乐的功能网络服务。

数据协议

MQTT（消息队列遥测传输）

“MQTT协议以非常轻便的方式实现发布/订阅消息传递模型，对于需要较小代码占用空间和/或网络带宽非常重要的远程位置的连接很有用。

- 其他资源

MQTT-SN（用于传感器网络的MQTT） - 专为机器到机器和移动应用设计的开放轻量级的发布/订阅协议

-Mosquitto：一个开源MQTT v3.1代理

- IBM MessageSight

CoAP（约束应用协议）

CoAP是一种应用层协议，旨在用于资源受限的互联网设备，如WSN节点，CoAP旨在轻松转换为HTTP，以简化与Web的集成，同时满足诸如组播支持等特殊要求低开销和简单性CoRE组为CoAP提出了以下功能：RESTful协议设计，最小化使用HTTP映射的复杂性，低标头开销和解析复杂性，URI和内容类型支持，支持发现由已知的CoAP服务。简单的资源订阅以及结果推送通知，基于最大时间的简单缓存。“

- 其他资源

- SMCP- 适用于嵌入式环境的基于C的CoAP堆栈。功能包括：支持draft-ietf-core-coap-13，完全异步I / O，支持BSD套接字和UIP。

STOMP - 简单文本定向消息协议

XMPP（可扩展消息和存在协议）

“用于实时通信的开放技术，其功能包括即时消息，存在，多方聊天，语音和视频通话，协作，轻量级中间件，内容联合以及XML数据的广义路由等广泛应用。

- 其他资源

- XMPP-IoT

“在XMPP的同一个庄园里，默默地创造了人与人之间的通信互操作性，我们的目标是使通信机对人和机器进行机器互操作。

Mihini / M3DA

“Mihini代理是一个软件组件，作为M2M服务器和在嵌入式网关上运行的应用程序之间的中介者。M3DA是针对二进制M2M数据传输进行优化的协议，它在Mihini项目中可用于手段的设备管理，通过简化设备数据模型的操作和同步，以及通过允许用户应用程序与M2M服务器来回交换数据/命令的手段来进行资产管理，以优化带宽使用的方式“

AMQP（高级消息队列协议）

“面向消息的中间件的开放标准应用层协议AMQP的定义特征是消息导向，排队，路由（包括点对点和发布和订阅），可靠性和安全性。

- 其他资源

DDS（实时系统数据分发服务）

“第一个开放的国际中间件标准直接针对实时和嵌入式系统的发布订阅通信。

JMS（Java消息服务） - 一种面向Java消息的中间件（MOM）API，用于在两个或多个客户端之间发送消息。

LLAP（轻量级本地自动化协议）

“LLAP是一个简单的短消息，它使用正常文本在智能对象之间发送，它不像TCP / IP，蓝牙，zigbee，6lowpan，WiFi等，它们在低级别实现”如何“移动数据，这意味着LLAP可以运行在任何通信媒介上，LLAP的三个优点是，它将在任何现在，任何未来的任何事情上运行，人类很容易理解。

LWM2M（轻量级M2M）

“轻量级M2M（LWM2M）是开放移动联盟的系统标准，包括DTLS，CoAP，Block，Observe，SenML和资源目录，并将其编入设备 - 服务器界面以及对象结构。

SSI（简单传感器接口）

“设计用于计算机或用户终端与智能传感器之间数据传输的简单通信协议”

反应流

“用于JVM上非阻塞背压的异步流处理标准”。

ONS 2.0

REST（表示状态转移） - RESTful HTTP

- 物联网上下文中的附加资源

HTTP / 2- 通过引入头字段压缩并允许在同一连接上进行多个并发交换，可以更有效地利用网络资源和减少对延迟的感知。

SOAP（简单对象访问协议），JSON / XML，WebHooks，Jelastic，MongoDB

Websocket

WebSocket规范 - 作为HTML5计划的一部分开发 - 引入了WebSocket JavaScript接口，该界面定义了一个全双工单一套接字连接，客户端和服务器之间可以发送消息。 WebSocket标准简化了双向Web通信和连接管理的复杂性。

JavaScript / Node.jsIoT项目

可以在这里找到一个名为Contit，Riot OS等的IoT软件项目列表。

通讯/传输层

以太网

WirelessHart

“WirelessHART技术为各种过程测量，控制和资产管理应用提供了强大的无线协议。”

DigiMesh

“DigiMesh是一种用于无线端点连接解决方案的专有点对点网络拓扑。

ISA100.11a

“ISA100.11a是由国际自动化学会（ISA）开发的无线网络技术标准，官方描述为”工业自动化无线系统：过程控制及相关应用“

IEEE 802.15.4

IEEE 802.15.4是一种标准，用于指定低速率无线个域网（LR-WPAN）的物理层和媒体访问控制。它由IEEE 802.15工作组维护。它是ZigBee，ISA100.11a，WirelessHART和MiWi规范的基础，每个规范通过开发未在IEEE 802.15.4中定义的上层进一步扩展标准。或者，它可以与6LoWPAN和标准互联网协议一起使用来构建无线嵌入式互联网。

NFC

基于标准ISO / IEC 18092：2004，使用中心频率为13.56 MHz的电感耦合器件。与无线传感器网络相比，数据速率高达424 kbps，范围短于几米。

蚂蚁

ANT是一种专有的无线传感器网络技术，具有无线通信协议栈，使得能够在2.4 GHz工业，科学和医疗分配RF频谱（“ISM频带”）中运行的半导体无线电通过建立共存的标准规则进行通信，数据表示，信令，认证和错误检测。

蓝牙

蓝牙工作在2.4 GHz ISM频段，并使用跳频。数据速率高达3 Mbps，最大范围为100m。可以使用蓝牙的每个应用程序类型都有自己的配置文件。

Eddystone - 定义接近信标消息的蓝牙低功耗（BLE）消息格式的协议规范。

ZigBee

ZigBee协议使用802.15.4标准，并在2.4 GHz频率范围内工作，速度为250 kbps。网络中的最大节点数为1024，范围可达200米。 ZigBee可以使用128位AES加密。

EnOcean

EnOcean是一种能量收集无线技术，其工作频率为欧洲868 MHz，北美为315 MHz。发射范围在建筑物中可达30米，室外可达300米。

无线上网

WiMax

WiMax基于标准的IEEE 802.16，适用于无线城域网。固定电台的范围是不同的，在那里它可以达到50公里，移动设备有5到15公里。 WiMAx以2.5 GHz至5.8 GHz的频率运行，传输速率为40 Mbps。

LPWAN

无重量

无重量是一种专有的开放式无线技术标准，用于在基站和数千台机器之间交换数据（使用空闲电视传输通道中的波长无线电传输），具有高度的安全性。

NB-IoT（窄带IoT）由3GPP标准体系标准化的技术

LTE-MTC（LTE机器类型通信） - 基于标准的技术系列支持适用于物联网的几种技术类别，如Cat-1和CatM1。

EC-GSM-IoT（扩展覆盖 - GSM-IoT） - 为LPWA（低功率广域）IoT应用实现现有蜂窝网络的新功能。 EC-GSM-IoT可以通过部署在非常大的GSM足迹上的新软件来激活，从而为服务IoT设备增加更多的覆盖范围。

LoRaWAN - 用于无线电池操作的网络协议区域，国家或全球网络中的任务。

RPMA（随机相位多址）采用具有多路访问的直接序列扩频（DSSS）技术的通信系统。

手机：

GPRS / 2G / 3G / 4G蜂窝

- 在这里查看有关物联网通信和技术的更完整的概述。

语义

IOTDB

“用于描述物联网的JSON /链接数据标准”

SensorML

“SensorML为描述传感器和测量过程提供了标准模型和XML编码。”

语义传感器网络本体 - W3C

“这个本体论描述了传感器和观察结果以及相关的概念，它并没有描述域名概念，时间，位置等，这些概念是通过OWL导入从其他本体中被包含的。”

Wolfram语言 - 连接的设备 - “每个设备的符号表示，然后有一组标准的Wolfram语言功能，如DeviceRead，DeviceExecute，DeviceReadBuffer和DeviceReadTimeSeries，执行与设备相关的操作。

RAML（RESTful API建模语言） - 可以轻松管理从设计到共享的整个API生命周期。简明扼要 - 您只需编写您需要定义的内容，并可重复使用。

SENML（传感器标记语言的介质类型）- 简单的传感器，如温度传感器，可以在诸如HTTP或CoAP之类的协议中使用此介质类型来传输传感器的测量值或进行配置。

LsDL（Lemonbeat智能设备语言）- 面向服务的设备的基于XML的设备语言

多层框架

Alljoyn - 一个开放源码的软件框架，可让设备和应用程序轻松发现和沟通。

IoTivity是由Linux基金会托管的开放源码项目，由伊斯兰会议组织赞助。

IEEE P2413 - 物联网建筑框架标准（IoT）

线程 - 基于开放标准和IPv6技术，以6LoWPAN为基础。

IPSO应用程序框架（PDF）

“这个设计定义了一组REST接口，可以由智能对象使用它来表示其可用资源，与其他智能对象和后端服务交互。该框架旨在与现有的Web配置文件（包括SEP2和oBIX）相辅相成。

OMA LightweightM2M v1.0

“LightweightM2M的动机是开发一种快速可部署的客户端 - 服务器规范来提供机器到机器服务。

LightweightM2M主要是一种设备管理协议，但它应该被设计为能够扩展以满足应用程序的要求。轻量级M2M不限于设备管理，应该能够传输服务/应用数据。“

编织 - 用于物联网设备的通信平台，可实现设备设置，手机到设备到云的通信以及来自移动设备和网络的用户交互。

Telehash- JSON + UDP + DHT =自由

一种安全的线路协议，为应用和设备提供分散式覆盖网络

安全

开放信任协议（OTrP） - 安装，更新和删除应用程序以及管理受信任执行环境（TEE）中的安全配置的协议。

X.509 - 用于管理数字证书和公钥加密的公钥基础设施（PKI）标准。用于保护网络和电子邮件通信的传输层安全协议的关键部分。

垂直具体

IEEE 1451：

IEEE 1451是智能传感器接口标准系列，描述了一组用于将传感器（传感器或执行器）连接到微处理器，仪表系统和控制/现场网络的开放，通用，独立于网络的通信接口。

IEEE 1888.3-2013- “无线普及绿色社区控制网络安全标准”

IEEE 1905.1-2013 - “IEEE Standard for a Convergent Digital Home Network for Heterogeneous Technologies”

IEEE 802.16p-2012 - “IEEE宽带无线接入系统空中接口标准”

IEEE 1377-2012 - “IEEE工业计量通信协议应用层标准”

IEEE P1828 - “虚拟组件系统标准”

IEEE P1856“电子系统预测与健康管理标准框架”

架构和图形

Credit: Simon Ford - Director of IoT Platforms ARM

Graphic via Ronak Sutaria and Raghunath Govindachari from Mindtree Labs in "Making sense of interoperability:Protocols and Standardization initiatives in IOT"

IoT Communication stack from IoT-A Initiative

"The communication model aims at defining the main communication paradigms for connecting entities, as defined in the domain model. We provide a reference communication stack, together with insight about the main interactions among the actors in the domain model. We developed a communication stack similar to the ISO OSI 7-layer model for networks, mapping the needed features of the domain model unto communication paradigms. We also describe how communication schemes can be applied to different types of networks in IoT."

David E Culler Open Standards Reference Model

Above Graphic: David E. Culler - The Internet of Every Thing - steps toward sustainability CWSN Keynote, Sept. 26, 2011 (Download PPT)

Graphic: Sensinode: - Zach Shelby: Is the Internet Protocol enough?

Graphic: EU Butler Project - Communication Issues

联盟和组织

组织机构：

ETSI（欧洲电信标准协会）

- 连接事物群集

IETF（互联网工程任务组）

- CoRE工作组（约束RESTful环境）

- 6lowpan工作组（IPv6 over Low Power WPAN）

- ROLL工作组（低功耗和有损网络）

IEEE（电气与电子工程师协会）

- IoT“创新空间”

OMG（对象管理组）

- 数据分发服务门户

OASIS（结构性信息提升标准组织）

- MQTT技术委员会

OGC（开放地理空间联盟）

- IoT标准工作组的传感器Web

IoT-A

“针对物联网的欧洲灯塔综合项目，提出了建立一个建筑参考模型以及初始的关键构件块的定义。”

OneM2M

“oneM2M的目标和目的是开发技术规范，解决需要一个可以容易地嵌入到各种硬件和软件中的普通M2M服务层，并依靠将现场无数设备与全球M2M应用服务器连接“。

OSIOT

“一个单一的重点是为新兴物联网开发和推广免版税，开源标准的组织。”

IoT-GSI（物联网全球标准倡议）

ISA国际自动化学会

W3C

- 语义传感器网络本体论

- 物联网社区小组

EPC全球

IEC（国际电工委员会）和ISO（国际标准化组织）通过JTC（联合技术委员会）。委员会页

RRG（路由研究组）

HIPRG（主机身份协议研究组）

Eclipse Paho项目

“Paho项目的范围是提供开源和标准消息传递协议的开源实现，支持目前和新兴的M2M与企业中间件和应用程序集成的需求，包括客户端实现，以及相应的服务器支持由社区决定。“

OpenWSN

“作为使用各种硬件和软件平台的基于物联网标准的协议栈的开源实现的存储库。

CASAGRAS

“我们是代表欧洲，美国，中国，日本和韩国的重要的国际合作伙伴，他们加入了欧盟资助的第七个框架计划，该计划将着眼于RFID的全球标准，监管和其他问题及其在实现”物联网“。

联盟

AllSeen联盟

“AllSeen联盟是一个非营利组织，致力于通过一个开放的，通用的发展框架，支持和驱动广泛采用的产品，系统和服务，支持全球互联网，由充满活力的生态系统和蓬勃发展的技术社区支持，

IPSO

“该联盟是一个全球性的非营利组织，为各种社区服务，旨在通过为公众提供协调一致的营销努力，建立互联网协议作为智能对象连接的网络。”

Wi-SUN联盟

Wi-SUN联盟旨在“通过推动基于IEEE 802.15.4g标准的全球区域市场互操作性来推进无缝连接”。

OMA（开放移动联盟）

“OMA是开发市场驱动，互操作的移动服务推动者的领先行业论坛”

- OMA LightweightM2M v1.0

工业互联网联盟

“成立于2014年，进一步开发，采用和广泛使用互连机器，智能分析和工作人员”

 

本文：https://pub.intelligentx.net/overview-protocols-involved-iot-devices-and-applications

讨论：请加入知识星球或者小红圈【首席架构师圈】

此页尝试记录各种MQTT服务器(代理)支持的特性。这是特定于他们的MQTT支持的。这些服务器中有许多具有比MQTT更广泛的功能。

能力

Server	QoS 0	QoS 1	QoS 2	auth	Bridge	$SYS	SSL	Dynamic topics	cluster	websockets	plugin system	Mqtt 5 support	Active development
Aedes	✔	✔	✔	Username/ Password	rm	✔	✔	✔	✔	✔	✔	✘	✔
AWS IoT Services	✔	✔	✔	Client certificates	?	✘	✔	§	✔	✔	✘	✘	✔
Apache ActiveMQ Artemis	✔	✔	✔	JAAS	✘	✘	✔	✔	✔	✔	✔	✘	✔
BevywiseIoT Platform	✔	✔	✔	Key based	✔	✔	✔	✔	✔	✔	rm	✘	✔
ClearBlade	✔	✔	✔	OAuth based User/Pass & Per-channel authorization	?	✔	✔	✔	✔	✔	?	✘	✔
ejabberd	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔
emitter	✔	✘	✘	Per-channel authorization	✘	✘	✔	✔	✔	✔	✘	✘	✔
EMQ X	✔	✔	✔	Username /Password, JWT, LDAP, ClientID, ...	✔	✔	✔	✔	✔	✔	✔	✔	✔
flespi	✔	✔	✔	✔	✘	✘	✔	✔	✔	✔	✘	✘	✔
GnatMQ / M2MQTT	✔	✔	✔	Username Password	✘	✘	✔	✔	✘	✘	✘	✘	✔
HBMQTT	✔	✔	✔	Username/ Password, Client certificates	✔	✔	✔	✔	✘	✔	✔	✘	✔
HiveMQ	✔	✔	✔	Username/ Password	✔	✔	✔	✔	✔	✔	✔	✔	✔
IBM IoT MessageSight	✔	✔	✔	Username/ Password	✔	✔	✔	✔	✔	✔	✔	✘	✔
IBM Watson IoT Platform	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✘	✔
IBM WebSphere MQ Middleware	✔	✔	✔	Username/ Password, Client certificates	✔	✔	✔	✔	✔	✔	✘	✘	✔
Jmqtt	✔	✔	✔	Username/ Password, Client certificates	✔	✔	✔	✔	✘	✔	✔	✘	✔
JoramMQ	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✔	✘	✘
Mongoose	✔	✔	✔	✔	✔	✘	✔	✔	✘	✔	✔	✘	✔
moquette	✔	✔	✔	?	✔	✘	✔	✔	rm	✔	✘	✘	✔
mosca	✔	✔	✘	✔	✘	✘	✔	✔	✘	✔	✘	✘	✘
mosquitto	✔	✔	✔	✔	✔	✔	✔	✔	§	✔	✔	✘	✔
MQTT.js	✔	✔	✔	§	✘	✘	✔	✔	✘	✔	✘	✘	✔
MQTTnet	✔	✔	✔	§	§	§	✔	✔	§	§	§	rm	✔
MqttWk	✔	✔	✔	✔	✔	?	✔	✔	✔	✔	✘	✘	✔
RabbitMQ	✔	✔	✘	SASL	✘	✘	✔	✔	✔	✔	✔	✘	✔
Software AG Universal Messaging	✔	✔	✔	✔	§	✘	✔	✔	§	rm	✘	✘	✔
Solace	✔	✔	✘	Basic, client certificate, Kerberos	§	✔	✔	✔	✔	✔	✘	✘	✔
SwiftMQ	✔	✔	✔	✔	✔	✘	✔	✔	✔	✘	✔	✘	✔
TraferoTstack	✔	✔	✔	✔	✘	✘	✔	✔	✘	✘	✘	✘	✘
VerneMQ	✔	✔	✔	Username/ Password	✔	✔	✔	✔	✔	✔	✔	✘	✔

键

• ✔意思是:支持
• ✘的意思是:不支持
• 吗?意思是:未知
• §意思是:看到局限性
• rm的意思是:路线图(计划好的)

已弃用或停止使用的软件/服务

• 2lemetry被亚马逊AWS秘密收购，见techcrunch的文章。
• Apache ActiveMQ Apollo停止运行，见此链接。
• JoramMQ似乎要停产了。
• IBM物联网消息网关现在是IBM Watson物联网平台。
• mosca 停用。
• RSMB现在是软件公司通用消息。然而，文档非常糟糕。
• TraferoTstack自2017年以来没有更新，所以没有真正维护。

限制

• AWS 物联网服务保留了一些以美元开始的主题。
• ClearBlade 保留了一些从$开始的主题。
• mosquitto  通过后台(redis, amqp等)实现mosquito to聚类。
• MQTT.js 将接受提供了用户名和密码的连接，但并不实际验证该连接。
• Software AG Universal Messaging 传递提供了主动/主动集群(通过专有协议)和桥接(通过专有协议)。
• Solace  ”确实为经纪人之间提供了一个专有的桥梁解决方案。
• MQTTnet提供了客户机和服务器实现。所有特性都可以根据需要进行扩展(或保留)。它主要针对。net开发人员来构建他们的自定义服务器和客户端实现。然而，这个标准已经有很多可用的功能。

 

这需要扩大。请在此表中添加关于已知代理的已知信息，并包括任何已知的限制。

对于代理比较(尽管它现在肯定已经过时了)，还请参见https://github.com/mqtt/mqtt.github.io/issues/37和所附的PDF文件。

 

原文：https://github.com/mqtt/mqtt.github.io/wiki/server-support

本文：http://jiagoushi.pro/node/1105

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

 

最近在Exadel，我们遇到了一个有趣的挑战，对物联网的开发者。因为IoT应用程序获得了如此多的动力，所以有越来越多的选择如何开发它们。对于设备通信，两个专门的竞争协议脱颖而出：消息队列遥测传输（MQTT）和约束应用协议（CoAP）。它们都设计为轻量级，并仔细使用稀缺的网络资源。两者都在正确的环境中使用，但问题是，由于物联网发展的相对发展，人们不知道这些协议是什么或何时使用。

这些不是每个人使用的标准Web协议。

鉴于我们自己内部的对话，我决定帮助我们解释这些。首先，我们来看看这些协议是什么。

什么是MQTT？

对于外行人来说，MQTT很像Twitter。这是一个“发布和订阅”协议。您可以订阅某些主题并发布在其他主题上。您将收到有关您订阅的主题的消息，并且订阅您发布的主题的人将收到这些消息。当然有区别。例如，您可以通过保证交付来配置协议更可靠。发布/订阅系统利用一个经纪人，为了进一步推出类比，Twitter平台本身将根据您的订阅偏好过滤消息。

什么是CoAP？

CoAP更像是传统的基于网站的业务，如亚马逊。您要求资源（亚马逊示例中的页面和搜索结果），并且偶尔还会提交您自己的数据（进行购买）。 CoAP被设计为看起来像是兼容HTTP，它支持大多数互联网，因为我们目前知道的。 CoAP可以利用代理服务器，并将其转换成HTTP，或者根据环境限制直接与设计为使用CoAP的特殊服务器进行通信。

你什么时候使用它们？

你可能都在问的问题是，“如果他们很相似，我应该何时使用一个对另一个？”

由于发布/订阅体系结构与中间商中介，MQTT是广域网（WAN，互联网）上的设备之间的通信的理想选择。它在带宽有限的情况下是最有用的，例如远程现场站点或其他缺乏强大网络的区域。 MQTT是Azure和Amazon服务产品的一部分，因此它具有很多已建立的架构，使其易于适应当前的开发人员。

在CoAP的情况下，最强的用例是与HTTP的兼容性。如果您有一个基于Web服务的现有系统，那么在CoAP中添加是一个很好的选择。它建立在用户数据报协议（UDP）上，这在一些资源有限的环境中是有用的。由于UDP允许广播和多播，您可以使用较少的带宽潜在地传输到多个主机。这使得它对于设备需要快速交流的本地网络环境很好，这对于一些M2M设置是传统的。

如果物联网开发人员正在使用将利用现有Web服务器架构的设备，开发人员将使用CoAP。但是，如果开发者正在构建一个设备真正“仅报告”的东西 - 也就是说，它被丢弃在网络上，只需要将数据报告回服务器 - CoAP将会更好。其他用途，如云架构，可能最好用MQTT完成。

MQTT和CoAP的未来

随着时间的推移，对于其他协议，使用或行业采用趋向于向更自由和包容的平台迁移，除非非包容性平台更好。 MQTT和CoAP都是开放标准，任何人都可以实现。 CoAP由标准机构启动，而不是由私有公司（包括IBM）设计的MQTT。 CoAP被设计为处理资源有限的环境，可能是它成为赢家，但是目前MQTT似乎处于领先地位。 MQTT背后有显着的动力 - 大云玩家已经选择了这一势头，或者至少选择它。此外，许多商业用例需要MQTT（存储和转发，集中式主机）的功能。然而，一种可能性是，一些围绕HTTP（例如移动应用程序开发）进行标准化的软件开发可以开始利用CoAP来处理外围设备，并与后端通信，以帮助减少不良连接带宽。

最终，这些协议可以通过互联网有效部署在不同的应用程序中。我们知道有特定的使用案例，其中每个都是最好的，但是我们也知道，物联网和物联网设备将会在复杂性和普及性方面继续发展。对于开发人员来说，了解应用程序的关键差异不仅可以实现更好的初始部署，而且可以为今后的开发工作奠定坚实的基础。

说实话：物联网仍然是一个涉及新技术的新市场，适用于整个物联网空间的标准是罕见的。这是新技术的预期;正如ZDNet的报告，利用企业中的物联网指出：“在物联网的许多领域，毫无疑问，在标准竞争中将会摆脱和整合，而另一个难以置信的CIO则要关注。” [1]

那么你如何利用物联网，你从哪里开始？

实际物联网

在开始物联网项目之前，您将需要放置几个东西。这些包括能够管理设备和数据的跨学科IT组织，确保诸如集成，合规性和安全性等问题成为头脑的系统 - 可能使用沙箱方法 - 并确保您的基础设施可以处理该数据，除非当然，您打算使用云基础设施。

组织买入将是至关重要的，这反过来意味着需要建立稳固的业务案例，以及衡量投资回报率的方法。

总是会有一些行业部门倾向于选择新技术并与之一起运行。然而，在涉及物联网方面，行业经常被认为比较保守，导致了物联网革命。

物联网在行动

对于制造而言，返回有关现实世界的信息的设备只是当前流程的演变。运输行业受益于传感器数据，从而实现预测性维护，物流效率更高，燃油消耗更低。能源公司已投入巨资从智能电表（无需电池）到遥控器和仪表上的传感器。非盈利性减肥SIG [2]的IEEE研究员兼首席执行官威廉·韦伯（William Webb）表示：“石油泵破裂的几分钟内收入的损失是巨大的，所以值得安装IoT系统。

医疗保健是一个不断发展的行业，受益于监控远程设备的能力，包括安装在病人身边的设备，在家中使用IoT设备也在增加。

云可以如何帮助

考虑如何建立自己的物联网专家团队，以及购买和配置支持它所需的基础设施，除了上述不可避免的问题外，可能足以给出任何CIO的意图。

新技术不仅总是昂贵，正确的技能往往是罕见的，所以这是一个更大的挑战。相反，依靠您的系统集成商，他们将能够使用基于云的解决方案来定制解决方案，至少在最初阶段就有很大的意义。

云提供商正在通过新的解决方案来包装其基础设施，以利用物联网。例如，一家领先的大型提供商提供了一套可提供预测性维护的套件，可让您预测设备故障并系统地防止设备故障。它还提供IoT驱动的远程监控，其中涉及从资产收集数据，并使用该数据来触发自动警报和操作，如远程诊断，维护请求和其他操作流程。

这些服务的主要优点是手动，时间密集的程序现在可以动态，快速和自动化。几乎任何地方的资产都可以从远程监控，使用智能传感器和设备的实时数据。这反过来可以更好地了解操作状态，使您能够快速自动地响应当前的状况。

简而言之

虽然标准仍然难以捉摸，直到IT行业开始发展 - 通常当IT制造商决定采用标准来扩大市场和增加收入时，这不应妨碍您组装一个提供稳健投资回报率的协调一致的基础设施的能力到业务。集成商和云提供商已经在提供工作解决方案，为什么不使用它们？

当谈到物联网（IoT），许多开发者从微控制器、片上系统板、单板计算机、传感器和各种其他电子元件来思考。而设备无疑是物联网的基础，连接的解决方案的核心价值在于这些设备产生的数据。

设备层仅仅是底层数据平台的冰山一角，而底层数据平台则是水面下的重担。强大的物联网数据平台的关键支柱之一是Apache Kafka，它是一种开源软件，旨在处理大量的数据摄取。它充当数据中心中由Apache storm、Apache spark和Apache hadoop集群提供支持的数据处理管道的网关。

如果你是一个将物联网作为职业选择的开发者，那么现在是你开始投资Apache kafka的时候了。本文探讨了Apache kafka在部署可伸缩物联网解决方案中所扮演的角色。

Kafka：传感器数据的高性能摄取层

物联网设备包括能够生成多个数据点的各种传感器，这些数据点以高频率采集。一个简单的恒温器每分钟可以产生几字节的数据，而一辆连接的汽车或风力涡轮机在几秒钟内就可以产生千兆字节的数据。这些海量数据集被摄取到数据处理管道中，用于存储、转换、处理、查询和分析。

每个数据集由多个表示特定度量的数据点组成。例如，连接的暖风、通风和空调（HVAC）系统将报告环境温度、所需温度、湿度、空气质量、鼓风机转速、负荷和能耗指标。

在一个大型购物中心，这些数据点经常从数百个hvac收集。由于这些设备的功能可能不够强大，无法运行完整的TCP网络堆栈，因此它们使用诸如Z-Wave和ZigBee之类的协议将数据发送到能够聚合数据点并将其摄取到系统中的中央网关。

网关将数据集推送到Apache-Kafka集群，其中的数据采用多条路径。需要实时监控的数据点经过热路径。在我们的HVAC场景中，实时跟踪温度、湿度和空气质量等指标以采取纠正措施非常重要。这些数据点可以通过Apache storm和Apache spark集群进行近实时处理。

负载和功耗等指标在一段时间内收集后进行分析。通过批处理过程收集和分析的这些数据点通常采用数据处理管道的冷通道。MapReduce作业可以在Hadoop集群中运行，用于分析hvac的能效。

不管数据点采用什么路径，它们都需要被摄取到系统中。apachekafka充当处理大量数据集的高性能数据摄取层。负责热路径和冷路径分析的数据处理管道组件成为apachekafka的订户。

Kafka vs.MQTT

apachekafka不是MQTT的替代品，MQTT是一种通常用于机器到机器（M2M）通信的消息代理。卡夫卡的设计目标与MQTT有很大不同。

在物联网解决方案中，设备可分为传感器和执行器。传感器生成数据点，而执行器是可以通过命令控制的机械部件。例如，房间中的环境照明可用于调整LED灯泡的亮度。在这种情况下，光传感器需要与LED通信，这是M2M通信的一个例子。MQTT是为传感器网络和M2M优化的协议。

由于Kafka不使用HTTP进行接收，所以它提供了更好的性能和规模。

由于MQTT是为低功耗设备设计的，它无法处理海量数据集的摄取。另一方面，Apache kafka可以处理高速数据摄取，但不能处理M2M。

可扩展的物联网解决方案使用MQTT作为显式设备通信，同时依赖Apache Kafka来接收传感器数据。也可以将Kafka和MQTT桥接起来，以便摄取和M2M。但是建议将设备或网关配置为Kafka生产者，同时仍然参与由MQTT代理管理的M2M网络，从而使它们保持分离。

Kafka与HTTP/REST

apachekafka公开了一个基于二进制协议的TCP端口。推送数据的客户机启动套接字连接，然后写入一系列请求消息并读回相应的响应消息。此协议不需要为每个连接或断开连接进行握手。

由于Kafka不使用HTTP进行接收，所以它提供了更好的性能和规模。客户机可以连接到集群的一个实例来接收数据。这种体系结构与原始TCP套接字相结合提供了最大的可伸缩性和吞吐量。

虽然使用HTTP代理与Kafka集群通信可能很诱人，但建议解决方案使用本机客户机。由于Kafka是用Java编写的，所以本机Java客户机库提供了最好的性能。社区已经为Go、Python甚至甚至构建了优化的客户端库节点.js. Shopify还为Kafka开发了一个名为Sarama的开源Go库。Rackspace的Mailgun团队已经构建了Kafka Pixy，一个Kafka的开源HTTP代理。Python、C#、Ruby和其他语言有多个库。

大多数物联网网关功能强大，足以运行Java、Go或Python。为了获得最佳性能和吞吐量，建议使用本机为Kafka设计的客户端库。

Kafka入门

apache kafka是用Java开发的，它的部署由apache zookeeper管理。任何能够运行JVM的操作系统都可以用来部署Kafka集群。为了测试水，你可以在Docker运行卡夫卡。

如果您不想处理基础设施，可以从云中的托管Kafka服务开始。IBM Bluemix有一个基于Kafka的完全管理的基于云的消息服务MessageHub。Cloud Karafka是公共云中的另一个流式平台，专为Apache Kafka工作负载而设计。 Aiven.io提供hosted Kafka以及InfloxDB、Grafana和Elasticsearch。如果你是一个Salesforce.com网站或者Heroku开发者，你可以在Heroku上利用Kafka。

Apache卡夫卡是许多大数据部署的基础。在本系列的后续文章中，我将介绍Kafka的关键概念、体系结构和术语

原文：https://thenewstack.io/apache-kafka-cornerstone-iot-data-platform/

本文：http://jiagoushi.pro/node/1102

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

Apache Kafka是一个实时流平台，在大大小小的组织中得到了广泛的采用。Kafka的分布式微服务架构和发布/订阅协议使得它非常适合在企业系统和应用程序之间实时移动数据。据统计，超过三分之一的财富500强公司正在使用Kafka。在Github上，Kafka是最受欢迎的Apache项目之一，有超过11K之星和超过500名贡献者。毫无疑问，Kafka是一个开源项目，它改变了企业在云和数据中心内移动数据的方式。

Kafka的架构已经被优化为在系统和应用程序之间以可伸缩的方式尽可能快地流数据。Kafka客户端/生产者与Kafka集群紧密耦合，要求每个客户端知道Kafka集群的IP地址，并直接访问所有单独的节点。在可信网络内部，这允许对代理拓扑进行更改，这意味着可以通过直接使用来自Kafka客户端的多个节点来扩展主题和分区。在大多数情况下，Kafka主题空间也保持相当扁平，因为通常使用多个分区来扩展单个Kafka主题。在Kafka系统中拥有数百甚至数千个主题通常是不可取的，首选的方法是对大多数数据流使用很少的主题。Kafka非常适合在具有稳定IP地址和连接的相同可信网络内的系统之间进行通信。

对于设备连接到公共互联网上的数据中心或云的物联网用例，Kafka架构不适合开箱即用。如果您试图在Internet上使用Kafka从数千甚至数百万设备流数据，那么Apache Kafka架构是不合适的。有许多原因Kafka本身不是很适合物联网用例:

1. Kafka代理需要由客户端直接处理，这意味着每个客户端需要能够直接连接到Kafka代理。专业的IoT部署通常利用负载均衡器作为云中的第一道防线，因此设备只使用负载均衡器的IP地址连接到基础设施，负载均衡器有效地充当代理。如果您希望您的设备直接连接到Kafka，您的Kafka代理必须暴露给公共互联网。
2. Kafka不支持大量的主题。当通过公共Internet连接数以百万计的物联网设备时，通常使用单个和唯一的主题(通常在主题名称中包含一些唯一的物联网设备标识符)，因此可以根据单个客户机的权限限制读写操作。你不希望你的智能恒温器被黑客攻击，那些证书可能被用来窃听系统中的所有数据流。
3. 与物联网协议的客户端库相比，Kafka客户端是相当复杂和资源密集型的。大多数编程语言的Kafka api都非常直接和简单，但是在其内部存在很多复杂性。例如，客户端将使用并维护到Kafka代理的多个TCP连接。物联网的部署通常会限制设备的使用，这些设备需要最小的内存占用，并且在设备端不需要很高的吞吐量。默认情况下，Kafka客户端针对吞吐量进行了优化。
4. Kafka客户端需要一个稳定的TCP连接来获得最好的结果。许多物联网使用案例涉及不可靠的网络，例如联网的汽车或智能农业，因此典型的物联网设备需要不断地重新建立与Kafka的连接。
5. 将数万甚至数百万客户机连接到一个Kafka集群是不寻常的(通常甚至根本不可能)。在物联网使用案例中，通常有大量设备同时连接到后端，并不断产生数据。
6. Kafka缺少一些关键的物联网功能。Kafka协议缺少了诸如《活着》和《遗嘱》等功能。这些特性对于构建一个有弹性的物联网解决方案非常重要，该解决方案可以处理遇到意外连接丢失和网络不可靠的设备。

Kafka仍然为物联网用例带来了很多价值。物联网解决方案创建了大量的实时数据，很适合由Kafka处理。挑战在于:如何将物联网数据从设备连接到Kafka集群?

许多实现物联网用例的公司正在研究集成MQTT和Kafka来处理物联网数据的可能性。MQTT是另一个发布/订阅协议，它已经成为连接IoT设备数据的标准。MQTT标准设计用于通过不可靠的网络连接大量的物联网设备，解决了Kafka的许多限制。具体来说，MQTT是一种轻量级协议，需要在每个设备上占用较小的客户机空间。它可以在不可靠的网络上安全地支持数百万个连接，并在高延迟和低吞吐量环境下无缝工作。它包括物联网功能，如保持活力，最后的遗嘱和遗嘱功能，不同质量的服务水平的可靠消息，以及客户端负载平衡(共享订阅)在其他功能设计的公共互联网通信。主题是动态的，这意味着系统中可以存在任意数量的MQTT主题，在MQTT服务器集群中，每次部署通常多达数千万个主题。

尽管Kafka和MQTT有不同的设计目标，但两者在一起工作得非常好。问题不是Kafka vs MQTT，而是如何将这两个世界集成在一起，形成一个物联网端到端数据管道。为了将MQTT消息集成到Kafka集群中，需要某种类型的桥接器将MQTT消息转发到Kafka。

有四种不同的架构方法来实现这种类型的桥梁:

1. Kafka连接（Kafka Connect）MQTT

Kafka有一个扩展框架，叫做Kafka Connect，它允许Kafka从其他系统摄取数据。Kafka Connect for MQTT充当一个MQTT客户端，订阅来自MQTT代理的所有消息。

如果您没有对MQTT代理的控制权，那么Kafka Connect for MQTT是一个值得追求的方法。这种方法允许Kafka摄取MQTT消息流。

在MQTT中使用Kafka Connect存在性能和可伸缩性限制。如前所述，Kafka Connect for MQTT是一个MQTT客户机，它订阅通过代理传递的所有MQTT消息。MQTT客户机库并不打算处理大量的MQTT消息，因此使用这种方法的物联网系统将存在性能和可伸缩性问题。

这种方法集中了业务和消息转换逻辑，并创建了紧密耦合，这在分布式(微服务)体系结构中应该避免。业界领先的咨询公司Thoughtworks称这是一种反模式，甚至在他们之前的技术雷达出版物中将Kafka归入“持有”类别。

2. MQTT代理

另一种方法是使用代理应用程序，它接受来自物联网设备的MQTT消息，但不实现发布/订阅或任何MQTT会话特性，因此不是MQTT代理。物联网设备连接到MQTT代理，然后该代理将MQTT消息推送到Kafka代理。

MQTT代理方法允许在Kafka部署中完成MQTT消息处理，因此可以从单个控制台完成管理和操作。MQTT代理通常是无状态的，因此通过添加代理的多个实例，它(理论上)可以独立于Kafka集群进行伸缩。

MQTT代理的限制是它不是真正的MQTT实现。MQTT代理不是基于发布/订阅的。相反，它在设备和Kafka之间创建了一个紧密耦合的流。MQTT发布/订阅的好处是，它创建了一个松散耦合的端点系统(设备或后端应用程序)，可以在每个端点之间通信和移动数据。例如，MQTT允许两个设备之间的通信，例如两个连接的汽车可以彼此通信，但是MQTT代理应用程序只允许从一辆汽车到Kafka集群的数据传输，而不允许与另一辆汽车的数据传输。

一些Kafka MQTT代理应用程序支持QoS级别等特性。值得注意的是，只有在MQTT客户端重新连接到相同的MQTT代理实例时，才可能在连接丢失后恢复QoS消息流，而这是不可能的，前提是使用负载均衡器，该均衡器使用最少连接或循环策略来实现可伸缩性。因此，在MQTT中使用QoS级别的主要原因(即没有消息丢失)仅适用于稳定连接，这在大多数物联网场景中是一个不现实的假设。

使用这种方法的主要风险是代理不是功能完整的MQTT代理，因此它不是MQTT规范定义的MQTT实现，只是实现了一个很小的子集，因此它不是一个标准化的解决方案。为了在MQTT客户机中正确地使用MQTT，需要一个功能齐全的MQTT代理。

如果消息丢失不是一个重要因素，并且没有使用为可靠的物联网通信而设计的MQTT特性，如果您只想通过Internet单向地向Kafka发送数据，那么代理方法可能是一个轻量级的替代方法。

3.构建您自己的自定义桥接

一些公司建立了他们自己的MQTT到Kafka桥。典型的方法是使用开源MQTT客户端库和开源Kafka客户端库创建应用程序。自定义应用程序负责在MQTT代理和Kafka实例之间调换和路由数据。

这种方法的主要挑战是，自定义应用程序通常没有设计成容错和弹性。如果物联网解决方案要求和端到端保证至少一次或确切一次消息传递，这就变得很重要。例如，设置为服务质量级别1或2的MQTT消息发送到自定义应用程序将确认收到消息。但是，如果自定义应用程序在将消息转发给Kafka之前崩溃，则消息将丢失。类似地，如果Kafka集群不可用，自定义应用程序将需要缓冲MQTT消息。如果定制应用程序在Kafka集群恢复可用之前崩溃，所有缓冲的消息将丢失。要解决这些问题，定制应用程序将需要大量的开发工作，构建与Kafka和MQTT代理中已经发现的技术类似的功能。

4. MQTT代理扩展

最后一种方法是扩展MQTT代理，以创建包含本机Kafka协议的扩展。这允许MQTT代理充当一流的Kafka客户机，并将物联网设备数据流传递给多个Kafka集群。

要实现这种方法，您需要访问MQTT代理，代理需要能够安装扩展。

这种方法允许物联网解决方案使用本地MQTT实现和本地Kafka实现。物联网设备使用MQTT客户机将数据发送到功能齐全的MQTT代理。MQTT代理被扩展为包括一个本地Kafka客户机，并将MQTT消息置换到Kafka协议。这使得物联网数据可以同时路由到多个Kafka集群和非Kafka应用程序。使用MQTT代理还将提供对物联网设备所需的所有MQTT特性的访问，例如遗嘱和遗嘱。MQTT代理(如HiveMQ)是为高可用性、持久性、性能和弹性而设计的，因此消息可以在Kafka不可写时在代理上缓冲，因此重要消息不会从物联网设备中丢失。因此，这种方法提供了真正的端到端消息传递保证，即使是在不可靠的网络、公共Internet通信和不断变化的网络拓扑(在容器化部署中经常看到，例如Kubernetes)。

用于Kafka的HiveMQ企业扩展

在与HiveMQ客户的对话中，一些操作集群具有数百万台设备和非常高的消息吞吐量，我们看到需要为Kafka创建MQTT代理扩展。我们的客户希望从MQTT和Kafka协议的本地实现中受益，因为这两个协议都有所有的交付保证。因此，我们很高兴地宣布Kafka的HiveMQ企业扩展。

我们的客户看到了MQTT和Kafka联合解决方案的巨大价值。他们将Kafka视为在数据中心或云环境中处理和分发实时数据的优秀平台。他们希望使用MQTT和HiveMQ将数据从设备移动到不同的后端系统。后端系统包括Kafka和非Kafka系统。他们还知道，如果他们试图连接数以百万计的设备，比如连接的汽车，他们需要使用MQTT的本机和经过实战测试的实现，比如HiveMQ。

用于Kafka的HiveMQ企业扩展在HiveMQ代理中实现了本地Kafka协议。这允许MQTT消息与单个Kafka集群或多个Kafka集群同时无缝集成。它100%支持整个MQTT 3和MQTT 5规范。我们甚至可以将潜在的数百万个MQTT主题映射到数量有限的Kafka主题。最后，我们扩展了HiveMQ控制中心，使其能够监视写入Kafka的MQTT消息。

我们很高兴能将这个新产品带给我们的HiveMQ客户。这是在物联网用例中使用Apache Kafka的最佳方法。

 

参考：http://jiagoushi.pro/node/1099

讨论：请加入知识星球【首席架构师圈】或者小号【ca_cto】

物联网数据很复杂，需要多个用户访问，所以不要犯创建数据孤岛的错误。

几乎在每个行业，都有一个由物联网数据驱动的数字化转型正在进行中。重要的是要认识到物联网不是关于事物的;而是那些东西创造和收集的数据。组织依靠这些数据提供更好的用户体验，做出更明智的业务决策，并最终推动其增长。

然而，如果没有一个可靠的数据库来处理物联网设备产生的大量数据，这一切都是不可能的。关系数据库以灵活、易于使用和成熟而闻名。它们并不特别出名的是规模，这促使了NoSQL数据库的创建。你可能知道也可能不知道，有一些方法可以克服这个缺点。

另一件需要注意的事情是，物联网数据本质上是时间序列。通过使用像TimescaleDB这样的时间序列数据库，组织可以利用隐藏在机器生成数据中的洞察力来构建新特性、自动化流程和提高效率(稍后将对此进行更多介绍)。通常，工程团队最终会将数据存储在多个数据库中:元数据存储在关系数据库中，时间序列数据存储在NoSQL存储中。不要这样做。

下面，我们将概述您希望在NoSQL之上使用关系数据库的主要原因，并解释TimescaleDB + PostgreSQL可以为物联网提供的优势。

利用SQL及其生态系统

物联网数据需要多样化的、可定制的摄食管道，这需要一个具有广泛生态系统的数据库。要满足这些需求，开发人员只需查看SQL即可。

关系数据库和SQL密不可分，许多跨组织的人员(例如内部数据分析师、应用程序开发人员或希望实时访问数据的外部用户)通常已经了解SQL。例如，在制造业中，有些团队可能想要监视设备维护和预测故障，有些团队可能想要跟踪生产率和运输物流数据，等等。SQL使其变得容易。

此外，还有一些非常酷的功能，如:

• 连接:基于两个或多个表之间的相关列，将这些行组合在一起
• 聚合:将多个行的值分组在一起，形成一个汇总值(即最小、最大、AVG)
• 窗口函数:对一组行进行操作，并从底层查询中为每一行返回一个值(即PARTITION BY、ORDER BY)。
• 公共表表达式(CTEs):简化复杂的连接和子查询(即使用)
• ROLLUPS: GROUP BY子句的扩展，允许您使用单个查询生成多个分组集

此外，开发人员通常希望在现有的物联网基础设施上构建应用程序。SQL兼容许多管理工具，流管道(如Kafka或RabbitMQ)、消息传递协议(如MQTT)、可视化工具(如Seeq)、工业自动化平台(如Ignition)，以及用于处理地理空间和其他数据类型的扩展。

模式(大纲)是一件好事

对于关系数据库，您可以使用模式来帮助进行数据建模。虽然“无模式”数据库看起来似乎更容易入门，但它们最终会导致重大的技术债务。用户通常必须预先就如何存储他们的数据做出设计决策，而这些决策在未来很难更改。这意味着，如果新的查询模式需要不同的设置来提高性能，那么它们将得不到很好的支持。

另一方面，使用SQL预先构建模式实际上支持复杂的查询。用户还可以使用一组DDL(数据定义语言)命令来调整和更新模式。但是，正确地建模数据以提高性能是很重要的。为给定的工作负载创建适当的索引和表模式可以显著提高性能。相反，设计错误的模式会导致显著的性能下降。

本质上，你需要的是一种灵活的模式，特别是在存储半结构化数据时(例如，存储来自收集不同测量值的物联网传感器的读数)。您还需要一个能够灵活地管理和访问数据的数据库。特别是在物联网中，您收集数据的设备并不总是在线的，从而导致批量上传的数据次序混乱。您还可能需要更新不正确的传感器测量值。关系模型很好地支持所有这些函数。

消除数据孤岛

我们已经提到了这样一个事实，即组织中很多人都知道SQL，它允许多个用户访问数据。我们经常从客户那里听到，他们希望将时间序列数据库与完整的关系系统结合在一起，并且希望能够连接这些数据。

幸运的是，关系数据库支持连接并消除了在多个位置存储数据的需要。通过这样做，组织还可以节省操作多个系统的开销成本。此外，它们还可以避免与维护独立数据库相关的完整性问题，这就引出了我们的下一点。

依赖关系数据库获得可靠性

许多存储敏感数据的组织依靠关系数据库来保证信息的安全。毕竟，关系数据库早在70年代就出现了，并且在保证财富500强公司数据安全方面有着良好的记录。

物联网应用程序通常必须处理大量复杂的查询和事务。使用关系数据库，您可以确保这些事务将是进程的可靠性，这要归功于ACID(原子性、一致性、隔离性、持久性)。如果您不熟悉，那么可以告诉您，ACID是修改数据库时使用的一组属性。它们保证即使在遇到错误、断电、崩溃等情况下，事务也是有效的。

物联网选择PostgreSQL + TimescaleDB

如果您正在寻找用于物联网的关系数据库，我们建议您选择PostgreSQL。虽然我们似乎有些偏颇，但PostgreSQL的受欢迎程度依然坚定，并且连续第二次被db引擎评为年度最佳DBMS:

PostgreSQL首次发布于1989年，今年已经30岁了，它的人气达到了顶峰，没有任何老化的迹象，拥有一个非常活跃的社区。由于其稳定性和特性集，PostgreSQL已经成为众多开发人员首选的数据存储。”

虽然还有其他的关系数据库管理系统，但PostgreSQL和TimescaleDB为物联网开发人员提供了显著的优势。

总结:

原文：https://blog.timescale.com/blog/use-relational-database-instead-of-nosql-for-iot-application/

本文：http://jiagoushi.pro/node/1333

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

 

为物联网解决方案选择正确的数据库平台是一项艰巨的任务。首先，物联网解决方案可以跨地理区域分布。与集中式的基于云的解决方案相反，更多的解决方案正在采用边缘雾计算和云计算的组合。因此，您的数据库平台必须为您提供在边缘处理数据以及在边缘服务器和云之间进行同步的灵活性。

其次，根据您的物联网使用情况，您需要的数据库功能可能包括实时数据流、数据过滤和聚合、接近零延迟的读取操作、即时分析、高可用性、地理分布、模式灵活性等等。本文介绍了为物联网解决方案选择正确的数据库平台的四个步骤:

步骤1 确定解决方案的数据需求

物联网解决方案依赖于从联网设备中收集和处理数据，做出智能决策，如触发通知或动作，计算实时分析，从历史数据中收集模式，等等。

为了便于讨论，在通用的物联网解决方案中，可以在整个企业中安装传感器和执行器。成千上万的传感器和执行器与一台edge服务器相连。物联网解决方案不断从所有传感器收集数据，做出实时决策来控制传感器和执行器，向系统监视器发出异常活动警报，并为最终用户提供分析的历史视图。

在决定使用哪些服务和与之配套的数据库之前，有必要清楚地了解如何使用数据以及在何处使用数据。一些问题可以帮助理解和优先考虑你的数据需求:

• 哪些数据处理和决策被委托给边缘服务器?
• 云解决方案是部署在一个地区，还是分散在多个地区?
• 从设备到边缘服务器和从边缘服务器到中央服务器传输的数据量是多少?估计的峰值容量是多少?
• 物联网解决方案是否控制设备或致动器?如果是，它们需要实时响应吗?
• 从历史数据中获得的业务洞察力是什么?

步骤2 将解决方案分解为独立的软件服务

在此步骤中，您将设计执行独立的特定任务的软件服务或组件。

当将前面描述的样例物联网解决方案分解为独立的服务时，可以得到图2所示的设计。物联网解决方案本身是地理分布的，其中一些组件部署在边缘网络，其余组件在一个集中位置。

现在让我们将架构分解为服务，并分析它们的职责和数据需求:

数据摄取

目的:收集和存储设备日志和消息。

数据库需求:支持高速写操作，因为数据可能以突发的方式到达，确保数据在不寻常的情况下不会丢失。

边缘分析

用途:对输入数据执行数据转换、分类、聚合、过滤和功能。它负责在边缘进行实时决策。

数据库需求:支持高速读写与亚毫秒延迟;提供工具和命令来对数据执行复杂的分析计算。

设备管理器

用途:向设备传递信息。

数据库需求:以最小的延迟访问和向设备发送消息。

系统分析

目的:从边缘服务器收集数据，执行数据转换和分析操作。

数据库需求:提供对数据执行分析计算的命令，并根据分析引擎的需要长时间存储数据。

C&C (命令和控制)仪表板

目的:提供物联网生态系统当前状态的可视化表示。

数据库需求:保持数据的当前和准确，读取数据的延迟小于毫秒。

商业智能

用途:从历史数据运行报告、查询和推断。

数据库需求:长时间存储数据，节约成本;提供查询和分析数据的工具。

物联网数据流出口

用途:将数据规范化为一种通用格式，并将其推送给订阅服务器。

数据库需求:高效执行数据转换操作的能力;支持发布和订阅功能。

 

步骤3:根据数据需求对服务进行分组，并选择正确的数据库

下一步是根据每个服务的数据选择正确的数据库。图3将我们的物联网示例中的服务连接到图中，根据数据在数据库中停留的时间和服务所需的数据读/写速度对它们进行分类。

您将看到数据不断进出数据摄取服务器，在数据库中停留的时间非常短。同时，数据的到达量大，速度快。因此，我们需要一个具有低延迟的高速数据库来保存用于摄入服务的数据。另一方面，商业智能服务依赖于历史数据。

下一步是对具有类似数据访问特征的服务进行分组，目标是限制数据库的数量(多余的数据库和不符合您需求的数据库)，从而减少操作开销。

在图4中，我们将示例服务分组到两个主数据库中—一个热数据库和一个冷数据库。保存热数据的数据库部署在靠近物联网设备的位置，以最小化网络延迟。热数据和冷数据的数据库选择是:

热数据库:由于RAM的成本越来越便宜，内存中的数据库通常是一个不错的选择。内存中的数据库以最小的延迟交付数据读写能力。当选择一个热数据库时，这些额外的功能和能力将帮助您缩小选择范围:

• 数据格式的灵活性——帮助您支持广泛的设备和通信格式
• 查询功能——使您能够实时运行高效的查询
• 消息传递和排队——驱动通信和数据交换
• 分层内存模型-提供一个经济有效的内存模型，但高性能
• 高可用性和灾难恢复-帮助您保持业务的所有时间
• 地理分布-服务地理分布的物联网部署
• 二进制安全-帮助您保存二进制数据

冷数据库:物联网解决方案的历史数据可能增长到多个tb，在某些情况下可能超过一个pb。存储历史数据的流行选择包括在普通硬件上存储解决方案。查询通常遵循map-reduce模式。通常，历史数据也会在搜索引擎中建立索引，用于模式匹配和数据聚合。如果您要将数据存储在云中，请与您的云服务提供商联系，在您所在的地区，哪种数据存储方案最划算。

第四步:评估成本、资源效率

将数据库分为热数据库和冷数据库有助于缩小数据库选择范围。对于大多数物联网用例，一个高速数据库可以满足热数据库的所有需求。对于冷数据库，选项可能从关系数据库到数据湖。设计人员经常犯的一个错误是为每个服务创建具有专门数据库的多语言体系结构。这增加了应用程序堆栈的复杂性以及操作开销和成本。

拥有一个数据库的总成本是许多参数的函数。数据库本身的成本只是成本的一小部分。以下是一些费用:

• 数据库许可证成本:该成本可能与cpu数量、集群中的碎片数量、数据库大小、吞吐量(每秒最大操作数量)、时间(年、月、小时等)、高可用性和恢复特性、云的多个区域的可用性等有关。如果您使用的数据库可以作为开放源码软件使用，根据许可证的类型，数据库成本甚至可能为零。
• 基础设施成本:基础设施成本取决于数据库的资源效率。例如，一个轻量级、线程安全的数据库可能只使用两个商用服务器每秒执行100万次读/写操作，而传统数据库可能需要更多的服务器才能得到相同的结果。除了数据库效率，硬件成本还取决于吞吐量、cpu数量、RAM、数据大小、闪存、网卡等。用于高可用性的数据库体系结构也发挥了作用。例如，基于仲裁的故障转移架构将只需要一个备用服务器副本，但非基于仲裁的架构将需要两个数据副本，以避免分裂大脑。
• 数据丢失成本:为数据丢失提供适当的保险是极其重要的，特别是对于商用物联网解决方案。您丢失数据的总成本为:
  • 亏损的业务
  • 数据丢失的概率*恢复数据的成本

您可以使用数据库供应商提供的适当SLA来抵消部分成本。

• 操作开销:自动化是成功的咒语。如果数据库提供控制来自动化部署、配置、故障转移、扩展、数据分区、备份和恢复、监视和警报等操作，那么将有助于高效地操作。

结论

当为下一代物联网解决方案选择正确的数据库时，很容易迷失在现有的大量数据库中。但是，如果将解决方案分解为组件服务并理解它们的数据库需求，就可以有效地缩小数据库选择范围。大多数物联网解决方案都依赖于热数据库进行实时数据收集、处理、消息传递、分析，而冷数据库用于存储历史数据和收集商业智能。这将使架构简单、精简和健壮。

最后需要说明的是，Redis实验室赞助的开源内存数据库Redis是物联网解决方案的热门数据库。它被物联网解决方案广泛用于数据摄取、实时分析、消息传递、缓存和许多其他用例。

 

原文：https://thenewstack.io/4-steps-to-select-the-right-database-for-your-internet-of-things-system/

本文：http://jiagoushi.pro/node/1332

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

面对现实吧。建立物联网产品路线图难度要比为“正常”技术产品制定路线图要困难得多。

这是因为IoT产品是复杂的系统。为了创建一个工作的解决方案，物联网技术栈的所有层 - 设备硬件，设备软件，通信，云平台和云应用都需要一起工作。就像在一个管理五个产品一样，你的路线图需要成为让所有利益相关者符合你的愿景的胶合剂。

物联网路线图 - 您的利益相关方和团队对齐的关键

物联网路线图需要以所有利益相关者有意义的方式展示产品方向以及新功能的影响。您的利益相关者可能来自销售，营销，执行团队，工程等。他们都有不同的需求和不同层次的了解产品如何组合在一起。

事实上，IoT引入了额外的复杂性，因为即使技术实现可能分为多个组。根据您公司的结构，您可能会有专门的硬件与软件团队，嵌入式和云开发等。没有任何一个团队将有一个整体的理解，这使您更加重要（和您的路线图）沟通完整的图片。

由于这种复杂性，管理物联网产品类似于管理产品组合，区别在于您的投资组合中的所有产品需要一起工作以形成一个凝聚力的解决方案。不是一件容易的事情

构建物联网产品路线图的关键是平衡端到端产品的高级视图，并在物联网技术栈的每一层进行更详细的视图。这样，您就可以为不同的利益相关者提供适当的信息，确保没有人看到大局。

建议阅读：物联网：产品经理入门

建立高层次的物联网产品路线图

我们用一个例子来说明物联网产品路线图的所有运动部分。假装你的公司建造工业水泵。

在与很多客户和销售人员交谈之后，您发现客户的一个主要关注点是始终保持业务运行。他们想知道泵是否即将失效，以便他们可以主动地订购部件并安排服务。这将减少停机时间并节省很多钱。这种“预测维护”对您的客户非常有价值，他们愿意付出很多代价。

研究解决方案与工程，你会知道，随着泵的老化，它开始振动。振动越多，失败越紧。因此，如果您能够监测泵振动并对该数据执行分析，则可以预测故障。通过这些信息和一些业务尽职调查，您确定这是一个很好的解决方案，您可以将其放在内部买入的路线图中。

您的高级路线图可能看起来像这样。

如您所见，这与非IoT产品的路线图没有什么不同。这里面临的挑战是，您的利益相关者（高管，销售，营销和工程部门）很难理解构建此功能以及最终产品的功能。也很难理解为什么第一版将需要6个月，而版本＃2和＃3将会更短。

使用故事映射来增强您的物联网路线图

对于您的IoT路线图传达完整的故事，您需要提供另一个级别的详细信息，描述物联网技术栈中高层路线图的功能。

我发现故事映射是深入下一个细节层级的好方法。我喜欢将故事映射与IoT技术栈结合在一起，以显示功能如何与端对端IoT产品的各个层对齐。

结果是一个比“产品积压”更高的可视化，但为所有团队提供足够的信息来了解大局。这一观点还使团队能够了解计划功能如何与他们需要做的日常工作相关。

以下是这种方法将如何寻找我们的“智能泵”的例子。从这个观点来看，更容易解释需要完成的工作来支持预测性维护功能。请注意，上一个路线图中高级功能的名称如何成为每个版本的主题。这有助于您的团队关注大局，同时关注较小的细节。

请注意，并非所有图层都必须受到每个版本的影响。在这个例子中，发布＃1后的“通信”层没有任何功能。此示例假定“通信”层中的版本＃1功能将能够支持版本＃2和＃3的功能。

从这个可视化的角度来看，很容易看到第1版是影响设备硬件的唯一版本。因此，很容易解释为什么第1版将比其他版本更长。

您还可以看到在版本＃2和＃3中影响较少的图层。初始版本将是最长的，因为您需要构建大量的基础设施。一旦建立了初始的“管道”，那么您可以以更快的速度添加其上的功能。您可以使用此工具来解释演变。

建议阅读：物联网的产品管理框架

使用路线图协调工程

您还可以使用故事映射路线图来协调跨越物联网技术栈的各个层次的多个工程团队。每个团队都需要分享产品所在的统一愿景。但与此同时，他们需要了解他们特定团队的未来工作。该路线图可以帮助您实现两个目标。

如下图所示，您可以使用“垂直切片”为多个版本的每个工程团队创建特定的路线图。只要数据格式和层之间的接口被明确定义，这种方法将使每个团队能够独立工作，并使进度更快。

底线

作为产品经理，在整个公司沟通产品愿景时，您将永远面临挑战。 这是一项艰巨的任务，但这可能是我们角色中最重要的功能。 这篇文章中概述的方法为您提供了一个非常强大的沟通工具，您可以使用它来清楚地表达您的产品想法并使每个人都对齐。 结果：提高透明度，从而实现更好的沟通，快乐的团队和愉快的客户。

物联网产生大量的数据，包括流数据、时间序列数据、RFID数据、传感数据等。要有效地管理这些数据，就需要使用数据库。物联网数据的本质需要一种不同类型的数据库。以下是一些数据库，当与物联网一起使用时，会给出非常好的结果。

物联网可以看作是一个网络，在这个网络中，各种事物通过一个共同的平台相互连接。只是想象一个场景,在该场景中,每一个设备在家里和工作场所的连接,和一个世界,空调在房间外面的温度上升时自动降低其温度,当在任何公共集会的人数很容易知道,当一个人的健康可以每天监控参数。这就是物联网可能带来的影响。

物联网目前的状态是非常零散的。有不同的公司和组织正在为他们的客户或他们的个人需求建立自己的平台。但是，目前还没有一种通用的平台，可以让所有设备(无论它们是哪家公司的)通过用户友好的界面相互连接。

据估计，未来5年，物联网设备的数量将达数万亿。

物联网需要数据库吗?

物联网带来了许多繁琐的挑战，尤其是在数据库管理系统领域，比如实时整合海量数据、处理流中的事件以及处理数据的安全性。例如，应用于智能城市的基于物联网的交通传感器可以实时生成大量的交通数据。

数据库在充分处理物联网数据方面扮演着非常重要的角色。因此，适当的数据库与适当的平台同等重要。由于物联网在世界上不同的环境中运行，选择合适的数据库变得非常具有挑战性。

在为物联网应用选择数据库之前应该考虑的因素是:

1. 大小、规模和索引
2. 处理海量数据的有效性
3. 用户友好的模式
4. 可移植性
5. 查询语言
6. 流程建模和事务
7. 异构性和集成
8. 时间序列聚合
9. 归档
10. 安全和成本

物联网中的数据类型有:

1. RFID:射频识别
2. 地址/惟一标识符
3. 过程、系统和对象的描述性数据
4. 普适环境数据和位置数据
5. 传感器数据:多维时间序列数据
6. 历史数据
7. 物理模型:作为现实模板的模型
8. 执行器状态及控制命令数据

适合物联网的数据库

InfluxDB

InfluxDB:流感数据库首次发布于2013年，是最近的数据库之一。该数据库完全基于键值数据库LevelDB，采用Go编程语言进行开发。InfluxDB是一个时间序列数据库，用于优化和处理时间序列数据。时间序列数据最早由Kdb在2000年发布，但随着物联网的兴起，随着NoSQL、NewSQL和大量增长的数据的出现，InfluxDB变得流行起来。

对物联网数据使用InfluxDB的优点包括:

• 允许对序列进行索引
• 它有一个类似sql的查询语言
• 对缺失数据提供内置的线性插值
• 支持数据自动降采样
• 支持连续查询计算聚合

CrateDB

CrateDB: CrateDB是一个分布式SQL数据库管理系统。它是开源的，用Java编写的，包含了来自Facebook Presto、Apache Lucene、Elasticsearch和Netty的组件——因此它是为高可伸缩性而设计的。CrateDB是为使物联网数据工作而设计的。从工业互联网、联网汽车到可穿戴设备，CrateDB是新型物联网解决方案创新者的首选数据库。

将CrateDB用于物联网数据的优点包括:

• 每秒百万个数据点:快速、线性可扩展的数据摄取
• 实时查询:柱状索引和字段缓存提供内存中的SQL性能
• 动态模式:动态添加和查询新的传感器数据结构
• 物联网分析:快速、健壮的时间序列、人工智能、地理空间、文本搜索、连接、聚合
• Always on:内置的数据复制和集群再平衡确保不间断的性能
• ANSI SQL:无锁定，易于任何开发人员使用和集成
• 内置的MQTT代理:直接将设备与数据库集成
• 物联网生态系统:使用Kafka、Grafana、NodeRED等流行的物联网栈软件
• 可以在任何地方运行，以便在边缘或云中进行高效处理

MongoDB

MongoDB: MongoDB是一个免费的、开源的、跨平台的、面向文档的数据库程序。它被归类为一个NoSQL数据库程序。MongoDB使用具有模式的类似json的文档。它是物联网组织的首选，因为它可以让他们存储来自任何上下文的数据，可以实时分析，也可以在他们进行时改变模式。

MongoDB用于物联网数据的优点包括:

• 强大的数据库
• 面向文档的
• 具有一般用途
• 作为一个NoSQL数据库，它使用类似JSON的带有模式的文档

RethinkDB

RethinkDB:在开放源码数据库列表中，RethinkDB位于顶部。它是一个可伸缩的实时Web JSON数据库，是从头开始构建的。RethinkDB通过改变传统数据库架构引入了一种令人兴奋的新访问模型。当开发人员向它发出命令时，它可以不断地将更新后的查询结果实时推送到应用程序。这是一个被开发人员称为change feed的特性。RethinkDB充当数据库、实时存储库和系统状态的消息代理，这是change feed允许的。它的实时推送架构大大减少了构建可伸缩实时应用程序所需的时间和精力。

对物联网传感器数据使用RethinkDB的优点包括:

• RethinkDB有一个可适应的查询语言来检查API，非常容易设置和学习。
• 如果主服务器出现故障，命令会自动转移到新服务器上。
• 节点实时即插即用功能，无需停机一秒，方便添加节点。
• 在Ruby和Tornado中通过Eventmachine提供异步查询，提供异步应用程序编程接口。
• 它提供SSL访问，只是为了通过公共互联网安全访问RethinkDB。
• Floor, ceil和round是RethinkDB提供的各种数学运算符。

SQLite

SQLite数据库引擎是一个进程库，它提供了一个无服务器的(自包含的)事务性SQL数据库引擎。由于其可移植性和较小的内存占用，它对游戏和移动应用程序开发产生了重大影响。

SQLite适用于不需要任何人工支持的设备，因为数据库不需要管理权限。它非常适合用于手机、机顶盒、电视、游戏机、相机、手表、厨房电器、恒温器、汽车、机床、飞机、远程传感器、无人机、医疗设备和机器人，以及物联网。

客户端/服务器数据库引擎被设计为驻留在网络核心的数据中心内。SQLite也在那里工作，但SQLite也在网络的边缘蓬勃发展，在为自己提供快速可靠的数据服务的同时，为那些连接不可靠的应用程序提供服务。

对物联网数据使用SQLite的优点包括:

• 内存占用小
• 它是真实的
• 使用前无需设置
• 没有依赖性

Cassandra

Apache Cassandra: Apache Cassandra是一个免费的开源分布式NoSQL数据库管理系统，最初发布于2008年。它旨在通过许多商用服务器处理大量数据，提供没有单点故障的高可用性。

在物联网中，由于连接的设备数量巨大，通过各种网络产生、跟踪和共享数据的规模非常大。Cassandra非常擅长利用大量的时间序列数据，这些数据直接来自于设备、用户、传感器以及存在于不同地理位置的类似机制。

在物联网中使用Apache Cassandra的优点

数据包括:

• 容错
• 展示了高性能
• 去中心化:集群中的每个节点都是相同的
• 可伸缩
• 持久性
• 确保可控:每次更新都可以选择同步复制和异步复制
• 弹性:读写都是实时执行的，任何应用都不存在停机
• 专业支持:加强第三方提供的合同和服务。

 

原文：https://www.opensourceforu.com/2018/05/open-source-databases-that-work-best-for-iot/

本文：http://jiagoushi.pro/node/1331

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

整体架构

IoT设备组件

硬件抽象层

为了确保便携性，IoT设备需要包括一个软件层，可以访问MCU的硬件功能，如闪存，GPIO，串行接口等。

提供高级API用于访问由微控制器（如GPIO，ADC，MEMS等）提供的硬件功能。它可以直接连接到由硅供应商提供的本地库，驱动程序和板支持包。

通讯

IoT设备需要允许将其连接到有线或无线协议的驱动程序和协议，从而实现通信。

提供MQTT协议的实现。

远程管理

IoT设备需要远程控制的情况很多，例如升级固件或监控其电池电量。

• Provides an implementation of the OMA LWM2M standard.

• 提供OMA LWM2M标准的实现。

IoT网关组件

操作系统

Linux (Ubuntu/Ubuntu Core, Yocto-based linux distribution), Windows.

应用容器或者应用运行时

OSGi Runtime

通讯和连接

与网关I / O（例如串行，RS-485，BLE，GPIO等）接口，并支持可用于连接设备（例如MODBUS，CAN总线等）的许多现场协议。

网络管理

通过广泛的接口（蜂窝，Wi-Fi，以太网等）提供先进的网络和路由功能。

数据管理和消息

实现基于本地MQTT的消息传递解决方案，允许在网关上运行的应用程序透明地与云平台通信，而无需处理网络接口的可用性，或如何表示IoT数据。 通过内置的Apache Camel消息路由引擎可以获得对附加消息协议的支持。

I

远程管理和消息

提供基于MQTT协议的远程管理解决方案，除了控制（安装，更新，修改设置）其运行的软件之外，还可以监视IoT网关的总体运行状况。

云平台组件

连接性和消息路由

IoT平台需要能够与使用不同协议和数据格式的大量设备和网关进行交互，然后将其规范化，以便轻松集成到企业的其余部分

提供用于与使用任意协议的设备交互的统一API，以及可扩展的框架来添加其他协议。

提供MQTT代理的实现。

设备管理

IoT平台应该能够配置新的软件更新和管理设备。

提供OMA LWM2M设备管理协议的实现

设备注册

中心注册表有助于识别和验证在IoT解决方案中运行的设备/网关

提供管理工具，向设备和网关推出软件更新

事件管理

•  

分析

• 包括Apache Hadoop，Apache Spark和Apache Storm。

• 提供对仪表板和存储在各种数据存储库中的数据报告的支持。

应用服务接口

通过公开应用程序编程接口（API），能够整合和分析数据，并创建报告，图表和仪表板。

• 有助于公开一致的API，用于消费遥测数据或向设备发送命令，以便使IoT应用程序开发合理化。

开放标准

CoAP

CoAP（约束应用协议）是专门用于受限节点和网络的协议。

它实现了REST架构风格，可以透明地映射到HTTP。 然而，CoAP还提供超出HTTP的功能，如本地推送通知和群组通信。

DTLS

数据报传输层安全（DTLS）协议为诸如数据报协议提供了通信安全性。 DTLS允许基于数据报的应用程序以旨在防止窃听，篡改或消息伪造的方式进行通信。 对于IoT应用，DTLS可用于保护基于CoAP的通信。

ISO/IEC 15118

题为“道路车辆 - 车辆到电网通信接口”的国际标准ISO / IEC 15118定义了电动汽车（EV）和充电站（称为电动车辆供应设备 - EVSE）之间的数字IP通信接口。

它允许基于在EV和EVSE之间交换的广泛信息的用户友好的“插入和充电”机制进行认证，授权，计费和灵活的负载控制。

IEC 61499

国际标准IEC 61499，涉及工业过程测量和控制系统功能块的主题。 IEC 61499的规范定义了分布式控制系统的通用模型，并基于IEC 61131标准。

OMA LightweightM2M (LWM2M)

OMA轻量级M2M（LWM2M）是M2M / IoT设备设备管理的行业标准。 它依赖于CoAP，因此针对传感器或蜂窝网络的通信进行了优化。

OMA LWM2M提供了一种可扩展的对象模型，允许除了核心设备管理功能（固件升级，连接监控，...）之外，还可以实现应用程序数据交换

MQTT

MQTT是一种用于连接物理世界设备和网络以及IT和Web开发中使用的应用程序和中间件的协议，使其成为IoT和M2M的理想连接协议。

它是一种轻量级的发布订阅协议，可在嵌入式设备和移动平台上运行，同时通过有线和无线网络连接到高度可扩展的企业和Web服务器。对于需要较小代码占用和/或网络带宽或连接不可预测的远程嵌入式系统以及需要较小尺寸，低功耗，最小化数据包和高效分配的移动应用程序，该连接非常有用的信息到一个或多个接收器。

通过松散耦合和服务质量，MQTT针对动态系统环境进行了优化，其中需要向Web和企业服务器以及其他消费者提供大量物理世界消息和事件。 MQTT已经很好地满足了M2M和IoT应用的意想不到的需求。

SensorThings API

SensorThings API是一个开放的地理空间联盟（OGC）标准，为通过网络互连IoT传感设备，数据和应用提供了一个开放和统一的框架。 这是一个开放的标准，涉及物联网的语法互操作性和语义互操作性。

oneM2M

oneM2M规格提供横向框架，以支持智能城市，智能电网，连接车，家庭自动化，公共安全和健康等广泛的应用和服务。

OPC Unified Architecture (UA)

OPC统一架构（UA）是一种互操作性标准，可实现安全可靠的工业自动化数据交换，同时保持跨平台和供应商的中立。 该规范由OPC基金会在个别软件开发商，行业供应商和最终用户的指导下开发和维护。 它定义了客户端和服务器之间的接口，包括访问实时数据，监控报警和事件，历史数据访问和数据建模

PPMP

PPMP（生产绩效管理协议）指定了一种允许捕获生产设备性能分析所需的数据的格式。 它允许监视后端在生产过程的上下文中收集和评估机器的关键指标。 它正在通过允许将机器状态与当前生产的部件相关联来实现。

用于传感器分析的KSQL UDF。利用KSQL的新的API特性，用Java轻松地构建UDF / UDAF函数，从而使用Apache Kafka进行连续流处理。用例:联网汽车——使用深度学习的实时流媒体分析。

我为混合机器学习基础设施构建了一个场景，利用Apache Kafka作为可伸缩的中枢神经系统。使用公共云在极端尺度下训练分析模型(如通过谷歌ML引擎在谷歌云平台(GCP)上使用TensorFlow和TPUs。预测(即模型推断)是在本地Kafka基础设施的边缘前提下执行的(例如利用Kafka流或KSQL进行流分析)。

这篇文章的重点是在前提部署。我用KSQL UDF创建了一个用于传感器分析的Github项目。它利用KSQL的新API特性轻松地使用Java构建UDF / UDAF函数，对传入事件进行连续流处理。

用例:联网汽车——使用深度学习的实时流媒体分析

连续处理来自连接设备(本例中的汽车传感器)的数百万个事件:

我建立了不同的分析模型。他们在公共云上接受训练，利用TensorFlow、H2O和谷歌ML引擎。模型创建不是这个示例的重点。最终的模型已经准备好投入生产，并可以部署进行实时预测。

模型服务可以通过模型服务器或原生嵌入到流处理应用程序中来完成。查看模型部署中RPC与流处理的权衡和“TensorFlow + gRPC + Kafka流”示例。

演示:使用MQTT、Kafka和KSQL在边缘进行模型推断

Github项目生成汽车传感器数据，通过Confluent MQTT代理将其转发到Kafka集群进行KSQL处理和实时分析。

这个项目主要是通过MQTT将数据输入Kafka，通过KSQL对数据进行处理:

Confluent MQTT代理的一大优点是可以简单地实现物联网场景，而不需要MQTT代理。您可以通过MQTT代理直接将消息从MQTT设备转发到Kafka。这大大减少了工作和成本。如果您“只是”希望在Kafka和MQTT设备之间进行通信，那么这是一个完美的解决方案。

如果你想看这个故事的其他部分(与像Elasticsearch / Grafana这样的sink应用的集成)，请看看Github项目“KSQL流物联网数据”。通过Kafka Connect和Elastic connector实现了与ElasticSearch和Grafana的集成。

 KSQL UDF 源代码

开发udf非常容易。只需在一个UDF类中实现一个Java方法:

 

@Udf(description = "apply analytic model to sensor input")
public String anomaly(String sensorinput){ "YOUR LOGIC" }

 

下面是KSQL UDF异常检测的完整源代码。（Anomaly Detection KSQL UDF.）

如何运行与Apache Kafka和MQTT代理演示?

在Github项目中描述了执行演示的所有步骤。

您只需要安装Confluent Platform，然后按照以下步骤部署UDF、创建MQTT事件并通过利用分析模型的KSQL处理它们。

我使用mosquito to生成MQTT消息。当然，您也可以使用任何其他MQTT客户机。这就是开放和标准化协议的最大好处。

Apache Kafka和机器学习的混合云架构

如果你想了解一个可扩展的、不确定供应商的机器学习基础设施背后的更多概念，请看看我在Slideshare上的演示，或者观看相应的Confluent网络研讨会“释放Apache Kafka和TensorFlow在云端”的记录。

 

原文：https://www.kai-waehner.de/blog/2018/08/02/deep-learning-kafka-ksql-udf-anomaly-detection-mqtt-iot-sensor/

本文：http://jiagoushi.pro/node/1100

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

随着有价值的用例的出现，物联网(IoT)正得到越来越多的关注。然而，一个关键的挑战是整合设备和机器来实时和大规模地处理数据。Apache Kafka®及其周边的生态系统，包括Kafka Connect、Kafka Streams和ksqlDB，已经成为集成和处理这类数据集的首选技术。

在Kafka客户端api(如Java、Python、.NET和C/ c++)之外，需要注意的是:

• Kafka连接源和接收连接器，它们在两个方向上与MQTT代理集成
• 汇合式MQTT代理，它从物联网设备中摄取数据，而不需要MQTT代理
• Confluent REST代理用于简单但功能强大的基于http的集成

在我更详细地讨论这些问题之前，让我们先看一看目前在物联网项目中使用Confluent Platform和Confluent Cloud的一些常见用例。

物联网技术和事件流平台的用例

Confluent Platform和Confluent Cloud已经被用于许多物联网部署，包括消费者物联网和工业物联网(IIoT)。大多数场景都需要可靠、可伸缩和安全的端到端集成，从而支持实时的双向通信和数据处理。一些具体的用例是:

联网的汽车基础设施:

汽车彼此和远程数据中心或云进行通信，以执行实时交通建议、预测维护或个性化服务。

例如:Audi

智能城市和智能家居:

建筑、交通灯、停车场等很多东西都相互连接，以实现更高的效率，提供更舒适的生活方式。能源供应商将房屋连接起来，买卖自己的太阳能，并提供额外的数字服务。

例如:E.ON

智能零售和客户360:

客户的移动应用程序与CRMs、忠诚度系统、地理位置和天气信息等后端服务之间的实时集成，创建了特定上下文的客户视图，并允许更好的交叉销售、促销和其他面向客户的服务。

例如: Target

智能制造:

工业企业将机器和机器人集成在一起，优化业务流程，降低成本，比如提前报废零部件，或者提前进行预防性维护，在机器部件损坏之前更换它们。数字服务和订阅服务提供给客户，而不仅仅是向他们销售产品。

例如:Severstal

在这些用例中，机器学习发挥了巨大的作用，无论行业是什么，您可以使用Apache Kafka阅读来推动尖端的机器学习，以获得更多的见解。

现在让我们来看看一个健壮的物联网集成架构。

端到端企业集成架构

物联网集成架构需要将edge(设备、机器、汽车等)与数据中心(on-premises、cloud和hybrid上)集成，以便能够处理物联网数据。

物联网集成架构的要求和挑战

为了灵活和面向未来，物联网集成架构应该具备以下要求:

• 可伸缩的数据移动和处理:处理反向压力，可以处理不断增加的吞吐量
• 敏捷开发和松耦合:不同的源和汇应该是各自的解耦域。不同的团队可以开发、维护和更改对设备和机器的集成，而不依赖于处理和分析数据的其他源或sink系统。微服务、Apache Kafka和域驱动设计(DDD)更详细地介绍了这一点。
• 创新开发:根据特定用例的灵活性和需求，可以使用新的和不同的技术和概念。例如，一个应用程序可能已经将数据发送到MQTT代理，以便您可以从那里消费，而另一个项目根本不使用MQTT代理，您只是想直接将数据推入事件流平台以进行进一步处理。

但是几个挑战增加了物联网集成架构的复杂性:

• 复杂的基础设施和操作通常无法更改——尽管需要与现有的机器集成，但您无法轻松地向机器本身添加代码
• 与许多不同的技术集成，比如MQTT或OPC统一架构(OPC Unified Architecture, OPC UA)，同时也遵守遗留的和专有的标准
• 由于不良的物联网网络导致通信不稳定，导致成本和投资在边缘

考虑到这些需求和挑战，现在让我们看看MQTT和其他IoT标准如何帮助集成数据中心和edge。

物联网标准和技术:MQTT, OPC UA，西门子S7, PROFINET

市场上有许多物联网标准和技术。如果必须选择，以下是实现物联网集成的最常见选项:

• 专有接口:特别是在工业物联网(IIoT)中，这是最常见的场景。计算机以专有格式提供大量通常是封闭的和不兼容的协议。例如S7、PROFINET、Modbus或自动分派系统(ADS)。监控控制和数据采集(SCADA)通常用于控制和监控这些系统。
• OPC UA:这是一个开放的、跨平台的、用于工业自动化的机器对机器通信协议。每个设备都必须进行改造，使其能够使用新的协议，并使用一个公共客户机与这些设备进行通信。要启用OPC UA，许可证成本和现有硬件的修改是必需的。
• PLC4X:作为一个Apache框架，它通过实现驱动程序(类似于用于关系数据库的JDBC)来提供一个统一的API，这些驱动程序用于与大多数工业控制器以其本身理解的协议进行通信。不需要许可证成本或硬件修改。
• MQTT:它构建在TCP/IP之上，用于受限制的设备和不可靠的网络，应用于许多(开放源码)代理实现和许多客户机库。它包含用于不良网络/连接的IoT特定特性，并被广泛使用(主要用于物联网，但也通过MQTT通过WebSockets用于web和移动应用程序)。

难怪这两个领域的技术诀窍分布不均。例如，在物联网环境中，近年来发展了大量的数据交换协议。只有MQTT对自动化技术员工来说是熟悉的。

用同样的方法，工业协议对软件工程师来说是一本有七个封条的书。可能有些工业协议非常适合特定的物联网解决方案，就像现代物联网协议的某些安全特性适合工业一样。但这并不能改变什么。

MQTT已经成为当今大多数物联网场景的标准解决方案，特别是在IIoT之外。尽管MQTT是这篇博客文章的重点，但在以后的文章中，我将通过利用PLC4X及其Kafka集成，讨论MQTT与IIoT及其专有协议(如西门子S7、Modbus和ADS)的集成。有关在IIoT集成场景中使用Kafka Connect和PLC4X的更多细节，您可以查看这些关于自动化行业中灵活和可伸缩集成的幻灯片(flexible and scalable integration in the automation industry)，以及解释IIoT、Apache Kafka和PLC4X之间关系的视频(video explaining the relation between IIoT, Apache Kafka, and PLC4X)。

根据我与工业客户(他们对封闭的、不灵活的接口的挑战感到痛苦)的交谈，我注意到越来越多的IIoT设备和机器也提供了可以集成到现代系统中的MQTT接口。

关于MQTT的权衡，考虑利弊:

优点

• 广泛采用
• 轻量级
• 有一个简单的API
• 为连接差和延迟高的场景而构建
• 支持许多客户机连接(每个MQTT服务器数万个)

缺点

• 只是排队，而不是流处理
• 无法处理使用量激增(没有缓冲)
• 大多数MQTT代理不支持高可伸缩性
• 异步处理(通常脱机很长时间)
• 缺乏与企业其他部分的良好集成
• 单一基础设施(通常位于边缘)
• 不能对事件进行再处理

这些权衡表明MQTT是为物联网场景构建的，但是在集成到公司的企业架构时需要帮助。这就是事件流媒体平台Apache Kafka及其生态系统发挥作用的地方。

Apache Kafka作为一个事件流平台

Apache Kafka是一个事件流平台，它结合消息传递、存储和数据处理来构建高度可伸缩、可靠、安全和实时的基础设施。那些使用Kafka的人经常使用Kafka连接以及使集成与任何源或接收器。Kafka流也很有用，因为它允许连续的流处理。从物联网的角度来看，Kafka提出了以下折衷方案:

优点

• 流处理，不仅仅是排队
• 高吞吐量
• 大规模的
• 高可用性
• 长期存储和缓冲
• 再处理的事件
• 与企业的其他部分良好集成
• 混合、多云和全球部署

缺点

• 不是为成千上万的连接而建的
• 需要稳定的网络和坚实的基础设施
• 缺乏信息技术特有的特征，比如“活着”和“遗嘱”
• 由于Kafka不是为边缘物联网通信而构建的，因此Apache Kafka和MQTT的结合是构建可伸缩、可靠和安全的物联网基础设施的天成之选。

如何将两者结合起来?

下面几节将演示三种kafka本地选项，这意味着除了MQTT设备/网关/代理和Confluent平台之外，您通常不需要其他技术来集成和处理IoT数据。

Confluent MQTT连接器(源和汇)

Kafka Connect是一个包含在Apache Kafka中的框架，它集成了Kafka与其他系统。其目的是在充分利用Apache Kafka的所有特性(例如高吞吐量、可伸缩性和可靠性)的同时，轻松地向可伸缩和安全的事件流管道添加新系统。下载和安装新的源和接收器连接器的最简单方法是通过Confluent Hub。您可以找到安装步骤、文档，甚至是开放源码的连接器的源代码。

Kafka Connect MQTT连接器是用于从MQTT代理发送和接收数据的插件。

MQTT代理是持久的，并提供MQTT特定的特性。它消耗来自物联网设备的推送数据，Kafka Connect以自己的速度拉这些数据，而不是压倒源或被源压倒。开箱即用的可扩展性和集成特性，如Kafka连接转换器和单消息转换(SMTs)，是使用Kafka连接连接器的进一步优势。

MQTT连接器独立于特定的MQTT代理实现。我曾见过几个项目在从试验项目到预生产的过渡过程中从使用mosquito to开始，然后转向可靠的、可伸缩的代理，如HiveMQ。

用于在没有MQTT  Broker的情况下摄入数据的MQTT  Proxy

在某些情况下，主要的挑战和需求是摄入数据到Kafka，以便在其他后端系统中进行进一步的处理和分析。在这种情况下，MQTT代理只是增加了复杂性、成本和操作开销。

Confluent MQTT代理交付了一个kafka本地的MQTT代理，该代理允许组织消除中间MQTT代理的额外成本和延迟。MQTT代理访问、组合和保证物联网数据流到业务中，而不增加额外的复杂性层。

MQTT代理是水平可伸缩的，从物联网设备使用推送数据，并以低延迟将其转发给Kafka代理。不需要MQTT代理作为中介。Kafka经纪人是负责物联网数据持久性、高可用性和可靠性的真相来源。

然而，尽管在集成物联网设备时，每个人都考虑诸如MQTT或OPC UA之类的物联网标准，但REST和HTTP往往是更简单的解决方案。

REST代理作为物联网集成的“简单”选项

REST Proxy为Kafka集群提供了一个RESTful接口，使其可以轻松地生成和使用消息、查看集群的状态以及执行管理操作，而无需使用本机Kafka协议或客户机。

为什么要使用HTTP(S)进行物联网集成?由于各种原因，与特定于iot的技术相比，REST Proxy使实现和部署更简单、更快、更容易:

• 它简单易懂
• HTTP代理是基于推的
• 从组织和治理的角度来看，安全性更容易——问问您的安全团队吧!
• 可伸缩性与标准负载均衡器，尽管它仍然是同步HTTP，这不是高可伸缩性的理想
• 支持数以千计的消息每秒

无论您决定如何集成物联网设备，构建可靠的端到端监控基础设施都是必不可少的。

端到端监控和安全性

分布式系统很难监控和安全。Kafka集群没有太大的不同——您必须监视和保护Kafka代理、ZooKeeper节点、客户端消费者组(Java、Python、Go、REST等)以及Connect和ksqlDB集群。

就端到端监控您的整个Kafka基础设施而言，Confluent Control Center提供了对Kafka集群内部工作和流经它们的数据的洞察。Control Center通过精心策划的仪表板为管理员提供监视和管理功能，以便他们能够提供最佳性能并满足集群的sla。这包括:

• 从生产者到代理到消费者的端到端监控
• 连接集群(源和接收)的管理，无论它是中心基础设施还是体系结构中是否有域驱动的组件
• 用于安全通信和确保遵从性的基于角色的访问控制(RBAC)
• 对可用性、延迟、消耗、数据丢失等进行监视和警报。

通过使用诸如基于角色的访问控制(RBAC)这样的安全特性，您还可以为Confluent平台的所有组件启用简单的、标准化的身份验证和授权。

为您的物联网集成挑战选择正确的组件

物联网集成场景的用例总是类似的:与设备或机器集成;将事件流数据实时输入Kafka集群(在场所或云中);使用Kafka流和ksqlDB处理数据;然后将数据发送回设备或机器，和/或其他接收器，如数据库，分析工具，或任何其他业务应用程序。

通过使用诸如客户机、MQTT连接器、MQTT代理或REST代理等kafka本地选项，您可以集成物联网技术和接口来建立一个强大但简单的体系结构，而不需要使用其他工具。这在24/7任务关键型部署中特别推荐，因为每增加一个组件都会增加复杂性、风险和成本。你有很多选择，所以选择一个最适合你的情况。

如果你想读一个完整的故事建立一个端到端物联网体系结构从边缘到云,读启用连接转换与Apache卡夫卡和TensorFlow在谷歌的云平台,专注于谷歌的云平台,融合性的云,MQTT集成构建一个可伸缩的、可靠的机器学习的基础设施。

 

这篇博客文章的内容也被记录在名为“端到端集成:物联网边缘融合云”的交互式灯板记录中。

 

原文：https://www.confluent.io/blog/iot-with-kafka-connect-mqtt-and-rest-proxy/

本文：http://jiagoushi.pro/node/1103

讨论：请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】

Linux基金会推出了EdgeX Foundry，该项目旨在为物联网计算和可互操作组件生态系统建立开放框架。

EdgeX Foundry旨在促进边缘计算的模式，其中启用的设备将不会将其数据发送回云进行处理，而是依靠本地网关设备进行计算和分析。这种方法的主要优点是减少了延迟和网络流量，并提高了安全性。对于不需要云组件的发电，智能交通灯等工业应用，这被认为是特殊的价值。或者，对于来自多个设备的数据在将其发送到云之前本地收集的更一般的应用。

根据该公告，戴尔将根据Apache 2.0许可协议贡献其Fuse框架的源代码，该框架由十多个微服务器和超过12.5万行的代码组成。该项目还将收到其他成员的代码贡献，其中包括AMD，Ubuntu，Canonical，VMWare等50家公司，但目前尚不清楚。

InfoQ已经与Linux基金会IoT高级主管Philip DesAutels进行了交流。

开发人员何时可以使用源代码？框架的哪些部分将首先提供，接下来会有什么？

Philip DesAutels：该代码将在5月31日或之前发布为EdgeX。这是因为使用125K代码行，我们进行了大规模的转换，我们正在处理从FUSE到EdgeX的命名空间重命名练习。如果一家公司在此之前想要访问，他们可以遵循一个简单的过程，并且已经有几十个这样做。简而言之，代码正在转换，事情会发生变化。

您能否高度概述框架将为开发人员提供的功能？

DesAutels：最好的方法是通过我们的架构幻灯片：

我们通过EdgeX提供的四个核心API（安全，管理，设备和服务）提供统一的框架。参与并支持EdgeX的公司的生态系统将提供汇集在一起以创建EdgeX Platforms（实施）的实际服务。就此而言，EdgeX将提供可用作参考实现的示例设备服务，支持服务，管理工具等。我们也期待EdgeX Foundry社区将其中的一些随着时间推移到生产就绪的水平，作为EdgeX Foundry开源项目的一部分。

EdgeX将提供单一的，内聚的API，还是更多或多或少是松散耦合的组件？

DesAutels：EdgeX提供了一个核心总线，将四个API统一到一个框架中，使得松散耦合的组件能够以一个连贯一致的方式进行交互。

EdgeX驱动解决方案的典型架构如何？

DesAutels：在最简单的实现中，单个网关设备具有运行在其上的EdgeX核心以及一组装置，支持和导出服务以及管理服务和安全服务。这成为边缘处理节点，在与云连接之前，与多个设备，传感器，机器等的交互在一起进行交互处理。

对于什么样的领域，您特别想到基于EdgeX的解决方案？ EdgeX适合什么典型要求？

DesAutels：社区正在为小型基础安装脚本拍摄，在EdgeX框架的适用性方面具有极大的灵活性。 灵活的设计和庞大而不断增长的生态系统意味着我们应该期待从工业到民用基础设施到企业乃至消费者的广泛适用范围。

Linux Foundation计划不是首次为建立互连的IoT设备提供标准平台的尝试。 以前的例子包括思科与其iOx平台; 太平洋西北国家实验室（PNNL）与一个基于Android的参考平台Kaval; 和欧洲电信标准协会MEC规范。 EdgeX Foundry是否会取得更大的成功还有待观察。

弗雷斯特表示，在人工智能和5G的推动下，2021年将是这一新兴技术从实验走向实际应用技术的一年。

Forrester发布了一系列关于2021年的科技预测，其中一部分是关于edge计算的坚定断言:2021年将是edge计算最终真正有价值的一年。

“到目前为止，边缘计算很有前景，但仍在发展中。到2021年，新的商业模式将会出现，促进edge在生产中的部署，”Forrester在其预测总结中说。

弗雷斯特表示，在2021年，将把edge计算“从科学项目推向真正价值”的新商业模式主要基于两个因素:云平台必须与人工智能竞争，5G的广泛普及将使edge的使用案例更加实用。考虑到这两个驱动因素，Forrester对2021年科技界将如何发展做出了五项预测，这些预测将直接影响edge计算。

 

Edge主机将发展成为一个成熟的市场

Forrester说，像Akamai和Fastly这样的内容分发网络开始瞄准边缘计算需求，这使得它们向托管公司寻求小型的、广泛分布的数据中心，在这些数据中心，应用程序可以就近托管在它们所服务的人群中。

Forrester说，即使是大型主机托管公司也缺乏满足edge计算需求所需的本地化服务，而小型本地公司需要完成他们的edge服务，往往会被这些大公司所掩盖。

弗雷斯特预测:“到2021年，对于CDNs和全球主机商来说，像Edgevana和Inflect这样的主机市场聚合商将成为有吸引力的选择，它们将服务于企业需求，甚至在农村地区。”

Kubernetes将会占据主导地位，但不会有编排的赢家

Forrester预测，到2021年，轻量级的Kubernetes部署将占到edge编配的20%，但这并不意味着edge编配的战斗就会结束。Canonical、华为、OpenStack、Rancher和其他公司也在努力扩展他们的轻量级、边缘优化平台，未来一年的竞争将会非常激烈。

人工智能将离开数据中心走向边缘

弗雷斯特预测，人工智能在边缘计算中的使用将在2021年发生重大转变:机器学习模式将开始在边缘发生，而不是在数据中心接受训练。

得益于英特尔和英伟达的新芯片，以及增强和联合学习等新的机器学习技术，这一转变将成为可能。弗雷斯特说:“Edge应用智能将在2021年开花结果，以加速数字转型，特别是在那些必须实时连接实体世界和数字世界的行业。”

私人5G网络将得到扩展

Forrester表示，来自主要电信网络的全国性5G不足以满足edge计算需求。取而代之的将是由爱立信、华为和诺基亚等制造商部署和开发的私人5G网络。

Forrester预测，到2021年，私有5G网络将被用于工厂车间自动化、用于远程检查、监视、质量保证、远程监控、预测性维护和员工安全的AR/VR等领域。

公共云的增长将会放缓，而edge的支出将会增长

Forrester预测，由于市场成熟，公共云市场的增长率将从2018年的42%下降到2022年的24%。取而代之的将是边缘计算的爆炸式增长，这意味着投资于边缘计算和内容交付的云解决方案的公司将获得更多增长，而不是集中的数据中心。

Forrester预测，公共云实体不会消失，但它们不会主导分布式计算的未来。“他们的文化基于庞大的数据中心和对架构的严格控制，这与rms需要为本地客户提供服务正好相反。”拥有获胜优势战略的供应商会做得更好。

 

原文：https://www.techrepublic.com/article/5-edge-computing-predictions-for-2021/

本文：http://jiagoushi.pro/node/1288

讨论：请加入知识星球【数据和计算以及智能】或者小号【it_strategy】或者QQ群【1033354921】

 

前几年在巴塞罗那世界移动通信大会上 - 全球首屈一指的移动消费电子产品大会 - 专注于将下一个数十亿的网络带到网上。今年在活动中，如果没有人宣传5G的承诺，你就走不了一分钟，5G是下一代蜂窝移动通信，有望带来更高的数据速率，更短的延迟和大规模的设备连接。

唯一的问题是，对于普通消费者来说，5G并不是那么惊心动魄。通过4G甚至3G连接，我们几乎可以完成所有想象。除此之外，大多数提供商，手机和本地基础设施仍然无法支持它。当你走过所有华丽的看台和西装搭配运动鞋时，5G开始感觉像是一个失去的投资。

那是因为它不适合我们。像大多数技术进步一样，工业将成为第一。 5G的承诺是无人驾驶飞机和自动驾驶车队。它是轻量级工业可穿戴设备，可以快速处理关键信息。它在机器人中。而且，是的，它是我们一直在等待的增强现实游戏，“哈利波特：奇才团结。”

5G的这一承诺最有可能在边缘发布，从会议营销到实际可行性。实际上，4G已经可以通过边缘计算提供类似5G的体验。

边缘计算入门

那边缘计算到底是什么？ MobiledgeX的首席技术官Sunay Tripathi表示：“边缘是与用户息息相关的任何东西。”该公司最近吹捧了全球首个与德国电信的公共移动边缘网络部署。

这可能是您家中的设备，如Apple TV或Alexa，或者街对面的服务器为您的社区提供服务。对他而言，这就是您的家庭互联网连接世界的方式。

Tripathi表示，“保持本地化，尽可能贴近用户，减轻公共云的压力。”MobiledgeX专注于设备移动性并利用附近的边缘服务器。

Tripathi解释说“你拥有什么样的设备并不重要。最近的通勤。“

他表示，MobiledgeX利用运营商已经在其网络中投入的数万亿美元来支持现有网络上用户之间的30毫秒以下的通信 - 任何超过30毫秒的延迟都会对性能产生负面影响。

当5G可用时，速度可能会降至10到20毫秒。 MobiledgeX会自动搜索网络尚未超额订阅的位置。

“如果您是移动用户 - 无论是汽车，卡车还是无人机 - 您都可以连接到最近的塔楼，我们将基础设施连接到您附近。我们不会改变开发人员的工作流程，“Tripathi说。

MobiledgeX仍在云中部署，在后端使用基于lambda的容器来流式传输。

使用MobiledgeX，开发人员只需为他们正在使用的内容付费，同时它会自动找到最近的边缘计算机位置，以便在短时间内为用户提供服务。

Tripathi提供了一个15分钟沉浸式视频游戏的例子。设备和/或游戏开发人员通过边缘进行连接，但开发人员只需要在公共云中使用一个CPU，而不是购买CPU两到三个月。

在传统的连接路径中，如果您在10,000个位置拥有10,000个用户，则必须支付10,000次。 Tripathi说：“而不是更加静态地部署公共云，你可以更加动态地进行更多共享。”

5G将真正发挥作用

Tripathi表示，MobiledgeX的第一年一直在缩小用例范围，例如机器人3D绘图空间，以帮助工作人员提高工作效率或丰富的视频流，这些视频流需要实时处理多个设备上的大量数据。

他继续说，需要在边缘进行5G处理，以追求更自然的界面，将视频和音频结合起来 - “我们能看到的东西和我们能感觉到的东西” - 使用更轻的设备。

“数字世界即将到来，如果你看客户端，我们越来越不使用键盘，但是，如果你看后端，它仍然设计用于更多的键盘和静态应用，”Tripathi说

如果您以一种需要更多处理需求的方式与许多音频和视觉人员打交道，那么您需要边缘计算。但是，当需要更小的设备时，它也是必要的。

与此相呼应的是，1000 Realities的联合创始人Justyna Janicka告诉The New Stack，微软的混合现实耳机HoloLens对于实用的工业物联网（IIoT）应用而言过于笨重。在相邻的图片中，她展示了如何在MobiledgeX上运行的1000 Realities app与5G相结合，使更轻巧的智能眼镜能够使用增强现实技术快速扫描数据中心服务器的温度。如果没有5G边缘计算，这种轻量级设备无法处理这种处理速度。

当您拥有众多用户并希望创建丰富的多媒体体验时，边缘计算可以降低成本和CPU的效率，而您无法将负载降至3G。

Edge将推动5G（和应用程序开发人员的利润）

5G的第一个广泛使用案例是增强现实巨头Pokemon Go。数百名怪物捕手的聚会将聚集在公园内，为附近的每个人的移动覆盖范围崩溃。 ping到塔的4G网络根本没有多个设备上的流视频和增强现实的带宽。

德国处于5G的前沿，德意志电信已经进行了巨额投资。到2020年，我们将看到全球不少主要城市拥有5G连接，尽管到那时手机是否会赶上还有待观察。

目前，在西方世界一些最拥挤的地方 - 纽约时代广场或伦敦的金丝雀码头金融区 - 公共云上有这么多用户，每个人都被降到2G，因为网络不能赶上。

发生这种情况是因为所有内容都在ping公共云，而典型的服务提供商只有大约三到四个对等点 - 它们允许用户之间的信息交换。想象一下，如果有一百人在两周的增强现实版本中进行斗争。

Tripathi认为，在设备和边缘之间，有足够的带宽可以通过视频内容和沉浸式体验实现大量的多点设备到设备交互。

他还争辩说，我们很快就会看到收入模式从最大的云提供商转向提供基础设施的人和拥有应用程序的人

“目前，云提供商正在筹集不成比例的资金，因为每个人都必须生活在公共云中，”Tripathi说。

他继续说基础设施支出已经完成，云运营商已经在使用它。边缘计算只允许每个人更有效地使用它。

Tripathi表示，最受益于这种优势的公司是许多拥有40到100名开发人员的小型应用程序开发公司。

“较小的家伙并不知道这种优势正在逐渐形成，他们实际上可以构建他们的应用程序以实现边缘化并达到其他一组客户和体验，”他说，希望他能提高认知度。

这些开发人员认为他们无法在4G带宽上制作丰富的视频。 Edge已经可以在今天的4G网络上部署，这实际上使开发人员能够提供类似5G的功能，包括现在的视频丰富的交互。

“最难的部分是接触这些小型开发商。他们只需要知道边缘存在以及构建需要什么 - 我们已经[已经]拥有稳定的软件和边缘位置，“Tripathi说。

虽然今年的移动世界大会对5G的无处不在的承诺感觉有点遥远，但当然边缘计算可以帮助应用程序开发人员实现这一承诺。

Edge Computing如何扩展5G

那么，边缘计算将如何帮助扩展5G？

对于Tripathi，他认为这很简单，因为到2019年底，我们将看到超过200亿台设备连接并在全球范围内大规模分布。前几十亿是我们无处不在的智能手机，但其余的将由连接的可穿戴设备，车辆和无人机主导。突然之间，基础设施必须处理遍布10,000个地点的数十亿台设备。

这不仅仅是生活在城市中的70％，而且还可以利用边缘计算在农村社区中使用更小，更高效的本地化服务器将下一个十亿用户带到网上。

在接下来的十年中，Tripathi将边缘计算视为公共云在过去十年中所具有的十倍影响。他表示，边缘计算将能够在更多分布式位置和架构上以每秒更多客户端的比例处理两倍的规模。

在第一次采访时，大约有五个应用程序开发人员在德国使用它和大约8,000个用户。当我们一周后在世界移动通信大会上面对面会面时，他们拥有数百万用户，其中包括围绕会议空间设置的三台边缘服务器和几十个主要城市。

美国是一个独特的用例，因为大多数国家认为手机信号塔至少部分归公众所有。在美国，既不是服务提供者也不是政府，而是主要是第三方私人企业Crown Castles和American Towers。

MobiledgeX正在与The New Stack赞助商Packet合作，他们正在这些塔楼上建立裸机基础设施。

“在接下来的移动世界大会上，我们肯定会在欧洲拥有更大的优势，而美国的优势将开始形成，”Tripathi说。

“对于开发者社区来说，世界是一个全球市场。在美国和世界其他国家推出时，你可以从德国的优势中受益。“

 

原文：https://thenewstack.io/how-edge-computing-will-deliver-on-the-promise-of-5g/

本文：https://pub.intelligentx.net/how-edge-computing-will-deliver-promise-5g

讨论：请加入知识星球或者小红圈【首席架构师圈】