├── README.md ├── docs ├── architectures │ ├── aggregation │ │ └── aws_iot_sitewise.md │ ├── cloud │ │ ├── aws_iot_core.md │ │ ├── aws_iot_device_defender.md │ │ └── aws_iot_device_management.md │ └── edge │ │ └── aws_iot_greengrass.md ├── articles │ ├── ibm_iot.md │ └── iiot4.0_guide.md ├── basic │ └── field_bus.md ├── big-data │ └── reference.md ├── edge-computing │ └── README.md ├── platforms │ └── aliyun_iot_platform │ │ ├── device_process.md │ │ └── images │ │ ├── device_process.png │ │ └── device_register.jpg └── protocols │ ├── hart.md │ ├── modbus.md │ ├── opc_ua_guide.md │ ├── opc_ua_tsn.md │ └── tsn.md └── resources └── imgs ├── AVS-Integration-For-AWS-IoT-Core-Product-Page-Diagram_SkyHook.png ├── AWS IoT Core - Connect and Manage.png ├── AWS IoT Core - Process and Act.png ├── AWS IoT Core - Read and Set Device State.png ├── AWS IoT Core - Secure Connections.png ├── AWS-Greengate-Launch_Application-Arch.png ├── AWSIoTDeviceManagement_how_it_works.png ├── Greengrass_How-It-Works.png ├── Greenkey.png ├── How it Works AWS IoT Device Defender.png ├── TSN_architecture.jpg ├── TSN_time_sync.jpg ├── UA-Architecture.png ├── aliyun_iot_platform.png ├── aliyun_iot_platform_architecture.jpg ├── aws_iot_platform.png ├── azure_iiot_platform_architecture.png ├── edge_computing_deploy_architecture.png ├── edge_computing_design_architecture.png ├── edge_computing_design_architecture_detail.png ├── field_bus_10.png ├── field_bus_demo.png ├── field_bus_development.png ├── ge_predix_asset_service.png ├── ge_predix_iiot_platform.png ├── gongzhonghao.jpg ├── huawei_iot_analyze.png ├── ibm_iot_platform_architecture_layers.png ├── iot-azure-data-explorer.png ├── it_vs_ot.png ├── modbus_master_slave.jpg ├── opc-ua_tsn_deploy_scene.jpg ├── opc-ua_tsn_network_model.jpg ├── opc_ua_information_model.jpg ├── opc_ua_tsn_communication_scene.jpg ├── opc_ua_tsn_future_industy_scnario.jpg ├── opc_ua_tsn_iec_problems.jpg ├── sitewise-how-it-works.png └── why_we_use_opc_ua.png /README.md: -------------------------------------------------------------------------------- 1 | # 工业互联网 （工业4.0） 2 | 3 | > 工业互联网涉及到的行业知识非常丰富。对于想要从事工业互联网的开发者来说，如果来开始学习工业互联网是一个非常具有挑战的问题。 4 | > 5 | > 因为本人也是刚刚进入工业互联网，这个项目主要是学习和实践中的一些总结。所以有很多不完善的地方。有任何建议和意见都可以通过issue或者pull request来贡献。也可以直接发送邮件到soolaugust@gmail.com来进行讨论。 6 | 7 | - [工业互联网 （工业4.0）](#工业互联网-工业40) 8 | - [基本概念](#基本概念) 9 | - [IT & OT](#it--ot) 10 | - [现场总线](#现场总线) 11 | - [协议和标准](#协议和标准) 12 | - [HTTP](#http) 13 | - [OSLC](#oslc) 14 | - [OPC UA](#opc-ua) 15 | - [TSN](#tsn) 16 | - [Modbus](#modbus) 17 | - [HART](#hart) 18 | - [边缘计算](#边缘计算) 19 | - [架构&设计](#架构设计) 20 | - [云端](#云端) 21 | - [边缘端](#边缘端) 22 | - [组合](#组合) 23 | - [文章](#文章) 24 | - [平台调研](#平台调研) 25 | - [大数据相关](#大数据相关) 26 | - [网站](#网站) 27 | - [工具](#工具) 28 | - [消息队列 (MQ)](#消息队列-mq) 29 | - [其他](#其他) 30 | - [公众号](#公众号) 31 | 32 | ## 基本概念 33 | 34 | ### IT & OT 35 | 36 | IT (Information Technology)，即信息技术，是用于管理和处理信息所采用的各种技术总称，主要是应用计算机科学和通信技术来设计、开发、安装和实施信息系统及应用软件。 37 | 38 | OT (Operational Technology)，指操作技术，是工厂内的自动化控制系统操作专员为自动化控制系统提供支持，确保生产正常进行的专业技术。 39 | 40 | IT/OT的融合是近几年的热点，其大致意思是通过打通制造执行系统与运营管理系统之间的数据链路，并将二者整合在一个统一的信息平台上，从而帮助企业提升在生产管理、运营决策与制造执行等各方面的综合效益。但知难行易，将OT与IT融合并不是一件容易的事情，制造企业除了需要面对跨界投入不稳定、不确定的风险以及设备、专业IT人力等成本的挑战外，IT与OT本身的特性也为二者融合设置了障碍。 41 | 42 | ![](resources/imgs/it_vs_ot.png) 43 | 44 | ### 现场总线 45 | 46 | * [现场总线](docs/basic/field_bus.md) 47 | 48 | ## 协议和标准 49 | 50 | ### HTTP 51 | 52 | * [透视 HTTP 协议](https://zq99299.github.io/note-book2/http-protocol/) 53 | 54 | ### OSLC 55 | 56 | * [OSLC官网](https://open-services.net/) 57 | 58 | ### OPC UA 59 | 60 | * [OPC UA官网](https://opcfoundation.org/about/opc-technologies/opc-ua/) 61 | 62 | * [OPC UA协议](docs/protocols/opc_ua_guide.md) 63 | 64 | * [OPC UA TSN](docs/protocols/opc_ua_tsn.md) 65 | 66 | ### TSN 67 | 68 | * [TSN时间敏感网络协议](docs/protocols/tsn.md) 69 | 70 | ### Modbus 71 | 72 | * [Modbus协议](docs/protocols/modbus.md) 73 | 74 | ### HART 75 | 76 | * [什么是HART协议](docs/protocols/hart.md) 77 | 78 | ## 边缘计算 79 | 80 | * [边缘计算](docs/edge-computing/README.md) 81 | 82 | ## 架构&设计 83 | 84 | ### 云端 85 | 86 | * [AWS IoT Core设计解析](docs/architectures/cloud/aws_iot_core.md) 87 | * [AWS IoT Device Defender设计解析](docs/architectures/cloud/aws_iot_device_defender.md) 88 | * [AWS IoT Device Management设计解析](docs/architectures/cloud/aws_iot_device_management.md) 89 | 90 | ### 边缘端 91 | 92 | * [AWS IoT Greengrass设计解析](docs/architectures/edge/aws_iot_greengrass.md) 93 | 94 | ### 组合 95 | 96 | * [AWS IoT SiteWise设计解析](docs/architectures/aggregation/aws_iot_sitewise.md) 97 | 98 | ## 文章 99 | 100 | * [杂谈：一文了解工业4.0](docs/articles/iiot4.0_guide.md) 101 | * [数据模型设计](docs/articles/ibm_iot.md) 102 | 103 | ## 平台调研 104 | 105 | * [阿里云物联网平台](docs/platforms/aliyun_iot_platform) 106 | 107 | ## 大数据相关 108 | 109 | * [工业大数据](docs/big-data/reference.md) 110 | 111 | ## 网站 112 | 113 | * [数字孪生体 - 开源工业互联网平台](https://digitaltwin.openii.cn/) 114 | * [Next Generation Data Integration Solutions (OSLC)](https://koneksys.com/) 115 | 116 | ## 工具 117 | 118 | ### 消息队列 (MQ) 119 | 120 | **服务器** 121 | 122 | * [EMQ Broker](https://www.emqx.io/products/broker) 123 | 124 | **客户端测试工具** 125 | 126 | * [MQTT Websocket Toolkit](http://tools.emqx.io/) 127 | 128 | ## 其他 129 | 130 | ### 公众号 131 | 132 | 如果大家想要实时关注我更新的文章和其他的分享，可以关注我的公众号"yuye_suibi"。 133 | 134 | ![](resources/imgs/gongzhonghao.jpg) -------------------------------------------------------------------------------- /docs/architectures/aggregation/aws_iot_sitewise.md: -------------------------------------------------------------------------------- 1 | # AWS IoT SiteWise设计解析 2 | 3 | > 官网：[https://amazonaws-china.com/cn/iot-sitewise/?c=i&sec=srv](https://amazonaws-china.com/cn/iot-sitewise/?c=i&sec=srv) 4 | 5 | 事实上我们在设计工业物联网时，有时可能并不需要一个完成的平台来处理设备的管理或者和云端的交互，或者说我们需要一个更为轻量级或者单体式的应用来处理我们的数据和设备监控。 6 | 7 | 基于此，AWS设计了另外一套数据采集组件IoT SiteWise。这个设计目的在官网中也有体现： 8 | 9 | > **从工业设备中轻松地大规模收集、组织与分析数据** 10 | 11 | ![](../../../resources/imgs/sitewise-how-it-works.png) 12 | 13 | ## 面临的挑战 14 | 15 | 从工业设备中获取性能指标非常困难，因为数据通常被锁定在专有的本地数据存储中，且通常需要专业知识来检索数据并将其转换为有助于分析的格式。所以数据搜集第一个面临的挑战是如何一致性收集。 16 | 17 | 另一个就是数据的利用，除了提供给上层程序，更多时候我们需要直接能够看到我们搜集到的数据，并且如果可以监控数据来发现问题。 18 | 19 | 基于这种基本需求，IoT SiteWise分析出了下面的特点： 20 | 21 | * 从所有来源一致地收集数据 22 | * 通过远程监控快速识别问题 23 | * 使用中心数据源改进跨设施流程 24 | 25 | 所以在设计上，IoT SiteWise内置了需要的数据收集、管理与可视化功能。来帮助采集和管理数据。 -------------------------------------------------------------------------------- /docs/architectures/cloud/aws_iot_core.md: -------------------------------------------------------------------------------- 1 | # AWS IoT Core设计解析 2 | 3 | > 官网：[https://amazonaws-china.com/cn/iot-core/?c=i&sec=srv](https://amazonaws-china.com/cn/iot-core/?c=i&sec=srv) 4 | 5 | AWS IoT Core是AWS IoT云端设计的核心业务，在设计时明确了其目的： 6 | 7 | > **轻松安全地将设备连接到云。可靠地扩展至数十亿台设备以及数万亿条消息。** 8 | 9 | IoT Core面临的场景就是如何将设备更好的连接到云端。基于这个目的拓展了以下的设计要求： 10 | 11 | * **轻松连接**：因为设备端的复杂性和性能要求，如何让设备端以最小的代价连接云端是云端设计的基本要求 12 | * **安全连接**：这个也是设计上需要重点考虑的，物联网连接无论如何设计，安全都是首要的设计目的，特别是连接云端后，如何保证设备的安全运行是云端设计的重要内容 13 | * **可靠性**：云端连接面临着众多设备和应用的交互，可靠性是需要重点保证的 14 | * **可拓展性**：这个需求来源于设备端的复杂性和物联网技术的更新迭代速度 15 | 16 | ## 轻松连接 17 | 18 | ![](../../../resources/imgs/AWS%20IoT%20Core%20-%20Connect%20and%20Manage.png) 19 | 20 | AWT IoT Core为了保证设备能够轻松连接，支持了多种通信协议，包括带宽和资源占用低的MQTT等协议。同时支持多种行业标准和自定义协议，保证设备即使使用不同的协议也能相互通信。 21 | 22 | ## 安全连接 23 | 24 | ![](../../../resources/imgs/AWS%20IoT%20Core%20-%20Secure%20Connections.png) 25 | 26 | AWT IoT Core为了保证设备连接和通信数据的安全，在设计上采用首次连接提供自动配置，身份验证和端到端加密。保证在没有验证身份的情况下，不会进行任何的数据交换。 27 | 28 | 同时为上层应用提供权限配置的接口来进一步保护设备和数据。 29 | 30 | ## 数据处理 31 | 32 | ![](../../../resources/imgs/AWS%20IoT%20Core%20-%20Process%20and%20Act.png) 33 | 34 | 数据处理是云端的基本功能，IoT Core在设计上增加了规则引擎，这个也是自动化和报警等功能的基础。通过规则引擎，应用可以筛选和转换设备数据并执行操作。 35 | 36 | 同时集成了上层的IoT Cloud服务，来提供更为强大的功能，之所以将这些服务外包而不是集成在IoT Core中，一方面是为了保证IoT Core的业务清晰，是架构设计中的范围划定的考虑。另一方面是因为这些服务是会不断增加的，而且不是每一个云端或设备都必须的，也就是可以灵活配置的，所以独立处理啊更为合理。 37 | 38 | ## 设备影子 39 | 40 | ![](../../../resources/imgs/AWS%20IoT%20Core%20-%20Read%20and%20Set%20Device%20State.png) 41 | 42 | 设备影子或类似的概念是所有云端设计的核心工业，也是物联网架构中的重要内容，其来源是因为设备端的不可靠性，无论是设备本身还是与设备的连接，那么如果上层应用直接操作真实设备，那么就会有很多不可知的情况发生。所以一般都会在中间抽象一层，在IoT Core中也就是设备影子。通过这一层，屏蔽了设备端的不可靠情况，保证上层应用的访问。通过同步来保证设备影子的更改都会反应到真是设备中，也能保证真实设备和设备影子状态同步。 43 | 44 | ## 设备能力抽象 45 | 46 | ![](../../../resources/imgs/AVS-Integration-For-AWS-IoT-Core-Product-Page-Diagram_SkyHook.png) 47 | 48 | AWS IoT Core设计中的一大亮点就是设备能力的抽象，比如虚拟AVS服务，使得音频的处理能力放置到云端，这样设备的成本就会很低，只需要处理音频的输入和输出。这是一种设备计算能力的云端抽象化。 49 | 50 | ## 总结 51 | 52 | AWS IoT Core在设计上基于让设备轻松安全连接的目的，在架构上保持Core核心业务的独立性，其他云端服务通过集成的方式来配置。并通过设备影子的方式屏蔽了下层设备的不可靠性。有亮点的是设备能力的抽象，从而解放了设备的计算能力，让设备的成本可以更低，同时计算资源也更为可控。事实上对于边缘端的设备也可以参考这一点，将计算能力外置到云端或者边缘端。 -------------------------------------------------------------------------------- /docs/architectures/cloud/aws_iot_device_defender.md: -------------------------------------------------------------------------------- 1 | # AWS IoT Device Defender设计解析 2 | 3 | > 官网：[https://amazonaws-china.com/cn/iot-device-defender/?c=i&sec=srv](https://amazonaws-china.com/cn/iot-device-defender/?c=i&sec=srv) 4 | 5 | 在物联网架构中，安全是最为重要的，特别是工业物联网，设备的安全是关系到财产甚至生命的事情。这也是AWS设计IoT Device Defender的需求来源。这个在IoT Device Defender的官方介绍中来说明了： 6 | 7 | > **IoT 设备的安全管理** 8 | 9 | ## IoT 安全性为什么重要 10 | 11 | 连接的设备使用不同种类的无线通信协议不断地与其他设备和云进行通信。在通信催生响应式 IoT 应用程序的同时，它也会公开 IoT 安全漏洞，并为恶意角色或意外数据泄漏打开通道。为了保护用户、设备和公司，必须确保 IoT 设备安全并得到保护。IoT 安全性的基础在于控制、管理和设置设备之间的连接。适当的保护措施有助于保持数据的私密性，限制对设备和云资源的访问，提供安全的方式连接到云，以及对设备的使用情况进行审核。IoT 安全性策略通过使用诸如设备身份管理、加密和访问控制等此类策略来减少漏洞。 12 | 13 | ## IoT 安全面临的挑战是什么 14 | 15 | 安全漏洞是可被利用以损害 IoT 应用程序的完整性或可用性的弱点。IoT 设备在本质上是易受攻击的。IoT 队列由设备组成，这些设备具有截然不同的功能、使用寿命较长且地理位置分散。这些特性结合设备数量不断增长，对我们如何应对 IoT 设备所带来的安全风险提出了挑战。 为了更详细地说明安全风险，许多设备具有低级的计算、内存和存储功能，这限制了在设备上实施安全性的机会。即使您已实施了安全性最佳实践，新的攻击媒介也会不断涌现。**为了检测和缓解漏洞，组织应始终不断地审核设备设置和运行状况**。 16 | 17 | ## 设计 18 | 19 | 基于上面所说的IoT安全面临的挑战，AWS IoT Device Defender在设计时确立了一下的目标： 20 | 21 | * 审核设备配置，检查安全漏洞 22 | * 持续监控设备行为以发现异常 23 | * 接收提醒并采取措施 24 | 25 | ![](../../../resources/imgs/How%20it%20Works%20AWS%20IoT%20Device%20Defender.png) 26 | 27 | ### 审核设备配置，检查安全漏洞 28 | 29 | AWS IoT Device Defender 根据一组定义的 IoT 安全最佳实践来审核与您的设备相关的 IoT 配置，以帮助您确定存在安全漏洞的确切位置。您可以持续或即时运行审核。AWS IoT Device Defender 提供一系列安全最佳实践，您可以从中选择适用的最佳实践并将其作为审核的一部分运行。例如，您可以创建一项审核，检查 7 天内未激活、已撤销、已过期或正在等待转移的身份证书。通过审核，您可以在更新 IoT 配置时接收提醒。 30 | 31 | ### 持续监控设备行为以发现异常 32 | 33 | AWS IoT Device Defender 通过监控来自云和 AWS IoT Core 的高价值安全指标，并将其与您定义的预期设备行为进行比较，来检测可能表明设备受损的异常行为。例如，借助 AWS IoT Device Defender，您可以定义设备上开放的端口数量、设备的通信对象、设备的连接来源以及设备发送或接收的数据量。然后，该服务会监控设备流量，并在发生异常（例如流量从设备传输到已知恶意 IP 或未授权终端节点）时向您发送提醒。 34 | 35 | ### 接收提醒并采取措施 36 | 37 | 当审核失败或检测到行为异常时，AWS IoT Device Defender 会向 AWS IoT 控制台、Amazon CloudWatch 和 Amazon SNS 发布安全提醒，以帮助您调查和确定根本原因。例如，AWS IoT Device Defender 会在设备身份访问敏感 API 时向您发送提醒。AWS IoT Device Defender 还可以提供可用于最大限度降低安全问题影响的建议措施，例如撤消权限、重启设备、重置工厂默认设置或向任何连接的设备推送安全修补程序。 38 | 39 | ## 总结 40 | 41 | AWS IoT Device Defender在设计时根据目前IoT设备安全的需求，分析了所面临的挑战，包括设备易受攻击，因为性能等原因无法在设备实施安全，新的攻击媒介等原因，得出设备安全需要不断审核和分析。所以在设计上采用了分层设计，在数据收集层IoT Core和云端其他层中建立了IoT Device Defender层，使得所有的数据交互和设备信息都经过IoT Device Defender，这样可以不断监控和管理设备的安全。 -------------------------------------------------------------------------------- /docs/architectures/cloud/aws_iot_device_management.md: -------------------------------------------------------------------------------- 1 | # AWS IoT Device Management设计解析 2 | 3 | > 官网：[https://amazonaws-china.com/cn/iot-device-management/?c=i&sec=srv](https://amazonaws-china.com/cn/iot-device-management/?c=i&sec=srv) 4 | 5 | 在工业物联网架构设计中，我们除了考虑设备和云端的交互，还要考虑设备的规模，许多 IoT 部署由几十万至数百万台设备组成。所以AWS在云端设计上增加了IoT Device Management组件。其目的在官网中也进行了说明： 6 | 7 | > **大规模注册、组织、监控和远程管理互联设备** 8 | 9 | IoT Device Management这个组件并不属于必需组件，但是在工业物联网中却是不可缺少的一环。大规模的设备管理包括设备的注册，管理。所以继续拆分需求，AWS将大规模设备需求分析如下： 10 | 11 | * 快速注册设备 12 | * 简单的 IoT 设备组织 13 | * 快速定位连接的设备 14 | * 轻松进行远程设备管理 15 | 16 | ![](../../../resources/imgs/AWSIoTDeviceManagement_how_it_works.png) 17 | 18 | 在设计上，IoT Device Management采用插件式的设计，和IoT Core和IoT Device Defender协同工作，完成设备的注册，管理，配置下发，推送更新等功能。 -------------------------------------------------------------------------------- /docs/architectures/edge/aws_iot_greengrass.md: -------------------------------------------------------------------------------- 1 | # AWS IoT Greengrass设计解析 2 | 3 | > 官网：[https://amazonaws-china.com/cn/greengrass/?c=i&sec=srv](https://amazonaws-china.com/cn/greengrass/?c=i&sec=srv) 4 | 5 | AWS设计IoT Greengrass的目的在官网上就说明了： 6 | 7 | > **将本地计算、消息收发、数据管理、同步和 ML 推理功能引入边缘设备** 8 | 9 | 这个需求在目前很多工业物联网边缘计算项目中都会遇到，那么我们看一下AWS是如何来进行设计和架构的。 10 | 11 | ![](../../../resources/imgs/Greengrass_How-It-Works.png) 12 | 13 | 这图的设计来源于边缘设备的原始需求：如何连接云和设备。这里主要在需求上考虑了以下几点： 14 | 15 | * 将云端的能力下发到设备上，这里主要是：本地执行 AWS Lambda 代码 16 | * 消息收发 17 | * 数据管理 18 | * 安全策略 19 | 20 | 那么在实际场景中就要考虑如何和设备以及云端进行更好的连接： 21 | 22 | * 设备端：由于设备端情况复杂，规格不一，通信协议不一致等问题，AWS在考虑上采用了三方面适配，IoT Greengrass端适配，设备端采用sdk工具包进行适配，设备端适配。通过这种方式来屏蔽设备端的差异。 23 | * 云端：云端的链接除了安全之外要考虑现场的网络复杂性，重点是和云端的连接并不可靠，可能是断断续续的连接，所以在设计上要着重对这一情景进行支持。 24 | 25 | ![](../../../resources/imgs/AWS-Greengate-Launch_Application-Arch.png) 26 | 27 | 基于上面的考虑，AWS在设计上又增加了对设备端和云端的连接模块。这一部分拆分是为了更好了区分连接和边缘能力，这在架构上就是边界的划定。通过这一架构，当我们连接不同的设备或者云端时，我们只需要更改我们使用的连接器。 28 | 29 | ![](../../../resources/imgs/Greenkey.png) 30 | 31 | 那么边缘能力中，AWS着重描述了安全能力，考虑到设备端很多时候并不具备安全加密的能力，所以由边缘设备来完成更为强大的信息加密功能。 32 | 33 | ## 总结 34 | 35 | AWS在设计边缘端IoT Greengrass时分析了边缘端的场景，引出了边缘端设计的目的 “将本地计算、消息收发、数据管理、同步和 ML 推理功能引入边缘设备”。考虑了设备端和云端连接的复杂场景，在设计上采用了**不变的核心功能和可变的连接功能**分开的设计。并在边缘端的硬件设计上采用了硬件保护来进一步增加设备端和云端的信息保护。 -------------------------------------------------------------------------------- /docs/articles/ibm_iot.md: -------------------------------------------------------------------------------- 1 | > 文章参考： 2 | > 3 | > * [从应用层表象出发进行 IoT 架构抽象设计](https://developer.ibm.com/zh/articles/iot-lo-architecture-design-from-application-layer/) 4 | > 5 | > * [全异步的通用高性能物联网架构参考实践](https://developer.ibm.com/zh/articles/iot-lo-architecture-design-from-application-layer2/) 6 | > 7 | > * [高级数据抽象模型下 IoT 的次级数据扩展](https://developer.ibm.com/zh/technologies/iot/articles/iot-lo-architecture-design-from-application-layer3/) 8 | 9 | # 数据模型设计 10 | 11 | - [数据模型设计](#数据模型设计) 12 | - [面临的挑战](#面临的挑战) 13 | - [海量场景的多样性](#海量场景的多样性) 14 | - [应用和设备高耦合](#应用和设备高耦合) 15 | - [前提条件](#前提条件) 16 | - [数据设计](#数据设计) 17 | - [五元组设计](#五元组设计) 18 | - [例子](#例子) 19 | - [设备关系设计](#设备关系设计) 20 | - [架构设计](#架构设计) 21 | - [设计思想](#设计思想) 22 | - [同步还是异步](#同步还是异步) 23 | - [数据库快照和影子机制](#数据库快照和影子机制) 24 | - [设计方案](#设计方案) 25 | - [目标](#目标) 26 | - [分层设计](#分层设计) 27 | - [拓展场景](#拓展场景) 28 | - [边缘计算下的智能属性融合](#边缘计算下的智能属性融合) 29 | - [设备聚合下的抽象设备概念](#设备聚合下的抽象设备概念) 30 | - [事件数据记录和预聚合](#事件数据记录和预聚合) 31 | - [应用服务的设备抽象](#应用服务的设备抽象) 32 | 33 | ## 面临的挑战 34 | 35 | ### 海量场景的多样性 36 | 37 | **设备异构** 38 | 39 | IoT设备有着不同的 CPU 能力和差异巨大的网络环境，直接导致了设备能够处理的数据量、相应处理的延迟时效、重试机制、通信失败与异常的情况比例都存在巨大差异。有时候可能一个命令的下发，回应是分钟甚至是小时级别，所以架构在针对硬件接入这一层上，把这些因素都抽象归总在一起做到完全向上隔离，是一个非常重要的基础要求。 40 | 41 | **多种非标准的接入协议** 42 | 43 | 由于各类 IoT 设备的接入能力、厂商能力和经验以及对应通信模块固件的功能差异，在一个众厂商、多类设备的应用场景下，往往会并存各类完全不同的接入协议而没有一个公认的参考标准。 44 | 45 | **多版本并存** 46 | 47 | 即使对于同一个供应商给出的同一款设备，换代升级的时候也还是会面临到一些功能新增、前向不能兼容等等问题，而且某些设备也并不天然具备 OTA 升级等动态更新固件的功能。也就是说，在实际应用场景当中，可能会存在同时有多个版本的协议并存，在这种情况下，如何能够做到全向兼容，就是一个非常重要的问题了。 48 | 49 | ### 应用和设备高耦合 50 | 51 | 考虑到紧张的研发周期、快速的需求迭代周期和有限的人力等因素，那在各种适配定制开发的过程中，几乎无法避免的会引入应用服务、设备接入过度耦合、不同型号设备技术实现混杂等问题。而这些必然会产生的问题，在某款设备出现故障、一款设备的非同步升级迭代、应用需求的差异化变更等情境下，就会进一步放大，以至于持续性的修补而给系统带来更多对稳定的不确定性影响。 52 | 53 | ## 前提条件 54 | 55 | * 所有的操作一定是针对设备的`独立操作`(即使是批量的) 56 | * 每一个设备返回结果的时间和数据都是`不可预知的`，考虑到环境、设备状态等变量因素。 57 | * 所有的设备数据都是以设备为逻辑进行更新同步的，云端无法主动且可信的修改。 58 | * 设备的主要操作可以归类为4类：`创建/删除，配置，状态读取，功能调用`。 59 | * 针对同一类设备，所期望提供的`功能是一致`的。 60 | 61 | ## 数据设计 62 | 63 | ### 五元组设计 64 | 65 | | 名称 | 说明 | 例子 | 66 | | :-- | :-- | :-- | 67 | | ID | 用来唯一标识一个物理终端的识别码 | 车牌号 | 68 | | 固有属性 | 终端无法修改的属性，出厂固有 | 厂商 | 69 | | 可配置属性 | 可以通过某种方式调整并影响工作状态的参数 | 车内预设温度 | 70 | | 只读属性 | 只能由终端上报且不可配置的属性 | 信号强度 | 71 | | 功能函数 | 通过传入特定的参数，执行设备的操作 | 开锁 | 72 | 73 | 通过清晰完整的五元组描述，针对下述场景基本就可以实现 100%的覆盖了： 74 | 75 | * 查询某一个终端的出厂信息及型号（固有属性） 76 | * 调整某一个终端的工作参数（可配属性） 77 | * 终端主动上报工作状态（只读属性） 78 | * 启动某一个终端的特定功能（功能函数） 79 | 80 | #### 例子 81 | 82 | | 对象 | 操作 | 五元组等价 | 83 | | :-- | :-- | :-- | 84 | |电表|抄电表号为 A 的表读数|功能函数{读数}({A}) -> {读数}| 85 | |货车|A 火车上报位置|更新 A 的云端只读属性{位置}| 86 | |智能灯|调整灯 A 的亮度|配置 A 的可配属性{亮度}| 87 | |智能锁|开 A 的锁|功能函数{开锁}({A})| 88 | |智能音箱|更换 A 的人声|配置 A 的可配属性{口音}| 89 | 90 | ### 设备关系设计 91 | 92 | 通过五元组，我们可以定义一个独立的设备，但是如何表现设备之间的关系，却不是五元组可以解决的。这里我们就要引入树形结构，而树形结构我们可以通过带有树形结构的描述语言或者增加字段来实现，这里作者采用了`树形结构的描述语言`。 93 | 94 | |语言|优势|劣势| 95 | |:--|:--|:--| 96 | |Protobuf|有完善的多语言映射工具和语法工具|定义较为复杂，工具链的应用环境较麻烦| 97 | |Java|面向对象有天然的支持且贴近应用|有很多的约定特性是多余的| 98 | |JSON|简洁的数据定义模型，字典和数组的组合可以有效描述，灵活性强|为了可以字符串化，标号过多，影响直观可读性，手写容易搞错| 99 | |YML|极致简洁，而且刚刚好的贴合了设计要求，是的，依稀记得第一次见到 yml 格式时的激动情绪|需要自己写解析，不过这都不是事| 100 | 101 | 这里作者选中了`yml`,并约定了五元组的格式： 102 | |前缀|类型| 103 | |:--|:--| 104 | |k-|ID| 105 | |p-|固有属性| 106 | |c-|可配属性| 107 | |r-|只读属性| 108 | |f-|功能函数| 109 | 110 | 通过这种定义，既定义了终端，也定义了终端之间的联系。如果需要额外的描述，可以增加其他的属性来进行拓展。 111 | 112 | ## 架构设计 113 | 114 | ### 设计思想 115 | 116 | #### 同步还是异步 117 | 118 | 由于物联网设备存在海量的设备接入场景，并且由于性能和网络原因，无法提供最佳的响应时间。所以`同步的方式并不适用`。所以可以采取基于事件驱动模型的异步方式，增加总线来通知设备的响应结果。 119 | 120 | #### 数据库快照和影子机制 121 | 122 | 由于设备都是由当前的状态信息与可配置的参数信息构成，且设备的状态信息往往是通过某种策略设备主动或被动反馈的，再考虑到设备反馈的时效性，理论上我们可以`将设备的状态抽象成一个不定时更新的数据库表`。这样的一个数据库表的抽象，基本就可以实现完整的业务应用解耦了，而且在不影响使用效果的前提下，也能极大的疏解性能压力，提高效率。 123 | 124 | 而针对设备可配置参数，我们将引入另一个设计方案即影子同步机制。`影子与本体，分别代表着我们最后一次对设备的期望配置参数与设备反馈来最新的设备上配置参数`。之所以要这样做，是因为由于网络、设备异常等各种问题的存在，一个配置下发的命令并不一定能够很好的执行成功。而由于超高延迟和重试机制的存在，配置设备的应用测也不可能做到等待每一个配置成功还是配置失败。在这种前提下，发现需要重配的设备，获取设备的要求配置参数以及获 取设备的当前工作状态就变的很重要了。影子机制的实现，在数据库里体现为两个基本完全一致定义的表。其中，`所有请求设置设备参数的调用都会直接更新影子表，而所有来自设备的实际参数上报则会直接更新本体表，也就是使用者通过对本体表的查询就能获取实际的设备状态。`当设备返回配置失败的时候，可以通过比较影子与本体表的差别，重新设置为最新的参数。如果请求设置设备的时候设备是离线的，那么当设备上线会主动比对一下影子与本体表是否有差异，如果有差异则立即执行配置命令。 125 | 126 | ### 设计方案 127 | 128 | #### 目标 129 | 130 | * 应用开发和设备接入完全解耦 131 | * 同类设备下不同厂商不同批次设备可以无感知接入 132 | * 被动记录所有设备的关键操作 133 | 134 | #### 分层设计 135 | 136 | 基于我们的设计目标，我们采用最为有效的三层设计模型：设备端适配层，中间路由层，应用服务层。 137 | 138 | ![](../../resources/imgs/ibm_iot_platform_architecture_layers.png) 139 | 140 | **路由层** 141 | 142 | 所有的请求和通报都会经过本层来完成转发。路由层提供抽象的数据标准实现，即针对一个设备五元组（ID、固有属性、可配属性、只读属性、功能函数）的 CUDF(Create、Update、Delete、Function) 操作。 143 | 144 | 在设计上考虑如下几点： 145 | 146 | * 来自服务层的更新请求只能更新可配属性。 147 | 针对可配属性更新调用配套影子机制，服务层的执行结果为更新影子配置，适配层的执行结果为更新本体配置。 148 | * 创建一个设备的时候 ID 和固有属性都是必带初始化参数，固有属性（除创建外）是完全只读，不提供任何修改接口支持。 149 | * F 操作对象只能是 f 属性，并且需要携带 f 属性约定的 arg 字典作为参数（python 的函数传参底层实现也是一个字典而不是像 C 一样的约定栈序）。 150 | 除了 F 操作外，CUD 操作都会直接完成对应数据库的操作，即数据库里的数据永远等同于最新一次操作后的状态。 151 | * 由于设备的操作粒度是基于个体的，所以任何一次 CUDF 请求，都能且仅能携带一个设备 ID。这个很好理解，即使携带了一组 ID 做同样操作，每一个设备都可能因为网络、设备、工作状态等因素而返回不可预知的不同结果。 152 | 153 | 一次 CUDF 操作在完成数据库更新的同时或之后，会在对侧消息总线上发送一条包含本次请求四元组（ID、类型 C/U/D/F、参数组 -dict、taskID）的消息。关于 taskID 对应一次请求行为结果的追踪。 154 | 155 | 所有信息的获取都可以通过两种方式直接完成： 156 | * 应用侧的请求发起调用后，等待来自于适配层的操作消息返回，从结果中获取最新值。 157 | * 另一种获取方式为直接查表获取设备的最近同步状态。 158 | 159 | 拆分来看，针对固有属性肯定查表获取的值都是正确的，配置类属性则每次变更一定是应用侧发起，所以`通过返回结果获取是最准确的`。而设备的状态则一般为适配层自带的逻辑实现，或计划任务式的心跳判断，或设备主动上报的状态同步事件，或其他自定义的判断逻辑，这些更新都是即时写入到数据库的，而且更新频率一般情况下都是分钟级甚至更久，所以`查库获取到的参数时效性正常情况都是没有问题的`。 160 | 161 | 由于转发着所有的服务层请求以及适配层回应，以及所有的适配层通报，所以`理论上只要我们将所有的请求追踪落库，写入操作 ID、Action 与携带信息，并且通过 taskID 来匹配请求与响应，我们就可以在极少的开发量支持下完成接入本架构所有智能硬件设备的所有操作与通报行为埋点`了，而且即使后续新增接入设备，我们也不需要扩充我们的代码，被动就具备了这样一个新技能，是不是想想就很激动？而且还有一点，由于理论定义的完备性，我们设置不需要考虑会不会有没有覆盖到的行为操作，因为从设计本源上就决定了这套方案能记录我们能记录的最全埋点信息。 162 | 163 | **适配层** 164 | 165 | 在分布式的多节点部署模式下，针对消息的解读有两种模式，一种是抢占式，一种为匹配式。 166 | 167 | 如果是无连接应用，则发送给一个设备的消息可以由一个分布式集群中的任何一个实例发起，这种情况下抢占式的消息接收模式就很合适了，可以保证没有多余的系统资源浪费，同时又能够实现配置要求。 168 | 169 | 如果是 TCP 长链接类的设备唯一绑定一个节点的应用，则需要使用匹配模式，即分布式集群中的所有节点都需要收到消息的一个拷贝副本，然后判断收到的消息是否在自己的连接池中，如果在的话则处理消息与设备交互产生结果，不在的话则直接丢弃。相比于抢占模式，匹配模式最大的缺点就在于存在大量的冗余消费行为，当节点数过多的时候这个单机匹配的命中率就会越低，所以在设备有频繁的服务侧交互且适配层分布式节点数量过多的时候，还是需要进行必要的定向优化，以提升系统的吞吐量。 170 | 171 | `适配层除了能够完全隔离来自于设备协议和性能等客观差异情况带来的隔离传播外，还可以很好的完成故障阻断和动态扩容`。 172 | 173 | 当某一节点甚至整个适配层集群出现故障，其他的节点或者其他的设备由于与中心路由层的依赖关系只有消息读取和请求调用，所以即使共用一个路由也不会收到负面影响，从服务层来看只是受影响的个别设备或同类设备出现的无法在有效时间内响应异常，并不会严格意义上影响系统工作状态。 174 | 175 | 另外需要注意的一个问题是，有时候我们可能会有非状态类的应用模式，如数据流的原始数据大数据存储等，这种情况下`我们可以再应用层上开辟一个临时专用通道来完成对应的结果需求输出，从而可以至少临时性的满足业务侧需求。` 176 | 177 | **服务层** 178 | 179 | 路由接入方式也是包括 RPC 类 CUDF 调用请求以及监听 Kafka 总线来获取反馈消息。由于我们的数据声明模型提供了可供自由组合的完整原子操作集，所以业务侧可以根据数据模型定义按需组合出自己期望的调用模式。 180 | 181 | 当一次服务侧的请求调用，可能因为设备离线、故障、网络不稳定、性能阻塞等等各种原因面临随机性的失败、高延迟等情况，所以使用异步调用模式，即请求发出后即生成一个 taskID 追踪号返回给服务侧，同时把这个 taskID 协同本次请求发射到适配层，这样本次操作的执行过程就会全程携带 taskID，直到适配层执行完毕后，将带有 taskID 的 CUDF 操作再一次通过路由层发送到服务层的消息总线上，侦听总线的服务侧对应程序就可以通过 taskID 来甄别是否是自己发起的调用了。 182 | 183 | ## 拓展场景 184 | 185 | ### 边缘计算下的智能属性融合 186 | 187 | 由于云分析天然存在对传输延时、传输带宽、公网联通性等外部环境的依赖问题，所以一般意义上我们采用的都是设备局部环境内通过近距通道接入一些分析机（一般为 PC/盒子）来实时分析的方式来扩展设备的这些能力，也就是这些能力并不能有终端本身来完成。 188 | 189 | 虽然数据并不直接由终端本身直接产出，但是由于终端是分析节点的注入的数据源，所以边缘分析的结果一般都唯一关联到源头终端（数据来源于多个终端的情况会在下一节说明），也就是严格意义上划属于基于设备根节点扩展的基础属性，进而也就可以进行直接的数据关联。即使是进行参数调配、算法调配，虽然有可能是批量成组的修改，但原子粒度也一定是映射到某个终端的分析标准，所以也都是可以认为针对于终端节点或者终端子节点的创建、修改操作。 190 | 191 | ### 设备聚合下的抽象设备概念 192 | 193 | 某些情况下，我们的分析结果是以一组设备的汇聚数据流为输入的。这时候我们可以抽象一个虚拟设备可以提供完备的功能。虽然数据来源可能来自于多个同类或者不同类型的设备，部分特殊场景下甚至在物理上相距很远的不同终端，但是数据的输出都可以认为是一个看起来像一个设备的虚拟设备代理的身份输出的。也就是说，我们将用来做数据输出的这个设备抽象出来成为一个定义的设备节点，理论上也可以清晰的满足使用者的需求。 194 | 195 | ### 事件数据记录和预聚合 196 | 197 | 对于一个设备来讲除了可以读取的瞬态变量外，还有大量事件需要行为来进行记录。虽然原则上，这应该是来自于服务侧进行的应用策略，但是换个角度来看，事件亦属于创建后无法配置且无法更改的一种特殊节点，由设备的 ID 与流水创建的标示 ID 唯一的定位。 198 | 199 | 事件类应用本身还可以进行一个扩展，也就是在大数据分析场景下的一种特例应用，即预聚合。我们在进行分析或者过滤的时候，一般会将数据进行聚合处理来分类甄别需要关注的对象。由于物联网设备很多情况下都是持续性的上报数据，直接进行全量聚合的话，会面临海量设备和海量采样点的计算，并且如果查询的频率较高，对应的计算代价和响应时间都会变得无法接受。但是这种查询有一个特点，每次计算在同样时间段内的数据都会重复演算多次，会有大量的算力浪费情况存在，所以理论上这种情况是存在优化方法的。以时间维度的统计为例，我们可以采用 `量级下降` 的方法，针对日常时间轴进行块级切分，如日、周、月、年为单位进行预聚合统计，这样就不用每次都全量扫描所有的原始数据点，而大幅度减少重复过滤查询下的系统性能消耗。 200 | 201 | ### 应用服务的设备抽象 202 | 203 | 虽然说我们的数据定义标准来自于我们对物联网设备的高层数据模型抽象，但是这并不等同于这套标准只能应用于物联网设备的模型定义。我们回归到这个数据定义的形式来看的话，可以发现任何可以使用五元组（ID、固有属性、可配属性、只读属性、功能函数）来进行完备描述（可以是五元组的一个子集）的应用，都可以套用这套描述模型。而应用模型所带来的最大优势，就是可以使用一个清晰的树状结构和说明来给应用提供一个解耦与架构化部署的理论与工具链支撑，尤其是在优化与重构系统的时候，可以快速理清系统的基础逻辑关系并提供可预期的性能提升参考，并且在提供最小粒度原子化操作的同时还可以很好的支持到读写分离、中台化等理念的实际落地。 -------------------------------------------------------------------------------- /docs/articles/iiot4.0_guide.md: -------------------------------------------------------------------------------- 1 | # 杂谈：一文了解工业4.0 2 | 3 | 工业4.0是中国乃至全世界对下一代工业的规划和期许。我们知道每次工业革命都伴随着行业的兴衰更替。所以工业4.0的内容对于每一个和工业有关的行业都息息相关。今天我们简单来看一下工业4.0的内容，来看一下对我们个人未来的职业规划有什么帮助意义。 4 | # 历史 5 | 工业发展历史经历了如下的阶段： 6 | 7 | - **工业1.0**：机械制造时代，即通过水力和蒸汽机实现工厂机械化，时间大概是18世纪60年代至19世纪中期。 8 | - **工业2.0**：电气化与自动化时代，即在劳动分工基础上采用电力驱动产品的大规模生产，时间大概是19世纪后半期至20世纪初。 9 | - **工业3.0**：电子信息化时代，即广泛应用电子与信息技术，使制造过程自动化控制程度进一步大幅度提高。从20世纪70年代开始并一直延续至现在。 10 | 11 | 12 | 13 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603263349998-e0d6aff8-a063-4431-aa4f-1bbbf556de8b.png#align=left&display=inline&height=616&margin=%5Bobject%20Object%5D&name=image.png&originHeight=616&originWidth=1165&size=147757&status=done&style=none&width=1165) 14 | 15 | 16 | 到如今各国开始提出工业4.0的规划，特别是一些工业制作强国，比如中美德日。工业4.0是**实体物理世界与虚拟网络世界融合的时代**，产品全生命周期、**全制造流程数字化**以及基于信息通信技术的模块集成，将形成一种高度灵活、个性化、数字化的产品与服务新生产模式。 17 | 18 | 19 | > “工业 4.0 将嵌入式系统生产技术与智能生产过程连接 起来，从而开启了一个全新的技术时代，并将给行业、 生产价值链以及商业模式带来重大转变。” 20 | > ——德国联邦外贸与投资署 21 | 22 | 23 | 24 | 各国对工业4.0的规划虽然不尽一样，但是基本上都离不开以下两点： 25 | 26 | - **互联**：这个互联包含两个方面，一方面是万物互联，互联的不仅包括生产的产品，还包括生产的流程，设备，公司，甚至于不同国家。也就是符合工业4.0的产品，企业和国家都应该能够相互联合，达到更大规模的生成效应。另一方面是现实世界和虚拟世界的相连，在工业4.0中，最大的特点就是现实世界在数据世界的虚拟化，也就是实体的数据化。得益于计算力和网络等基础设施的发展，一个工厂甚至于一个城市都可以进行虚拟化。而工业4.0就要达到现实世界和虚拟世界的相连，现实世界不断喂数据给虚拟世界，虚拟世界也会进行各种分析来反馈现实世界的进展。 27 | - **数字化**：工业4.0是在工业3.0上的基础上进行发展的，也就是电子信息技术。在互联网的基础上进一步发展成物联网，在工业4.0的设计中，无论是产品还是流程都应当全部数字化，这样可以降低工业生产的成本并且提高效率。 28 | # 架构 29 | ## 中国 30 | 2019年8月27日，在2019智博会期间举办的工业互联网高峰论坛上，工业互联网产业联盟发布《工业互联网体系架构2.0》。 31 | 32 | 工业互联网体系架构中分为四个部分：业务，功能，技术和实施。 33 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603183380708-7783b287-9e3b-4dcb-9320-7064034aa664.png#align=left&display=inline&height=485&margin=%5Bobject%20Object%5D&name=image.png&originHeight=485&originWidth=704&size=137801&status=done&style=none&width=704) 34 | 业务方面，除了原有的能力层和应用层，商业层，工业4.0还包括一个产业层。也就是对于工业4.0的规划站在了更高的角度。最终是要实现产业的数字化，网络化和智能化。 35 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603183364968-e761cd31-8b73-4b16-9d3e-9ff8d3fc6ba9.png#align=left&display=inline&height=672&margin=%5Bobject%20Object%5D&name=image.png&originHeight=672&originWidth=885&size=489891&status=done&style=none&width=885) 36 | 而站在功能视图上来看，工业4.0的一大重点就是数据互通，也就是打通各个行业的数据，同时支持各种形式的网络互连。实施方面也涉及到了产业领域。 37 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603183468724-bd16e942-de2d-41aa-8ba0-d799fb56be57.png#align=left&display=inline&height=730&margin=%5Bobject%20Object%5D&name=image.png&originHeight=730&originWidth=859&size=424619&status=done&style=none&width=859) 38 | 实施方面，从设备到产业，可以说整个工业4.0成功将某个产业纳入到统一的平台中，这样打破了信息孤岛，能够产生更大规模的产业效应。 39 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603183519867-1c84a053-781d-459e-8f7a-577f653c22ff.png#align=left&display=inline&height=469&margin=%5Bobject%20Object%5D&name=image.png&originHeight=469&originWidth=907&size=382505&status=done&style=none&width=907) 40 | 技术方面，工业4.0设计到原本的制造技术，同时加入了互联网相关的信息技术。同时基于当前新产生的融合技术。在设计方面除了兼顾原有技术外，对新技术也留有了一定的空间。 41 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603183557921-6980d8b6-b7e3-495d-961d-f2c4a12813eb.png#align=left&display=inline&height=562&margin=%5Bobject%20Object%5D&name=image.png&originHeight=562&originWidth=893&size=289082&status=done&style=none&width=893) 42 | ## 美国 43 | IIRA（Industrial Internet Reference Architecture）由美国工业互联网联盟（Industrial Internet Consortium , IIC）发布，最新版本为v1.9版，2019年6月19日发布。 44 | 45 | 46 | IIRA注重跨行业的通用性和互操作性，提供一套方法论和模型，以业务价值推动系统的设计，把数据分析作为核心，驱动工业联网系统从设备到业务信息系统的端到端的全面优化 47 | 48 | 49 | ![](https://cdn.nlark.com/yuque/0/2020/jpeg/783466/1603183639256-87a9ea7b-16ca-4232-bc11-90a2290fdf77.jpeg#align=left&display=inline&height=558&margin=%5Bobject%20Object%5D&originHeight=558&originWidth=724&size=0&status=done&style=none&width=724) 50 | 51 | 52 | 美国工业互联网联盟发布的工业互联网参考架构 53 | [![](https://cdn.nlark.com/yuque/0/2020/jpeg/783466/1603183648606-ff5fe29f-3585-443c-b41c-7cc93d9fc185.jpeg#align=left&display=inline&height=570&margin=%5Bobject%20Object%5D&originHeight=570&originWidth=580&size=0&status=done&style=none&width=580)](http://images.blogchina.com/artpic_upload_v5/5dee37c04a65c.jpg!m1024) 54 | ## 德国 55 | RAMI4.0（Reference Architecture Model Industrie 4.0）即工业4.0参考架构模型，深度聚焦于制造过程和价值链的生命周期，为其建立了一个比较完整的三维模型。 56 | 57 | 58 | 这个模型在对在制造环境里不同环节单元的功能的分析、它们之间的互操作性的需求的辨认，以及对相应的标准制定和采用，都十分有价值。 59 | 60 | 61 | 更值得关注的是与其相关的工业4.0部件模型，对包括数字化的零部件、设备、产线、车间、工厂、甚至信息化系统在内的所有资产提供一个统一的CPS模型，描述其功能、性能和状态，并为它们之间的交互，从通讯协议、句法和语义，提供统一的界面。其广泛实施，对推动制造环境各个系统的全面互联互通，将会起着非常大的作用。 62 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603183738723-4a541290-30c5-4522-93af-f70158fb0941.png#align=left&display=inline&height=350&margin=%5Bobject%20Object%5D&name=image.png&originHeight=350&originWidth=633&size=269771&status=done&style=none&width=633) 63 | ## 日本 64 | 日本工业价值链促进会（Industrial Value Chain Initiative，IVI）是一个由制造业企业、设备厂商、系统集成企业等发起的组织，旨在推动“智能工厂”的实现。2016年12月8日，IVI基于日本制造业的现有基础，推出了智能工厂的基本架构《工业价值链参考架构（Industrial Value Chain Reference Architecture ，IVRA）》。 65 | 66 | 67 | 从制造业一直追求的质量、成本和效率（产出）传统要素加上环保要求的管理角度出发，结合生产环境的资产（人、流程、产品和工厂）角度和作业流程（计划、执行、查验和反应）角度，细分出智能制造单元，对信息化在生产过程的优化，作了细致的分析，进而提出了智能制造的总体功能模块架构，在不同的（设备、车间、部门和企业）层次上，分析知识/工程流程（相当于产品链）和供给流程（相当于价值链）的各个环节的具体功能构成，颇具有独到之处。 68 | 69 | 70 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603183778979-f0e73b39-2db1-4daa-a4b0-f3ab7a0c3a03.png#align=left&display=inline&height=358&margin=%5Bobject%20Object%5D&name=image.png&originHeight=358&originWidth=550&size=197773&status=done&style=none&width=550) 71 | 72 | 73 | **目前德国RAMI 4.0和美国IIFA已经开始了对接工作，来消除彼此架构上面的不兼容现象。而我国也和德国开始了互相认证的合作。在工业4.0的大背景下，各国都将进一步促进万物互联的情景。** 74 | # 数字孪生 75 | 数字孪生是工业4.0新提出的概念，也是工业4.0非常重要的内容。我们先来看一下网上的定义： 76 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603184236581-64ea979c-080e-4bb4-ab0c-98be664b6b3c.png#align=left&display=inline&height=116&margin=%5Bobject%20Object%5D&name=image.png&originHeight=116&originWidth=1073&size=15458&status=done&style=none&width=1073) 77 | 数字孪生是现实实体的数据化表现，包括实体的信息，流程以及相关的系统。对于数字孪生来说有两个重要概念，第一个就是模型，也就是一类实体的抽象。第二个就是基于模型生成的实例，对应着每一个实体。在数字孪生中，每一个实体都应该有其唯一对应的数字实例。 78 | 79 | 80 | 数字孪生不仅仅是现实物体的数字模拟，而是一个更大的范围，包括对物体的操作，状态，相关的流程和系统，都有其模拟的对应。 81 | 82 | 83 | ![](https://cdn.nlark.com/yuque/0/2020/png/783466/1603245275589-cef44754-cdf5-4181-ae74-53e998871d5d.png#align=left&display=inline&height=1938&margin=%5Bobject%20Object%5D&originHeight=1938&originWidth=3840&size=0&status=done&style=none&width=3840) 84 | 85 | 86 | 数字孪生是物联网里面的概念，它指通过集成物理反馈数据，并辅以人工智能、机器学习和软件分析，在信息化平台内建立一个数字化模拟。这个模拟会根据反馈，随着物理实体的变化而自动做出相应的变化。理想状态下，数字映射可以根据多重的反馈源数据进行自我学习，从而几乎实时地在数字世界里呈现物理实体的真实状况。数字映射的反馈源主要依赖于各种传感器，如压力、角度、速度传感器等。数字映射的自我学习（或称机器学习）除了可以依赖于传感器的反馈信息，也可以是通过历史数据，或者是集成网络的数据学习。后者常指多个同批次的物理实体同时进行不同的操作，并将数据反馈到同一个信息化平台，数字映射根据海量的信息反馈，进行迅速的深度学习和精确模拟。 87 | 88 | 89 | 一个好的数字孪生软件设计要从实体开始一步步抽象模拟，到最终的孪生对象，我们参照XMPRO将孪生对象分为三种：状态，操作和具体模拟。从实体（Entity）抽象出具体的数据描述，然后通过抽象和分析，生成最终的孪生对象。 90 | 91 | 92 | ![](https://cdn.nlark.com/yuque/0/2020/png/783466/1603260913730-edab343f-7b06-4886-b9db-db20f6f0b14e.png#align=left&display=inline&height=1070&margin=%5Bobject%20Object%5D&originHeight=1070&originWidth=1412&size=0&status=done&style=none&width=1412) 93 | # 对行业的影响 94 | 工业4.0如果按照规划进行，对于行业或者说是个人来说有什么影响呢？我们可以按照规划来看。 95 | ![image.png](https://cdn.nlark.com/yuque/0/2020/png/783466/1603263668578-2831a8b2-16d1-442a-9022-25bfaf2a52e8.png#align=left&display=inline&height=766&margin=%5Bobject%20Object%5D&name=image.png&originHeight=766&originWidth=824&size=283288&status=done&style=none&width=824) 96 | ## 初期 97 | 在变革的初期，需要大量能够实现架构关键技术的人才，也就是上图中国工业互联网技术体系中的技术，其中有些是已经成熟的技术，有些却是新的技术， 比如数字孪生，工业AI，工业区块链等。以及对于标准和架构理解深的人。 98 | ## 成熟期 99 | 当架构总体实现了之后，那么工业4.0就需要关注其中可以迭代的部分，或者说是需要不断新建的技术，比如数字孪生模型，工业AI模型等。同时，基于工业4.0产生的大量数据而生产的分析，展示的技术都会在这一时刻得到应用。 100 | ## 后期 101 | 工业4.0如果已经完全成熟，那么各个企业或者国家间的互联，兼容的计划都会被提上来，那么对于标准理解深的人或者架构的人又重新纳入到需求中。 102 | # 参考阅读 103 | 104 | - 一文解读工业互联网 (转)： 105 | 106 | [https://www.cnblogs.com/IT-Evan/p/12142286.html](https://www.cnblogs.com/IT-Evan/p/12142286.html) 107 | 108 | - Digital Twins: The Ultimate Guide： 109 | 110 | [https://xmpro.com/digital-twins-the-ultimate-guide/](https://xmpro.com/digital-twins-the-ultimate-guide/) 111 | -------------------------------------------------------------------------------- /docs/basic/field_bus.md: -------------------------------------------------------------------------------- 1 | # 现场总线 2 | 3 | 现场总线（Field bus）是近年来迅速发展起来的一种工业数据总线，它主要解决工业现场的智能化仪器仪表、控制器、执行机构等现场设备间的数字通信以及这些现场控制设备和高级控制系统之间的信息传递问题。 4 | 5 | ## 定义 6 | 7 | 国际电工委员会IEC标准和现场总线基全会FF将现场总线定义为：现场总线是连接智能现场设备和自动化系统的数字式、双向传输、多分支结构的通信网络。换句通俗地话，**现场总线就是将分散的有通信能力的测量控制设备作为网络节点，连接成能相互沟通信息，共同完成自控任务的控制网络**。 8 | 9 | ## 现场总线 vs 传统现场 10 | 11 | 它是一种工业数据总线，是自动化领域中底层数据通信网络。简单说，现场总线就是以数字通信替代了传统 4-20mA 模拟信号及普通开关量信号的传输，是连接智能现场设备和自动化系统的全数字、双向、多站的通信系统。 12 | 13 | 现场总线，往往是安装在楼宇或者更远距离的需求，连接各个设备之间，获取数据或者控制执行器的总线，例如传感器网络的连接。需要获取各个安装在现场的分散式传感器的数值的需求。这类总线类似 RS485,CAN,POWERBUS 等。现场总线更多的是考虑的长距离传输的时候信号稳定性，抗干扰性。它还具有接线简单，工程周期短，安装费用低，维护容易，可靠性高，稳定性好，抗干扰能力强，通信速率快，系统安全，符合环境保护要求等优点。 14 | 15 | ![](../../resources/imgs/field_bus_demo.png) 16 | 17 | * 传统的现场级自动化监控系统采用一对一连线的 4-20mA/24VDC 信号，信息量有限，难以实现设备之间及系统与外界之间的信息交换，使自控系统成为工厂中的 "信息孤岛"，严重制约了企业信息集成及企业综合自动化的实现。 18 | 19 | * 基于现场总线的自动化监控系统采用计算机数字化通信技术，使自控系统与设备加入工厂信息网络，构成企业信息网络底层，使企业信息沟通的覆盖范围一直延伸到生产现场。例如，利用现场总线技术可使用一条通信电缆将现场设备（智能化、带有通信接口）连接，用数字化通信代替 4-20mA/24VDC 信号，完成现场设备控制、监测、远程参数化等功能。 20 | 21 | ## 特点 22 | 23 | * **系统的开放性** 24 | 25 | 传统的控制系统是个自我封闭的系统，一般只能通过工作站的串口或并口对外通信。在现场总线技术中，用户可按自己的需要和对象，将来自不同供应商的产品组成大小随意的系统。 26 | 27 | * **可操作性与可靠性** 28 | 29 | 现场总线在选用相同的通信协议情况下，只要选择合适的总线网卡、插口与适配器即可实现互连设备间、系统间的信息传输与沟通，大大减少接线与查线的工作量，有效提高控制的可靠性。 30 | 31 | * **现场设备的智能化与功能自治性** 32 | 33 | 传统数控机床的信号传递是模拟信号的单向传递，信号在传递过程中产生的误差较大，系统难以迅速判断故障而带故障运行。而现场总线中采用双向数字通信，将传感测量、补偿计算、工程量处理与控制等功能分散到现场设备中完成，可随时诊断设备的运行状态。 34 | 35 | * **对现场环境的适应性** 36 | 37 | 现场总线是作为适应现场环境工作而设计的，可支持双绞线、同轴电缆、光缆、射频、红外线及电力线等，其具有较强的抗干扰能力，能采用两线制实现送电与通信，并可满足安全及防爆要求等。 38 | 39 | ## 发展历程 40 | 41 | ![](../../resources/imgs/field_bus_development.png) 42 | 43 | 随着信息与科学技术的迅猛发展，信息交换方式日新月异，并朝着全球化与数字化的方向发展，自动控制系统作为信息与科学技术发展的融合产物，自 19 世纪以来的近两百年里也发生了巨大变革。总的来说，一般可将其划分为 5 代： 44 | 45 | * 第一代：气动信号控制系统（PCS） 46 | 47 | * 第二代：电动模拟仪表过程控制系统（ACS） 48 | 49 | * 第三代：集中式数字控制系统（CCS） 50 | 51 | * 第四代：分散式控制系统（DCS） 52 | 53 | * 第五代：现场总线控制系统（FCS） 54 | 55 | ## 主流现场总线比较 56 | 57 | ![](../../resources/imgs/field_bus_10.png) 58 | 59 | ## 参考 60 | 61 | * [现场总线——让工业物联网通讯更快捷](https://www.iiot.com/news/266.html) -------------------------------------------------------------------------------- /docs/big-data/reference.md: -------------------------------------------------------------------------------- 1 | # 工业大数据 2 | 3 | - [工业大数据](#工业大数据) 4 | - [分类](#分类) 5 | - [平台](#平台) 6 | - [阿里云物联网平台](#阿里云物联网平台) 7 | - [架构](#架构) 8 | - [AWS IIoT服务](#aws-iiot服务) 9 | - [Micorsoft Azure IIOT Analytics](#micorsoft-azure-iiot-analytics) 10 | - [架构](#架构-1) 11 | - [数据流](#数据流) 12 | - [华为 IoT数据分析](#华为-iot数据分析) 13 | - [GE Predix平台](#ge-predix平台) 14 | - [资产服务](#资产服务) 15 | 16 | 工业大数据主要是采集工业领域中从需求到销售、订单、计划、研发、设计、工艺、制造、采购、供应、库存、发货到最终交付、售后、服务、运维、报废等全生命周期所产生的各类数据。建立工业打算数据平台的最终目的就是为了提高工业生产过程价值的提升或者变现。并为企业管理资产上提供数据支撑。 17 | 18 | ## 分类 19 | 20 | 工业大数据可以从数据来源上分成三大类：业务数据，制作过程数据，外部数据。 21 | 22 | * **业务数据**：企业在管理过程中产生的业务数据，包括企业资源计划(ERP)、产品生命周期管理(PLM)、供应链管理(SCM)、客户关系管理(CRM)和能耗管理系统（EMS)等。这类系统是工业企业传统意义上的数据资产，这类数据的特点是数据格式多样，系统复杂，专业性较强。 23 | * **制作过程数据**：工业生产中，产生的各种生产数据，主要通过MES形同实时传递。这类数据是目前增长最快的数据。 24 | * **外部数据**：包括产品售出后的使用，运营情况的数据，还有其他比如客户名单，供应商名单，外部互联网数据等。 25 | 26 | ## 平台 27 | 28 | ### 阿里云物联网平台 29 | 30 | > [https://help.aliyun.com/document_detail/30522.html](https://help.aliyun.com/document_detail/30522.html) 31 | 32 | ![](../../resources/imgs/aliyun_iot_platform.png) 33 | 34 | #### 架构 35 | 36 | ![](../../resources/imgs/aliyun_iot_platform_architecture.jpg) 37 | 38 | ### AWS IIoT服务 39 | 40 | > [https://aws.amazon.com/cn/iot/solutions/industrial-iot/?nc=sn&loc=3&dn=2](https://aws.amazon.com/cn/iot/solutions/industrial-iot/?nc=sn&loc=3&dn=2) 41 | 42 | ![](../../resources/imgs/aws_iot_platform.png) 43 | 44 | ### Micorsoft Azure IIOT Analytics 45 | 46 | > [https://docs.microsoft.com/en-us/azure/architecture/guide/iiot-guidance/iiot-architecture](https://docs.microsoft.com/en-us/azure/architecture/guide/iiot-guidance/iiot-architecture) 47 | 48 | #### 架构 49 | 50 | ![](../../resources/imgs/azure_iiot_platform_architecture.png) 51 | 52 | #### 数据流 53 | 54 | ![](../../resources/imgs/iot-azure-data-explorer.png) 55 | 56 | ### 华为 IoT数据分析 57 | 58 | > [](https://www.huaweicloud.com/product/iotanalytics-platform.html) 59 | 60 | ![](../../resources/imgs/huawei_iot_analyze.png) 61 | 62 | ### GE Predix平台 63 | 64 | > [https://www.predix.io/](https://www.predix.io/) 65 | 66 | ![](../../resources/imgs/ge_predix_iiot_platform.png) 67 | 68 | #### 资产服务 69 | 70 | ![](../../resources/imgs/ge_predix_asset_service.png) 71 | 72 | -------------------------------------------------------------------------------- /docs/edge-computing/README.md: -------------------------------------------------------------------------------- 1 | # 边缘计算 2 | 3 | ## 什么是边缘计算 4 | 5 | 边缘计算由利用传统和云数据中心之外可用计算资源的技术组成，可使工作负载的所在位置更接近数据的创建位置，并且可以根据数据分析结果及时地采取操作。通过利用和管理可在远程场所（例如工厂、零售店、仓库、酒店、配送中心或车辆）使用的计算能力，开发者可以创建相应的应用程序来实现以下目标： 6 | 7 | * 显著减少延迟 8 | * 降低对网络带宽的需求 9 | * 增加敏感信息的隐私性 10 | * 即使网络中断也可正常运作 11 | 12 | 在将应用程序工作负载移到边缘时，可能需要多个边缘节点，如图所示。 13 | 14 | ![](../../resources/imgs/edge_computing_deploy_architecture.png) 15 | 16 | 以下是构成边缘生态系统的一些关键组件： 17 | 18 | **云** 19 | 20 | 这可以是公共云或私有云，可以是基于容器的工作负载（如应用程序和机器学习模型）的存储库。这些云还托管并运行用于编排和管理不同边缘节点的应用程序。边缘工作负载（本地和设备工作负载）将与这些云上的工作负载进行交互。云还可以是其他节点所需的任何数据的源和目标。 21 | 22 | **边缘设备** 23 | 24 | 边缘设备是一种专用的装置部件，它同时也具有集成到该设备中的计算能力。在边缘设备上可以执行很多有趣的工作，例如，工厂车间的装配机械、ATM、智能相机或汽车等设备。边缘设备通常受到经济因素的驱动，计算资源一般都比较有限。具有 ARM 或 x86 类 CPU（单核或双核）、128 MB 内存以及 1 GB 本地持久存储器的边缘设备比较常见。尽管边缘设备功能更强大，但目前它们还没有成为规范，而只是作为特例现象存在。 25 | 26 | **边缘节点** 27 | 28 | 边缘节点是指可以在其上执行边缘计算的任何边缘设备、边缘服务器或边缘网关的通用方式。 29 | 30 | **边缘集群/服务器** 31 | 32 | 边缘集群/服务器是位于远程运营设施（例如工厂、零售店、酒店、配送中心或银行）中的通用 IT 计算机。边缘集群/服务器通常由工业 PC 或机架式计算机构成。具有 8 核、16 核或更多核计算能力、16GB 内存和数百 GB 本地存储器的边缘服务器比较常见。边缘集群/服务器通常用于运行企业应用程序工作负载和共享服务。 33 | 34 | **边缘网关** 35 | 36 | 边缘网关通常是边缘集群/服务器，除了能够托管企业应用程序工作负载和共享服务外，还具有可执行网络功能的服务，例如协议转换、网络终止、隧道技术、防火墙保护或无线连接。尽管某些边缘设备可以充当有限的网关或主机网络功能，但是边缘网关通常会与边缘设备分开。 37 | 38 | IoT 传感器是固定功能的设备，可收集数据并将其传输到边缘/云，但没有板载计算、内存和存储。因此，无法在其上部署容器。这些边缘设备会连接到不同的节点，但由于它们是固定功能的设备，因此未在图中反映出来。 39 | 40 | ## 核心优势 41 | 42 | 边缘计算技术具有以下核心优势： 43 | 44 | * **性能**： 在边缘进行近乎即时的计算和分析可降低延迟，从而大大提高性能。随着 5G 的到来，与边缘快速通信成为可能，在边缘运行的应用程序也可以快速响应消费者不断增长的需求。 45 | 46 | * **可用性**： 关键系统需要持续运行，而不考虑连接性。当前的通信流程存在许多潜在的故障点。这些故障点包括公司的核心网络、跨多个网络节点的多个跃点及网络路径的安全风险，以及许多其他故障点。对于边缘计算，由于主要在消费者/请求者与设备/本地边缘节点之间进行通信，因而提高了系统的可用性。 47 | 48 | * **数据安全**： 在边缘计算架构中，分析数据可能永远不会离开在本地边缘内收集和使用该数据的物理区域。 仅边缘节点需要从根本上予以保护，这更便于管理和监视，也意味着数据更加安全。 49 | 50 | ## 挑战 51 | 52 | ### 大规模挑战 53 | 54 | 如果在您纳入边缘计算时工作负载位置发生变化，并且以更加分散的方式部署应用程序和分析功能，为了进行扩展，就需要使用编排和自动化工具，这样才能在架构上以一致的方式管理此更改。 55 | 56 | 例如，如果将应用程序从一个具有永续支持的数据中心转移到本地边缘的 100 多个不易访问的位置，或者不在具有这种本地技术支持的位置中，那么管理生命周期和支持应用程序的方式就必须更改。 57 | 58 | 为了应对这一挑战，就需要使用新工具并对技术支持团队进行培训，以便管理、编排和自动运行这个新的复杂环境。传统网络运营工具对团队来说已经力有不逮（甚至超出软件定义网络运营工具范畴），支持团队将需要别的工具来帮助管理各种分布式环境中网络背景下的应用程序工作负载（远远多于先前），而每个工具都有不同的优势和功能。 59 | 60 | ### 使工作负载可移植 61 | 62 | 为了实现大规模运行，就需要对考虑用于边缘计算本地化的工作负载加以修改，从而提高其可移植性。 63 | 64 | * 首先，大小很重要。若要减少延迟，就需要将工作负载移至更靠近边缘的位置，而将其移至边缘组件也意味着运行该工作负载的计算资源会减少，因此各种工作负载的总体大小可能会限制边缘计算的潜力。 65 | 66 | * 其次，由于要考虑许多不同的工作负载，因此很难采用可移植性标准或标准集。 此外，该标准还应允许管理应用程序从构建、运行一直到维护整个生命周期。 67 | 68 | * 第三，需要完成相关工作，确定如何以最适宜的方式将工作负载细分为子组件，从而利用边缘计算的分布式架构。这将允许工作负载的某些部分在边缘设备上运行，而其他部分则在边缘集群/服务器或跨边缘组件的任何其他分布式系统上运行。这通常包括在适用且可行的情况下，迁移至网络功能虚拟化（针对网络工作负载）和容器工作负载（针对应用程序工作负载以及将来的网络工作负载）的组合方式。根据当前的应用程序环境，这一迁移过程可以需要耗费很大的精力。 69 | 70 | 为了以合理的方式应对这一挑战，可以基于许多因素划分工作负载的优先次序，这些因素包括迁移优势、复杂性以及迁移所需的资源/时间。许多网络和应用程序合作伙伴都已经在致力于将功能迁移到基于容器，这有助于应对这一挑战。 71 | 72 | ### 安全性 73 | 74 | 尽管数据安全性的优势在于可以将数据限制在特定应用程序的某些物理位置，但是在采用边缘计算时，整体安全性则是另一项挑战。边缘物理设备由于功能有限，可能无法利用现有的安全标准或解决方案。 75 | 76 | 因此，为了应对这些安全挑战，本地边缘上游基础架构可能还需要解决其他安全问题。此外，由于具有多个设备边缘，安全问题现在已分散开来，处理起来更加复杂。 77 | 78 | ### 新兴技术和标准 79 | 80 | 随着这一生态系统中新标准的不断制定或众多标准的迅速演变，企业很难长期坚持某些技术决策。特定边缘设备或技术的决策可能会被下一个竞争设备所取代，从而使其成为一个具有挑战性的运行环境。而有了适当的工具来管理这些不同的工作负载及其整个应用程序生命周期，就可以随着技术和标准的演变，更轻松地引入新设备/功能或替换现有设备。 81 | 82 | ## 整体架构 83 | 84 | 边缘计算由三个主要节点组成： 85 | 86 | * 设备边缘，即边缘设备所在的位置 87 | * 本地边缘，包括支持应用程序的基础架构和网络工作负载 88 | * 云或您环境的纽带，在此根据需要整合所有内容 89 | 90 | ![](../../resources/imgs/edge_computing_design_architecture.png) 91 | 92 | **设备边缘** 93 | 94 | 在边缘本地运行的实际设备，例如摄像头、传感器及其他收集数据或与边缘数据交互的物理设备。 简单的边缘设备用于收集和/或传输数据。更复杂的边缘设备则具有处理能力，可执行其他活动。无论哪种情况，重要的是能够在这些边缘设备上部署和管理应用程序。此类应用程序的示例包括专门的视频分析、深度学习 AI 模型和简单的实时处理应用程序。IBM 的方法（在其 IBM 边缘计算解决方案中）是在这些边缘设备上部署和管理容器化的应用程序。 95 | 96 | **本地边缘** 97 | 98 | 在本地或网络边缘运行的系统。边缘网络层和边缘集群/服务器可以是存在于各种物理位置的单独的物理或虚拟服务器，也可以将它们组合到超融合系统中。该架构层有两个主要的子层。在这些架构层中管理这些应用程序所需的系统组件以及设备边缘上的应用程序都将保存在此处。 99 | 100 | 应用程序层：由于占用空间对于设备而言太大而无法在设备边缘运行的应用程序将在此处运行。示例应用程序包括复杂的视频分析和物联网处理。 101 | 102 | 网络层：由于物理网络设备的管理很复杂，因此通常不会部署物理网络设备。整个网络层大多是虚拟化或容器化的。示例包括路由器、交换机或运行本地边缘所需的任何其他网络组件。 103 | 104 | **云** 105 | 106 | 这个架构层一般被称为云，但它可以在本地运行，也可以在公共云中运行。该架构层是工作负载的来源，这些工作负载是需要处理其他边缘节点和管理层所无法完成操作的应用程序。工作负载包括将通过使用适当的编排层部署到不同边缘节点的应用程序和网络工作负载。 107 | 108 | ![](../../resources/imgs/edge_computing_design_architecture_detail.png) 109 | 110 | 111 | 112 | ## 参考 113 | 114 | * [边缘计算架构和用例](https://developer.ibm.com/zh/depmodels/edge-computing/articles/edge-computing-architecture-and-use-cases/) -------------------------------------------------------------------------------- /docs/platforms/aliyun_iot_platform/device_process.md: -------------------------------------------------------------------------------- 1 | # 设备流程 2 | 3 | 阿里云物联网平台中的设备数据交换采用的是Alink协议。 4 | 5 | ## 设备上线 6 | 7 | ![](images/device_register.jpg) 8 | 9 | ### 直连设备 10 | 11 | 直连设备可以通过提前烧录设备证书或者产品证书来进行设备注册，上线和数据上报。 12 | 13 | ### 子设备 14 | 15 | 子设备注册时通过网关发起，可以通过下面两种方式： 16 | 17 | * 子设备直接烧录设备证书，将设备证书发给网关，网关首先添加拓扑关系，将设备上线，然后上传数据 18 | * 子设备将ProductKey和DeviceName通过网关传给平台，由平台进行验证，然后下发设备证书。子设备得到后将设备证书上传给网关，网关添加拓扑关系，将设备上线，然后上传数据。 19 | 20 | 总体流程就是： 21 | 22 | ``` 23 | 【子设备】 --设备证书--> 【网关】 --添加拓扑关系，并开始上传数据，将设备上线 --> 【平台】 24 | ``` 25 | 26 | 子设备上线的基本要求是：**设备身份**和与网关的**拓扑关系**。 27 | 28 | ![](images/device_process.png) -------------------------------------------------------------------------------- /docs/platforms/aliyun_iot_platform/images/device_process.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/docs/platforms/aliyun_iot_platform/images/device_process.png -------------------------------------------------------------------------------- /docs/platforms/aliyun_iot_platform/images/device_register.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/docs/platforms/aliyun_iot_platform/images/device_register.jpg -------------------------------------------------------------------------------- /docs/protocols/hart.md: -------------------------------------------------------------------------------- 1 | # 什么是HART协议 2 | 3 | HART(Highway Addressable Remote Transducer)，可寻址远程传感器高速通道的开放通信协议，是美国ROSEMOUNT公司于1985年推出的一种用于现场智能仪表和控制室设备之间的通信协议。 4 | 5 | 70年代中期，工业过程控制仪表发展成为统一的两线制4～20mA 标准信号，促进了工业过程控制系统的发展。但是从80年代开始，随着微电子学的发展，大量含有微处理器的智能变送器、控制器和集散系统（DCS）得到了普遍应用。现场设备与控制室自动化设备间需要传输的信息量也急剧增加。 6 | 7 | 由于原有的4～20mA模拟电流回路，只能在一根两芯电缆中单向传输一个参数，已经不能适应这种要求,所以在现场设备和控制系统之间，迫切需要一种全数字化的、双向、多变量的通信规程，来代替现有的4～20mA模拟传输方式，HART协议是一种由模拟系统向数字系统转变过程中的过渡协议,即它可以在提供现场总线的优越性的同时，保留对现有4～20mA 系统的兼容性。 8 | 9 | HART协议采用基于Bell202标准的FSK频移键控信号，在低频的4～20mA模拟信号上叠加幅度为0.5mA的音频数字信号进行双向数字通讯，数据传输率为1.2kbps。由于FSK信号的平均值为0，不影响传送给控制系统模拟信号的大小，保证了与现有模拟系统的兼容性。在HART协议通信中主要的变量和控制信息由4～20mA传送，在需要的情况下，另外的测量、过程参数、设备组态、校准、诊断信息通过HART协议访问。 10 | 11 | HART通信采用的是半双工的通信方式，其特点是在现有模拟信号传输线上实现数字信号通信，属于模拟系统向数字系统转变过程中过渡性产品，因而在当前的过渡时期具有较强的市场竞争能力，得到了较快发展。HART规定了一系列命令，按命令方式工作。它有三类命令，第一类称为通用命令，这是所有设备都能理解和执行的命令；第二类称为一般行为命令，所提供的功能可以在许多现场设备（尽管不是全部）中实现，这类命令包括最常用的的现场设备的功能库；第三类称为特殊设备命令，以便于工作在某些设备中实现特殊功能，这类命令既可以在基金会中开放使用，又可以为开发此命令的公司所独有。在一个现场设备中通常可发现同时存在这三类命令。 12 | 13 | HART采用统一的设备描述语言DDL。现场设备开发商采用这种标准语言来描述设备特性，由HART基金会负责登记管理这些设备描述并把它们编为设备描述字典，主设备运用DDL技术来理解这些设备的特性参数而不必为这些设备开发专用接口。但由于这种模拟数字混合信号制，导致难以开发出一种能满足各公司要求的通信接口芯片。HART能利用总线供电，可满足本质安全防爆要求，并可组成由手持编程器与管理系统主机作为主设备的双主设备系统。 14 | 15 | HART装置提供具有相对低的带宽，适度响应时间的通信，经过10多年的发展，HART技术在国外已经十分成熟，并已成为全球智能仪表的工业标准。 16 | 17 | ## 参考 18 | 19 | * [什么是HART协议?](http://www.jiweimeter.com/yfshow-23-430-1.html) -------------------------------------------------------------------------------- /docs/protocols/modbus.md: -------------------------------------------------------------------------------- 1 | # Modbus协议 2 | 3 | ## 概览 4 | 5 | Modbus​是​一种​工业​协议，​于​1979​年​开发，​旨​在​实现​自动​化​设备​之间​的​通信。 Modbus​最初​是​作为​通过​串​行​层​传输​数据​的​应用​级​协议​实现​的，​现​已​扩展​到​包括​通过​串​行、​TCP/​IP​和​用户​数据​报​协议​（UDP）​的​实现。 6 | 7 | ## 什么是Modbus协议 8 | 9 | Modbus​是​使用​主从关系​实现​的​请求 - 响应​协议。 在​主从关系​中，​通信​总是​成​对​发生 - 一个​设备​必须​发起​请求，​然后​等待​响应 - 并且​发起​设备​（主​设备）​负责​发起​每次​交互。 通常，​主​设备​是​人​机​界面​（HMI）​或​监​控​和​数据​采集​（SCADA）​系统，​从​设备​是​传感器、​可​编​程​逻辑​控制器​（PLC）​或可​编​程​自动​化​控制器​（PAC）。 这些​请求​和​响应​的​内容​以及​发送​这些​消息​的​网络​层​由​协议​的​不同​层​来​定义。 10 | 11 | ![](../../resources/imgs/modbus_master_slave.jpg) 12 | 13 | ## 特点 14 | 15 | * 免费 16 | * 支持多种电气接口 17 | * 帧格式简单，通俗易懂好开发 18 | * 可靠性好，Modbus协议需要对数据进行校验，串行协议中除有奇偶校验外，ASCII模式采用LRC校验，RTU模式采用16位CRC校验，但TCP模式没有额外规定校验，因为TCP协议是一个面向连接的可靠协议（PS：也就是说modbusTCP实际上是Modbus利用TCP打包数据传输的一种方式）。另外，Modbus采用主从方式定时收发数据，在实际使用中如果某Slave站点断开后(如故障或关机)，Master端可以诊断出来，而当故障修复后，网络又可自动接通。 19 | 20 | ## 标准网络 21 | 22 | ModBus网络只有一个主机，所有通信都由他发出。网络可支持247个之多的远程从属控制器，但实际所支持的从机数要由所用通信设备决定。采用这个系统，各PC可以和中心主机交换信息而不影响各PC执行本身的控制任务。 23 | 24 | 当在一Modbus网络上通信时，每个控制器须要知道它们的设备地址，识别按地址发来的消息，决定要产生何种行动。如果需要回应，控制器将生成反馈信息并用Modbus协议发出。在其它网络上，包含了Modbus协议的消息转换为在此网络上使用的帧或包结构。这种转换也扩展了根据具体的网络解决节地址、路由路径及错误检测的方法。 25 | 26 | 主设备可单独和从设备通信，也能以广播方式和所有从设备通信。如果单独通信，从设备返回一消息作为回应，如果是以广播方式查询的，则不作任何回应。Modbus协议建立了主设备查询的格式：设备（或广播）地址、功能代码、所有要发送的数据、错误检测域。从设备回应消息也由Modbus协议构成，包括确认要行动的域、任何要返回的数据、和一错误检测域。如果在消息接收过程中发生一错误，或从设备不能执行其命令，从设备将建立一错误消息并把它作为回应发送出去。 27 | 28 | ## 其他网络 29 | 30 | 在其它网络上，控制器使用对等技术通信，故任何控制都能初始和其它控制器的通信。这样在单独的通信过程中，控制器既可作为主设备也可作为从设备。提供的多个内部通道可允许同时发生的传输进程。 31 | 32 | 在消息位，Modbus协议仍提供了主—从原则，尽管网络通信方法是“对等”。如果一控制器发送一消息，它只是作为主设备，并期望从从设备得到回应。同样，当控制器接收到一消息，它将建立一从设备回应格式并返回给发送的控制器。 33 | 34 | ## 数据模型 35 | 36 | 通常，​Modbus​可​访问​的​数据​存储​在​四​个​数据​库​或​地址​范围​的​其中​一个： 线圈​状态、​离散​量​输入、​保持​寄存器​和​输入​寄存器。 与​许多​规范​一样，​名称​可能​因​行业​或​应用​而​异。 例如，​保持​寄存器​也可以​称为​输出​寄存器，​线圈​状态​可能​称为​数字​或​离散​量​输出。 这些​数据​库​定义​了​所​包含​数据​的​类型​和​访问​权限。 从​设备​可以​直接​访问​这些​数据，​因为​这些​数据​由​设备​本地​托管。 Modbus​可​访问​的​数据​通常​是​设备​主​存​的​一个​子​集。 相反，​Modbus​主​设备​必须​通过​各种​功能​代码​请求​访问​这些​数据。 37 | 38 | |内存​区块|数据​类型|主​设备​访问|从​设备​访问| 39 | |:---|:---|:---|:---| 40 | |线圈​状态|布尔|读/写|读/写| 41 | |离散​输入|布尔|只读|读/写| 42 | |保持​寄存器|无​符号​双​字​节​整型|读/写|读/写| 43 | |输入​寄存器|无​符号​双​字​节​整型|只读|读/写| 44 | 45 | 46 | 47 | ## 参考 48 | 49 | * [Modbus​协议​深入​讲解](https://www.ni.com/zh-cn/innovations/white-papers/14/the-modbus-protocol-in-depth.html) 50 | * [Modbus协议详解](https://www.jianshu.com/p/f7fd49a51f23) -------------------------------------------------------------------------------- /docs/protocols/opc_ua_guide.md: -------------------------------------------------------------------------------- 1 | # OPC UA协议 2 | 3 | OPC UA是OPC Unified Architecture的简称，是OPC基金会基于原有OPC协议的基础上推出的新的标准。OPC UA协议从名称中就可以看出是为了应对跨平台的趋势，能够达到只使用一个地址空间就能访问所有的对象，不受平台系统的限制。 4 | 5 | 起初，OPC是在微软Windows的OLE技术基础上，使用COM/DCOM（分布式组件对象模型）在软件组件之间交换数据，OPC是OLE for Process Control的缩写（用于过程控制的OLE）。经典的OPC标准有OPC DA（数据采集）、OPC Alarms&Events（报警和事件）、OPC HDA（历史数据）。 6 | 7 | 而随着工业的发展，人们对OPC技术的需求更加越来越高，对数据交互，安全性等要求的前提下，2008年发布的OPC统一架构（UA）将各个经典OPC规范的所有功能集成到一个可扩展的框架中，独立于平台并且面向服务。 8 | 9 | > 官网：[https://opcfoundation.org/about/opc-technologies/opc-ua/](https://opcfoundation.org/about/opc-technologies/opc-ua/) 10 | 11 | ## 设计目标 12 | 13 | 1. 功能对等：集成了之前所有的OPC协议的特性和信息，比如A&E,DA,OPC XML DA和HDA 14 | 2. 平台无关：更加开放，平台无关性，Windows和Linux都能兼容 15 | 3. 安全性：在协议和应用层集成了安全功能，更加安全 16 | 4. 拓展性：拓展了对象类型，支持更复杂的数据类型比如变量，方法和事件 17 | 5. 良好的信息模型：支持定义复杂的模型 18 | 19 | ### 功能对等 20 | 21 | OPC UA支持原有的OPC协议的功能，并且进行了延伸和拓展。 22 | 23 | * Discovery：查询本地网络或电脑上的OPC Server 24 | * Address space：所有的数据都是按照层次结构表示（例如files和folders），从而OPC Clients可以使用简单或者复杂的数据。 25 | * On-demand：数据的读取和写入都需要访问权限 26 | * Subscriptions：根据Clients的规则来进行数据的监控和异常的报警 27 | * Events：根绝Clients的规则来通知重要的信息 28 | * Methods：Clients可以运行程序或者脚本 29 | 30 | ### 平台无关 31 | 32 | OPC UA支持各种硬件和软件平台： 33 | 34 | * 硬件：电脑，主机，服务器，PLC，ARM等 35 | * 操作系统：Windows，Apple OSX，Android，Linux等 36 | 37 | ### 安全性 38 | 39 | OPC UA在安全性方面做了很多工作： 40 | 41 | * 传输：提供了很多可选配置，比如超快速OPC二进制传输和基于Websocket的JSON 42 | * 会话加密：各种加密级别的消息传输 43 | * 信息签名：通过信息签名，接收者可以验证信息的来源和完整性 44 | * 顺序数据包：可以有效防止重播攻击 45 | * 权限认证：每个UA客户端和服务器都通过X509证书进行标识，从而可以控制允许哪些应用程序和系统相互连接 46 | * 允许用户控制：应用程序可以要求用户进行身份验证，可以限制或增强其权限或者地址空间访问 47 | * 审核：记录用户或系统的活动，来跟踪审核访问的记录 48 | 49 | ### 拓展性 50 | 51 | OPC UA在设计上采用了多层架构，保证了对未来协议和技术的兼容性，同时保持对已有设备的一致性兼容。 52 | 53 | ### 良好的信息模型 54 | 55 | ![](../../resources/imgs/opc_ua_information_model.jpg) 56 | 57 | OPC UA在信息模型上采用面向对象的设计，使得即使是最复杂的多层结构也能很好的建模和拓展。 58 | 59 | ![](../../resources/imgs/UA-Architecture.png) 60 | 61 | 从架构图中我们可以看到，OPC UA定义了拓展接口和基本的模型，其他人可以通过拓展这些来实现自己的模型。 62 | 63 | OPC UA同时也定义了信息模型的访问机制： 64 | 65 | * 浏览本地实例对象的机制 66 | * 对当前数据和历史数据的读写方式 67 | * 可执行的方法 68 | * 数据和实践的通知机制 69 | 70 | 同时提供了两种通信方式：Client-Server和Pub-Sub。其中Client-Server每条信息都是针对单个客户端，而Pub-Sub测试多对多的方式。 71 | 72 | ## 角色与意义 73 | 74 | OPC UA扮演的角色主要基于下面的问题，在IEC关于互联技术报告中提到互联、互通、语义互操作多个层面的问题（图4中的不兼容、共存不考虑，互换目前无法做到），而OPC UA主要解决在语义互操作的问题上。 75 | 76 | ![](../../resources/imgs/opc_ua_tsn_iec_problems.jpg) 77 | 78 | ## 使用原因 79 | 80 | 尽管OPC UA有非常多的使用原因，包括非盈利组织、IEC标准、安全性，但是，对于智能制造而言，多个设备之间的协同（M2M）以及业务管理系统与产线的协同（B2M）、业务单元间的数据（B2B）都需要OPC UA的协同。 81 | 82 | ![](../../resources/imgs/why_we_use_opc_ua.png) 83 | 84 | ## 常见问题 85 | 86 | 1. **OPC UA属于哪一层的协议？** 87 | 88 | 应用层 89 | 90 | 2. **和OPC UA并列的还有哪些工业物联网协议？** 91 | 92 | CANOpen,Profinet,Modbus 93 | 94 | ## 参考文章 95 | 96 | * [OPC-UA技术在SCADA上的应用](https://mp.weixin.qq.com/s?subscene=23&__biz=MzA4NTQ5MTIzNA==&mid=2649929755&idx=1&sn=e8b9e70fca32e0e337006eefba1f6b7c&chksm=87d13356b0a6ba406e3a4bcdcc7b7f8485e2ee38b4e28806fa4c293d027b80f979a8c79a3886&scene=7&key=416803f1530d0e77a7a32dbd19c84b5093cbc28d1ef7ca3d6d20f4826401c9377b6b3b4bcbb658f09b7501a82694761ae0d2b76d07959a9cfb1c5e439df22db5835d92165bcd87603e99f801790443fae94a9192cab922788529de4296f13d12cedc49b36573ea8d5904b48a61d7110a3142e6733d78f7b1a9a92c50e91b04e0&ascene=0&uin=NTkyMjg4NQ%3D%3D&devicetype=Windows+10+x64&version=6300002f&lang=zh_CN&exportkey=AQqPS2Qsm9%2Fgp6%2FPX4YhESE%3D&pass_ticket=HGuHrG7jjjdrE7HPMUEY6u5Fpu3R65Fm1y%2Fe1ceod4kcNAhXXOROOcuDr2CpFf2T&wx_header=0) 97 | 98 | * [【对话老宋】深入浅出OPC UA经典十五问](https://mp.weixin.qq.com/s?subscene=23&__biz=MzA3ODA0NDYyMw==&mid=2658339134&idx=1&sn=c2650339e487048f3467efab099aa645&chksm=84cf659eb3b8ec88acd28b82b0b45a00df37f97ccfb5736e0b79e0a7b5d5cd3be631d64b1a15&scene=7&key=3a4727f7169ab807bcc55b734e29915941e997609dde2402eb5166de021a8ed6acd8186b80abefa8f988e8072f719e188873080df95927c70a242d3c058902f86e02fe2c70231ca4d95fc292eed70c68f6b065f7c898d913533fe1d53901fc43097acf6d63e50002cc2f4d782869157e2b787deb60dac0fae25eceed70cd4b13&ascene=0&uin=NTkyMjg4NQ%3D%3D&devicetype=Windows+10+x64&version=6300002f&lang=zh_CN&exportkey=AVCp%2BDpxfsU41ReG8nFg7A0%3D&pass_ticket=gR0quaGlkm1uBmSeEDUBuHRps%2B0Tm5mUo1%2Fg20TwhW38%2BOQtrdAqevLUAr0BH3Cc&wx_header=0) -------------------------------------------------------------------------------- /docs/protocols/opc_ua_tsn.md: -------------------------------------------------------------------------------- 1 | # OPC UA TSN 2 | 3 | ![](../../resources/imgs/opc-ua_tsn_network_model.jpg) 4 | 5 | ## 需求来源 6 | 7 | 由于OPC UA欠缺一定实时性，所以要推荐OPC UA TSN，即OPC UA Over TSN。OPC UA来解决语义互操性，TSN[1](./tsn.md)负责解决实时性问题。 8 | 9 | ## IT和OT融合难度在哪里 10 | 11 | ### 现场总线到实时以太网 12 | 13 | 下图是一个对于制造业现场的通信网络进行了简要的描述，相对于传统的PLC集中式控制，现场总线为工业控制系统带来了很多便利，通过统一的总线连接实现了分布式控制，并且通过总线使得接线变得更为简单，而系统的配置、诊断的工作量因此也下降，因此，现场总线是为制造业现场带来很多便利的技术，然而，各家公司都开发了自己的总线，在IEC的标准中也有多达20余种总线。总线本身是带来便利的，但是，不同的总线又造成了新的壁垒，因为各家公司的业务聚焦、技术路线的不同，使得各个现场总线在物理介质、电平、带宽、节点数、校验方式、传输机制等多个维度都是不同的，因此造成了同一总线标准设备可以互联，而不同总线设备则无法互联。 14 | 15 | ![](../../resources/imgs/opc_ua_tsn_communication_scene.jpg) 16 | 17 | 这也是因何实时以太网技术在21世纪初开始投入使用的原因，2001年贝加莱推出POWERLINK实时以太网是工业领域第一个实时以太网，相较于传统总线，实时以太网的好处在于物理介质、节点数、距离、带宽、校验、诊断都统一采用标准的IEEE802.3网络，因此在这个层面上，大家实现了统一。 18 | 19 | ### 互联互通和互操作 20 | 21 | 但是，实时以太网只是解决了物理层与数据链路层的问题，对于应用层而言，仍然无法联通—按照IEC的标准，通信连接分为互连、互通、互操作多个层级，各个实时以太网是基于原有的三层网络架构（物理层、数据链路层、应用层），在应用层采用了诸如Profibus、CANopen等协议，而这些协议又无法实现语义互操作。 22 | 23 | 简单理解语义互操作就是“5+5”这样的计算在自动化控制中，是物理的信号直接进行的处理，而对于IT网络传输更多丰富的数据结构与类型时就会需要更多信息，如单位，“5英寸+5厘米”显然是无法进行加法计算的，这个时候我们需要语义规范与标准，以便让不同的系统之间认识到各自每个参数所表达的语义。 24 | 25 | ### 智能时代的工业通信 26 | 27 | 在前面我们讨论的是在工业现场水平与垂直方向实现物理信号的采集与信息的传输，但是，到了智能制造时代，我们需要更为全局的数据采集、传输、计算与分析、优化，进而实现制造的高效协同，提升整个生产效率。 28 | 29 | 下图简要描述了这一场景，从工厂到供应链的各个环节都需要数据的连接，那么这个时候，IT与OT的融合会遇到如下复杂性： 30 | 31 | ![](../../resources/imgs/opc-ua_tsn_deploy_scene.jpg) 32 | 33 | * 总线的复杂性带来的障碍 34 | 35 | 总线的复杂性不仅为制造现场带来复杂性，也同样为IT访问OT带来了巨大的障碍，因为为了不同的数据访问就得写不同的网络驱动程序，对于老的工厂采用的不同的物理介质的现场总线还需要配置额外的网络适配模块，然后就是在软件层面的驱动程序，即使采用实时以太网，语义仍然需要编写不同的接口程序，而丰富的现场总线与应用层组合出成千上万种可能，这使得IT为了配置网络、数据采集与连接、数据预处理等工作花费巨大，这使得实现这件工作缺乏经济性—这是技术推进难的首要障碍，如果无法经济的实施项目，那么就没有投入的必要。 36 | 37 | * 周期性与非周期性数据的传输 38 | 39 | IT与OT数据的不同也使得网络需求差异，这使得往往采用不同的机制，对于OT而言，其控制任务是周期性的，因此采用的是周期性网络，多数采用轮询机制，由主站对从站分配时间片的模式，而IT数据往往是非周期性的，由于标准以太网无法满足周期性的确定性传输以及微秒级的实时性，才开发了POWERLINK、Profinet等基于以太网的协议，然而，这些都无法在一个网络里传输两种不同的数据。 40 | 41 | * 实时性的差异 42 | 43 | 由于实时性的需求不同，也使得IT与OT网络有差异，对于微秒级的运动控制任务而言，要求网络必须要非常低的延时与抖动，而对于IT网络则往往对实时性没有特别的要求，但对数据负载有着要求。 44 | 45 | ## OPC UA TSN的角色 46 | 47 | OPC UA主要解决在应用层的问题，而TSN实质上是处于数据链路层。 48 | 49 | ### OPC UA的角色与意义 50 | 51 | 参考[OPC UA协议](opc_ua_guide.md) 52 | 53 | ### TSN的角色与意义 54 | 55 | 参考[TSN时间敏感网络协议](tsn.md) 56 | 57 | ### OPC UA TSN架构了未来智能制造网络 58 | 59 | 实际上OPC UA和TSN贯穿了整个OSI七层模型，使得通过统一标准与规范实现了一个真正的“工业互联网”—Industrial Internet。 60 | 61 | ![](../../resources/imgs/opc_ua_tsn_future_industy_scnario.jpg) 62 | 63 | 上图则是整个基于OPC UA TSN的工业互联网架构，我们可以看到，通过OPC UA在水平方向的不同品牌的控制器的设备可以被集成，而在垂直方向设备到工厂再到云端都可以被OPC UA连接。 64 | 65 | 而TSN则在控制器、控制器与底层传感器、驱动器之间的物理信息传输，OPC UA即可实现与传统的实时以太网结合构成数据的多个维度集成，在未来也可以通过TSN与OPC UA的集成实现全新的制造现场网络集成。 66 | 67 | ## 技术发展 68 | 69 | OPC UA已经成为IEC标准，并在2017年成为中国国家推荐性标准，在2018年发布了基于Pub/Sub的机制作为OPC UA的补充机制，在Part 13部分由IEC发布。 70 | 71 | TSN目前由IEEE标准组织进行标准的制定工作，目前已经完成的状态如表2。 72 | 73 | ## 总结 74 | 75 | OPC UA与TSN代表了未来工业互联网的技术趋势，也代表着OICT融合的实现道路，本文主要从OT的视角来理解OPC UA和TSN，对于IT端的应用而言，OPC UA TSN提供了访问的便利，然后才能进而产生业务模式的创新，基于边缘计算的产业应用场景，基于云连接的智能优化，以及产业业务模式的转变，真正实现数字化转型。 76 | 77 | ## 参考链接 78 | 79 | * [OPC UA TSN真的会成为未来工业通信的统一标准吗？](https://zhuanlan.zhihu.com/p/42704948) 80 | * [未来工业通信的“通用语言”——OPC UA TSN](https://www.sdnlab.com/23113.html) -------------------------------------------------------------------------------- /docs/protocols/tsn.md: -------------------------------------------------------------------------------- 1 | # TSN时间敏感网络协议 2 | 3 | ## 需求来源 4 | 5 | TSN是一项从视频音频数据领域延伸至工业领域、汽车领域的技术。TSN最初来源于音视频领域的应用需求，当时该技术被称为AVB，由于针对音视频网络需要较高的带宽和最大限度的实时，借助AVB能较好的传输高质量音视频。 6 | 7 | 2006年，IEEE802.1工作组成立AVB音频视频桥接任务组，并在随后的几年里成功解决了音频视频网络中数据实时同步传输的问题。这一点立刻受到来自汽车和工业等领域人士的关注。2012年，AVB任务组在其章程中扩大了时间确定性以太网的应用需求和适用范围，并同时将任务组名称改为现在的：TSN任务组。TSN是以以太网为基础的新一代网络标准，具有时间同步、延时保证等确保实时性的功能。 8 | 9 | ## 使用场景 10 | 11 | TSN使用标准以太网提供分布式时间同步和确定性通信。因此，任何需要分布式测量或控制的应用都可以从TSN中受益。客户可使用TSN进行简单的分布式同步测量、下一代计算机数控加工的改进、新型半导体加工机器以及未来的电网研究等。在其他行业的应用包括： 12 | 13 | ### 音视频传输 14 | 15 | TSN最初来源于视频领域的应用需求。传输音频和视频信息的网络需要遵守严格的时序规则。如果音频或视频分组不能按指定的时序规则到达目的地，则接收设备（例如视频屏幕或扬声器）可能会发生视频帧被丢弃、音频伪像的情况。此外，这种网络还需要可预测的延迟，保证视频和相关音频流之间的同步。另一方面，足球赛事的实况转播有很多高清的数据要通过网络传输到处理中心，对带宽的需求极大。而且为了最大限度的提供实时性，这些图像、音频必须实现高实时的传输与处理，可以想象其对带宽和实时性的需求。 16 | 17 | ### 汽车驾驶 18 | 19 | 目前大多数的汽车控制系统非常复杂。比如说：刹车、引擎、悬挂等采用CAN总线。而灯光、车门、遥控等采用LIN系统。娱乐系统更是五花八门，有FlexRay和MOST等目前的车载网络。实际上，所有上述系统都可以用支持低延时且具有实时传输机制的TSN进行统一管理。可以降低给汽车和专业的A/V设备增加网络功能的成本及复杂性。 20 | 21 | 在车辆中，实时功能对于某些应用至关重要。 为确保这些实时功能可用，必须在以太网控制器中设置具有直接访问硬件资源的机制。TSN使构建可扩展的以太网网络成为可能。为此，不同的消息按照其可用性分为了不同的等级，并对其延迟和优先级进行了分类，每个消息类被分配到一个固定的带宽。此外，TSN还支持冗余以太网系统，并且，为确保稳定的数据交换，定义了安全标准。 22 | 23 | ### 工业物联网 24 | 25 | 标准以太网的本质是一种非确定性网，但在工业领域必须要求确定性，一组数据包裹必须完整、实时、确定性的到达目的地，因此较新的TSN标准增加了中心控制、所有网络设备的时间同步以及更低的延迟等特性。为了达到尽可能低的绝对延迟，IEEE 802.1Qbv定义了一个时间感知整形器，它可以无视定时流量门的存在。 26 | 27 | TSN除了解决以太网的不确定性问题，还正在解决工业领域总线的复杂性问题。如今工业中 28 | 每种总线有着不同的物理接口、传输机制、对象字典，每种不同的技术背后都有不同的厂商在支持，难以统一。而且即使是采用了以太网来标准各个总线，仍然会在互操作层出现问题，这使得对于IT应用，如大数据分析、订单排产、能源优化等应用遇到了障碍。 29 | 30 | ## 具体内容 31 | 32 | TSN是一组以太网标准，允许通过802网络实现时间同步的低延迟流服务。通过标准以太网，TSN创建了分布式，同步，硬实时系统的机制。这些系统使用相同的基础架构来提供实时控制并传达所有标准IT数据，从而为控制、测量、配置、UI和文件交换基础架构的融合提供动力。通过基于时间定义队列，TSN可确保通过交换网络的流量具有有限的最大延迟。这意味着标准以太网现在可以： 33 | 34 | * 通过交换网络保证消息延迟 35 | * 关键和非关键流量可以在一个网络中融合 36 | * 更高层协议可以共享网络基础结构 37 | * 实时控制可以远离操作区域 38 | * 子系统可以更容易地集成 39 | * 可以在不进行网络或设备更改的情况下添加组件 40 | * 可以更快地诊断和修复网络故障 41 | 42 | TSN并非涵盖整个网络，TSN其实指的是在IEEE802.1标准框架下，基于特定应用需求制定的一组“子标准”，旨在为以太网协议建立“通用”的时间敏感机制，以确保网络数据传输的时间确定性。而既然是隶属于IEEE802.1下的协议标准，TSN就仅仅是关于以太网通讯协议模型中的第二层，也就是数据链路层（更确切的说是MAC层）的协议标准。请注意，是一套协议标准，而不是一种协议，就是说TSN将会为以太网协议的MAC层提供一套通用的时间敏感机制，在确保以太网数据通讯的时间确定性的同时，为不同协议网络之间的互操作提供了可能性。 43 | 44 | ![](../../resources/imgs/TSN_architecture.jpg) 45 | 46 | ## 组件 47 | 48 | 由IEEE 802.1制定的TSN标准文档可以分为三个基本关键组件。每个标准规范都可以单独使用，并且主要是自给自足的。但是，只有在每个规范协同使用的情况下，TSN作为通信系统才能充分发挥其潜力。三个基本组成部分是：`时间同步，调度和流量整形，通信路径的选择、预留和容错`。 49 | 50 | ### 时间同步 51 | 52 | TSN网络中的时间同步可以通过不同的技术实现。从理论上讲，可以为每个终端设备和网络交换机配备GPS时钟。然而，这种方法不仅昂贵，而且无法保证GPS时钟始终接入卫星信号。由于这些限制，TSN网络中的时间通常从一个中央时间源直接通过网络本身分配，也就是使用IEEE 1588精确时间协议完成。除了普遍适用的IEEE 1588规范之外，IEEE802.1委员会已经指定了一个IEEE1588的概要文件，称为IEEE802.1AS。此配置文件背后的想法是将大量不同的IEEE 1588选项缩小到可管理的几个关键选项，这些选项适用于汽车或工业自动化环境中得网络。 53 | 54 | ![](../../resources/imgs/TSN_time_sync.jpg) 55 | 56 | ### 调度和流量整形 57 | 58 | 由于端口转发机制的限制，在标准的以太网中，实时性是难以保证的。调度和流量整形允许在同一网络上共存不同优先级的流量类别，每个类别对可用带宽和端到端延迟都有不同的要求。因此，所有参与实时通信的设备在处理和转发通信包时需遵循相同的规则。 59 | 60 | ### 通信路径的选择，预留和容错 61 | 62 | 所有参与实时通信的设备在选择通信路径、预留带宽和时隙方面遵循相同的规则，可以利用多条路径来实现故障排除，支持保护诸如安全相关的控制回路或车辆中的自动驾驶之类的安全应用，以防止硬件或网络中的故障。 63 | 64 | ## 参考文章 65 | 66 | * [下一代工业通信—TSN（时间敏感网络），工业物联网的助推器](https://www.sdnlab.com/22868.html) -------------------------------------------------------------------------------- /resources/imgs/AVS-Integration-For-AWS-IoT-Core-Product-Page-Diagram_SkyHook.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/AVS-Integration-For-AWS-IoT-Core-Product-Page-Diagram_SkyHook.png -------------------------------------------------------------------------------- /resources/imgs/AWS IoT Core - Connect and Manage.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/AWS IoT Core - Connect and Manage.png -------------------------------------------------------------------------------- /resources/imgs/AWS IoT Core - Process and Act.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/AWS IoT Core - Process and Act.png -------------------------------------------------------------------------------- /resources/imgs/AWS IoT Core - Read and Set Device State.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/AWS IoT Core - Read and Set Device State.png -------------------------------------------------------------------------------- /resources/imgs/AWS IoT Core - Secure Connections.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/AWS IoT Core - Secure Connections.png -------------------------------------------------------------------------------- /resources/imgs/AWS-Greengate-Launch_Application-Arch.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/AWS-Greengate-Launch_Application-Arch.png -------------------------------------------------------------------------------- /resources/imgs/AWSIoTDeviceManagement_how_it_works.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/AWSIoTDeviceManagement_how_it_works.png -------------------------------------------------------------------------------- /resources/imgs/Greengrass_How-It-Works.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/Greengrass_How-It-Works.png -------------------------------------------------------------------------------- /resources/imgs/Greenkey.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/Greenkey.png -------------------------------------------------------------------------------- /resources/imgs/How it Works AWS IoT Device Defender.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/How it Works AWS IoT Device Defender.png -------------------------------------------------------------------------------- /resources/imgs/TSN_architecture.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/TSN_architecture.jpg -------------------------------------------------------------------------------- /resources/imgs/TSN_time_sync.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/TSN_time_sync.jpg -------------------------------------------------------------------------------- /resources/imgs/UA-Architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/UA-Architecture.png -------------------------------------------------------------------------------- /resources/imgs/aliyun_iot_platform.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/aliyun_iot_platform.png -------------------------------------------------------------------------------- /resources/imgs/aliyun_iot_platform_architecture.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/aliyun_iot_platform_architecture.jpg -------------------------------------------------------------------------------- /resources/imgs/aws_iot_platform.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/aws_iot_platform.png -------------------------------------------------------------------------------- /resources/imgs/azure_iiot_platform_architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/azure_iiot_platform_architecture.png -------------------------------------------------------------------------------- /resources/imgs/edge_computing_deploy_architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/edge_computing_deploy_architecture.png -------------------------------------------------------------------------------- /resources/imgs/edge_computing_design_architecture.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/edge_computing_design_architecture.png -------------------------------------------------------------------------------- /resources/imgs/edge_computing_design_architecture_detail.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/edge_computing_design_architecture_detail.png -------------------------------------------------------------------------------- /resources/imgs/field_bus_10.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/field_bus_10.png -------------------------------------------------------------------------------- /resources/imgs/field_bus_demo.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/field_bus_demo.png -------------------------------------------------------------------------------- /resources/imgs/field_bus_development.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/field_bus_development.png -------------------------------------------------------------------------------- /resources/imgs/ge_predix_asset_service.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/ge_predix_asset_service.png -------------------------------------------------------------------------------- /resources/imgs/ge_predix_iiot_platform.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/ge_predix_iiot_platform.png -------------------------------------------------------------------------------- /resources/imgs/gongzhonghao.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/gongzhonghao.jpg -------------------------------------------------------------------------------- /resources/imgs/huawei_iot_analyze.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/huawei_iot_analyze.png -------------------------------------------------------------------------------- /resources/imgs/ibm_iot_platform_architecture_layers.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/ibm_iot_platform_architecture_layers.png -------------------------------------------------------------------------------- /resources/imgs/iot-azure-data-explorer.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/iot-azure-data-explorer.png -------------------------------------------------------------------------------- /resources/imgs/it_vs_ot.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/it_vs_ot.png -------------------------------------------------------------------------------- /resources/imgs/modbus_master_slave.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/modbus_master_slave.jpg -------------------------------------------------------------------------------- /resources/imgs/opc-ua_tsn_deploy_scene.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/opc-ua_tsn_deploy_scene.jpg -------------------------------------------------------------------------------- /resources/imgs/opc-ua_tsn_network_model.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/opc-ua_tsn_network_model.jpg -------------------------------------------------------------------------------- /resources/imgs/opc_ua_information_model.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/opc_ua_information_model.jpg -------------------------------------------------------------------------------- /resources/imgs/opc_ua_tsn_communication_scene.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/opc_ua_tsn_communication_scene.jpg -------------------------------------------------------------------------------- /resources/imgs/opc_ua_tsn_future_industy_scnario.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/opc_ua_tsn_future_industy_scnario.jpg -------------------------------------------------------------------------------- /resources/imgs/opc_ua_tsn_iec_problems.jpg: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/opc_ua_tsn_iec_problems.jpg -------------------------------------------------------------------------------- /resources/imgs/sitewise-how-it-works.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/sitewise-how-it-works.png -------------------------------------------------------------------------------- /resources/imgs/why_we_use_opc_ua.png: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/soolaugust/iiot/fae984422be1f432e8d6b76043517bdf9a6f1d57/resources/imgs/why_we_use_opc_ua.png --------------------------------------------------------------------------------