精华内容
下载资源
问答
  • 前言 停机时间对任何制造商来说都会造成高昂的成本,对于石油和天然气行业也不例外。麻省理工学院斯隆分校的一项研究显示,液化天然气设施停机一天可能造成2500万...2.虹科IIOT解决方案 3.虹科边缘计算平台介绍及优势

    前言

    停机时间对任何制造商来说都会造成高昂的成本,对于石油和天然气行业也不例外。麻省理工学院斯隆分校的一项研究显示,液化天然气设施停机一天可能造成2500万美元的损失,典型的中型液化天然气设施每年停机约五次,即一年可能造成1.25亿美元的损失。

    结合高油价的现实,石油和天然气行业正在采用新技术来提高效率并最大程度地减少计划外停机时间,这意味着采用工业物联网(IIOT)解决方案对石油生产商而言变得越来越重要。

    本文将讨论:
    1.油气行业IIOT的挑战
    2.虹科IIOT解决方案
    3.虹科边缘计算平台介绍及优势

    在这里插入图片描述

    油气行业IIOT的挑战

    像许多其他行业一样,石油和天然气行业一直在变得越来越紧密。工业连接设备的增加主要是新的智能连接产品和经过传感器和网关改造的旧设备的结合。与许多行业不同,石油和天然气行业面临通讯上面的问题。

    据思科称,一个典型的海上石油平台每天会产生1-2TB的数据。将数据传输到中央存储库的通信链路通常是卫星连接,数据通过该卫星连接以64 Kbps到2Mbps的速率传输。受网络带宽限制,将一天的数据传输到数据中心可能需要12天。延迟也是一个问题,如果不使用实时数据,尤其是与平台效率和安全性相关的数据,常常会失去数据的可用性。

    在离数据收集地点更近的地方执行分析可以将网络带宽限制和延迟的影响降到最低,因此虹科提出边缘计算解决方案支持石油和天然气行业IIOT。
    在这里插入图片描述

    我们的IIOT解决方案

    通过IOT网关设备,可以在传感器附近本地收集和分析数据,而不必将其发送到远程SCADA系统。该设备还能设置数据的重要等级,如果数据没有任何更改,则不必在单位时间间隔内不断推送数据,只需在数据发生变化时进行推送,以此达到节省整个网络上的原始数据量的目的。使用IOT网关还可以进行本地存储,即使网络中断,数据也不会丢失。而且,它可以使用合适您的安全协议进行传输,例如OPC UA,MQTT,CoAP等。

    采用边缘计算解决方案和支持这些解决方案的软件平台(例如用于石油和天然气行业的虹科的Edge Xpert边缘平台)是整个行业趋势的一部分,该趋势促进用户更靠近收集位置使用数据。

    虹科边缘计算平台介绍及优势

    虹科Edge Xpert边缘平台是边缘运算中间件,可采集众多通讯协议设备的数据,实时连接设备,配置简单,使用易操作的工具来帮助安装和连接新设备,轻松集成边缘端OT设备和传感器。并且可对数据过滤清洗,进行数据分析利用,达到有效利用数据、降低网络负载的目的。
    在这里插入图片描述
    虹科Edge Xpert可实现OT和IT的融合,在南向拥有众多的通讯协议实现实时采集数据,在北向可以对接各类系统数据库和云端,以及拥有OPC UA,MQTT等通用的物联网协议。
    在这里插入图片描述虹科Edge Xpert边缘计算平台拥有开放式的系统,以最大限度提高您的选择范围、灵活性和协作性,可实现快速开发并部署工业IOT,并解决了OT和IT世界融合的关键业务互操作性问题,以及分布式IOT边缘架构中数据从南向北,从东向西流动的问题。

    展开全文
  • 我们今天来聊聊IIoT解决方案中需要哪些常见的功能。  我们先用一个更详细的价值表格回顾下IIoT的价值点。 应用场景 价值点 规模(10亿) ...

    前一次和大家聊到IIoT的价值以及参考的解决方案通用模型。我们今天来聊聊IIoT解决方案中需要哪些常见的功能。

       我们先用一个更详细的价值表格回顾下IIoT的价值点。

    应用场景

    价值点

    规模(10亿)

    工厂

    运营(操作)优化(operation optimization)

    633-1766

    预测性维护(Predictive maintenance)

    240-627

    库存优化Inventory optimization

    98-342

    工人健康和安全(Health and safety)

    65-226

    增强现实设备(Augmented-reality devices)

    52-338

    减少假药Counterfeit drug  reduction (hospital)

    30-117

    人员效率提升 Human productivity(augmented reality)

    30-60

    人员效率提升Human productivity(monitoring)

    22-50

    人员效率提升Human productivity(organization redesign)

    17-50

    基于使用的设计Usage-based design

    10-57

    其他(生产物流,医院安全能源,售前分析)

    工地

    运营优化(operation optimization)

    56-473

    改善设备维修(Improved  equipment  maintenance)

    81-363

    健康和安全(Health and safety management)

    3-29

    生产力(Human productivity)

    17-37

    其他(基于使用的设计,售前分析)

    城市

    空气和水的监控(Air and water monitoring)

    403-693

    自适应交通管理(Adaptive traffic management)

    223-504

    自动驾驶汽车Autonomous vehicles (fully and partially)

    204-253

    资源/基础设施管理(resource/ infrastructure management)

    33-64

    灾害/紧急服务Disaster/emergency services

    24-41

    其他(公共交通时刻表,人的生产力)

    外部环境

    物流路径Logistics routing

    253-460

    自动驾驶车(乗用车和卡车)

    249-279

    包裹/集装箱跟踪Package/container tracking

    7-30

    船,飞机,车导航

    9-17

    状态维修(铁路)Condition-based  maintenance

    3-10

        我们针对不同的设备安装场景,以及结合成熟度模型可以简单总结下工业物联网解决方案需要以下几类常见功能。

        这些功能都是一个完整的解决方案需要考虑的问题。不管是选择一个PaaS还是SaaS的IIoT平台或者解决方案提供商。用户都可以从这几个维度去考量供应商提供的服务或者未来可以提供的服务。


       由于牵涉的功能比较多,我今天就不一一细聊。我会在里面重点抽取几个核心功能与大家一起分享。

       在分享之前呢,我希望大家要有一个共识:那就是IIoT的业务是动态变化的,同时IIoT业务往往是面向OT人员的。这两个属性其实在构建完整的解决方案的时候会重点考虑功能模块的构建。


       平台连接能力:

       IIoT的平台连接能力需要比一般消费级物联网市场的连接能力要求更高。除了需要具备终端与平台打通的协议以外还需要考虑以下几个问题。

       第一:连接能力是否可以构建VPN通道或者使用同类技术与工业设备打通。使得工业现场设备可以实现远程程序的调试和更新。(一般平台的解决方案往往只考虑到和物联网终端:网关的打通,而忽略对管理的工业设备的OTA)

       第二:连接能力是否具备支持不同的工业现场协议:包括PLC,CNC,电力,楼宇,环保等专用协议等。同时考虑对不同协议进行点表的配置(协议语义的解读,因为每个现场的设备即使协议相同点表大都不同

      第三:是够考虑物联网终端的安全问题:包括专用网络,数据加密,访问控制等等。

       第四:是够考虑数据本地缓存,数据清洗以及本地计算等等边缘计算能力。(IIoT边缘计算的价值远高于消费级物联网,可以实现保障数据的完整性,支持快速或者离线触发方式,降低流量成本等等功能

       目前来看。国内的平台厂家在接入这块往往只考虑到协议接入,其他功能并没有针对IIoT的需求特点做进一步的改善。目前BAT中看起来也只有百度天工做了物解析(点表配置功能)。而真正完善的接入解决方案仍然欠缺。


      平台基本能力:

      平台基本能力这块我主要讲四点

      第一:时序数据库,目前百度,阿里,普奥云等都采用了高性能的时序数据库(阿里云还在测试中)。时序数据是基于时间的一系列的数据。在有时间的坐标中将这些数据点连成线,往过去看可以做成多纬度报表,揭示其趋势性、规律性、异常性;往未来看可以做大数据分析,机器学习,实现预测和预警。可以说时序数据库是存储物联网数据的最佳选择。

      第二:数据模型化,针对工业设备的数据不仅仅需要支持以设备对象建模同时还需要以业务对象方式建模。

      第三:可编辑的设计器。工业物联网的数据可视化是非常多样的。不仅仅有工业组态的可视化,还需要有仪表板以及KQI仪表板的可视化。同时还需要一些专业视图(例如振动,电气等等)和类似BI同时支持时序数据的分析仪表板可视化能力。目前这块普奥云支持比较丰富,百度天工和CloudLinx,Thinglinx等也支持一部分能力。

      第四:针对开发者的相关功能,目前只有百度阿里等平台支持。

      

       数据分析:

       这块百度阿里等都在机器学习或者深度学习(人工智能)方面加大投入,也是这些大厂的核心卖点。

       但是大家容易忽略的是,机器学习和人工智能分析依赖于大量的数据样本,同时往往只是找到相关性。也就是说通过机器学习和人工智能分析获得的商业价值其实相对漫长。

       而现在客户需要的基于时序的BI分析,专业分析,公式计算等是可以立即植入领域经验同时快速获得经济价值的分析方式。这块目前只有一些独立的物联网平台商在构建能力。而像百度阿里的PaaS平台暂时没办法做到。


      数据可视化:

       IIoT平台的可视化能力主要分为以下几个阶段

       第一:实时数据和历史数据的场景化展示。这里面需要用到的功能包括组态视图,dashboard,3D视图等等。

       其中组态视图可以说是最工业的一种功能。每一个现场都不一样,需要通过组态进行场景的构建完善设备工艺流程。帮助工程师直观的展示数据。当然,3D是进一步直观的展示数据的一种方式。

       第二:AR支持,工业物联网中设备维修和操作的AR场景可以说是吹起了AR创业的一阵风。突然间国内出现了很多创业团队。本人也是非常看好AR在工业的应用。麦肯锡报告中也预测AR对人员生产力提升在工厂就有300-600亿美元的规模。

       第三:可自由定制报表。

       

       业务闭环能力:

       IIoT的数据可以为多个人,多个部分,多个企业服务。数据分享是趋势同时数据分享越广价值越大。当企业上下游实现互联的时候也许工业互联网就真的到来了。

       不过,我个人分析,目前国内市场成熟度不高,IIoT的数据还是以部门级别的业务闭环为主。通过部门级业务闭环业务功能构建,可以快速为企业带来物联网的投资回报。所以在解决方案中有哪些应用场景需要识别出来。

    以下是不同场景下的业务闭环。

        

        好了,简单的介绍了下IIoT解决方案中的关键功能。这些功能往往是一家企业实现不了的。同IIoT的解决方案会呈现沙漏型。所以,未来一定是多个企业集成解决的思路。

        

                                   

                                    

        大家下次再遇到做工业物联网的,一方面可以参考这个架构去选择自己的供应商同时也可以快速的识别出不同的厂家提供的是哪些部分的功能模块。


    展开全文
  • 工业物联网需要底层更多数据的支撑,由于制造工厂正在寻求从生产线中获取更多的信息和数据,所以对当前的设备进行改装是正确且必要的选择。...虹科IO-Link Wireless解决方案: 虹科的IO-Link Wireless产品提供了

    工业物联网需要底层更多数据的支撑,由于制造工厂正在寻求从生产线中获取更多的信息和数据,所以对当前的设备进行改装是正确且必要的选择。

    制造工厂面临的挑战:

    Apollo工厂正在分析生产线中各种传感器的数据,这需要从数百台不同的机器上收集数据以进行维护优化和节能。

    他们在每个设备上增加了工业空气流量传感器。

    现在,他们还增加了振动传感器。

    这需要更多的布线布局,很复杂并且很难扩展。

    虹科IO-Link Wireless解决方案:

    虹科的IO-Link Wireless产品提供了市场上性价比最高、易于部署、灵活和可扩展的无线解决方案。

    方案一:DIO/IO-Link传感器/执行器+无线桥+主站/网关

    方案二:DIO/AI的传感器/执行器+IO-Link Hub+无线桥+主站/网关

    虹科工业无线解决方案,简单、经济、高效地改造现有机器上的众多设备,它专门为恶劣的工业环境而设计,解除了工业空间的束缚。

    本次案例用到的有:

    1、无线桥——TigoBridge

    TigoBridge是具有IP67外壳的IO-Link无线桥接器。将IO-Link和数字数据(DIO)信号转换为IO-Link无线信号。

    2、IO-Link Wireless主站—TigoMaster 2TH

    TigoMaster 2TH是具有IP67防护外壳的2通道工业级IO-Link无线主站,内嵌TigoMaster 2T SOM模块。每条通道最多支持8个设备,从而同时支持多达16个IO-Link无线设备。每条通道都使用自己的收发器和专用天线。

    TigoMaster 2TH包括各种工业以太网和现场总线协议的接口 , 如PROFINET 、 EtherCAT 、 Ethernet/IP  OPC-UA 和MQTT, 可 以直接连 接 到 PLC ( OT 网 络 ) 和 IT 网 络 。TigoMaster 2TH可以通过TigoEngine进行设置、配置和监控,TigoEngine是用于IO-Link无线系统的工程工具。

    TigoMASTER 2TH通常用于以下无线任务关键型应用:

    ·机器人/协作机器人上的末端执行器(例如夹具、真空泵)的无线控制,以消除电缆,增加灵活性和降低复杂性

    ·在线性运输轨道系统中,快速移动载体上的传感器和执行器的无线控制

    ·在苛刻条件下,从快速旋转部件中收集数据,如数控机床上的刀具处理程序

    3、IO-Link Wireless主站—TigoMaster 2TS

    TigoMaster 2TS是一款用于物联网和工业4.0应用的IO-Link无线工业级主站。它能够与自动化OT网络集成和连接,将机器数据从车间传输到本地制造厂软件或其他企业系统。TigoMaster 2TS 与 TigoEngine 工程软件和TigoInsights监控软件完全兼容。

    TigoMaster 2TS包括:

     ·2通道IO-Link无线主站

    · 独立能力

    · 与任何PC/IPC/服务器轻松连接

    典型的应用程序包括用于各种行业中的多个环境的协作机器人、旋转组件IIOT。主站是基于工业适合的MCU设计,使其运行任何自定义的应用程序。

    4、IO-Link Wireless网关—TigoGateway

    TigoGateway是用于云、物联网和工业4.0应用的IO-Link无线工业级网关。它支持与工厂自动化OT网络和IT网络同时进行集成和连接,以将机器数据从车间传输到云或其他企业系统。TigoGateway与TigoEngine和TigoInsightsN软件完全兼容。

    TigoGateway包括:

    ·2通道IO-Link无线主站

    · 紧凑型工业PC平台

     ·多种有线和无线接口(例如Wi-Fi、蓝牙、现场总线和工业以太网[PROFINET、EtherCAT、EtherNet / IP]、OPC-UA等)

    典型的应用包括各种行业中多种环境的状态监测和预测维护。网关基于工业适用的定制树莓3设计,以运行任何自定义应用的边缘自动化。TigoGateway支持通过云进行固件更新。

    关于虹科工业通讯

    虹科是一家在工业自动化领域,特别是工业总线通讯行业经验超过10年的高科技公司。虹科工业通讯事业部与世界知名的工业通讯专家PEAK-System,Hilscher,Kunbus,SYS TEC,Koenig-Pa,Port,Copa-data,TenAsys,SoC-e、RELYUM】等深度合作,提供业内顶尖水平的工业总线协议软硬件解决方案,协议类型包含【CAN、CANopen、EtherCAT、Profibus、Profinet、EtherNET/IP、TSN】等,产品类型包含代码、软件、芯片、板卡、模块等。虹科工业通讯以客户需求为导向,以技术能力为基础,为国内企业提供最适合的产品和最满意的服务。特别是在工业4.0的大环境下,虹科工业通讯与时俱进,推出了TSN(时间敏感网络)的解决方案,后者将在推动万物互联的潮流中扮演着如高速公路般的连接作用。

    微信扫一扫,关注我们获取更多工业通讯干货~

    点击链接,关注我们的实时动态:www.hongconsys.com

    展开全文
  • iiot解决方案 Hello, my name is Andrey Sergeyev and I work as a Head of IoT Solution Development at 您好,我叫Andrey Sergeyev,我是Mail.ru Cloud Solutions. We all know there is no such thing as a ...

    Hello, my name is Andrey Sergeyev and I work as a Head of IoT Solution Development at Mail.ru Cloud Solutions. We all know there is no such thing as a universal database. Especially when the task is to build an IoT platform that would be capable of processing millions of events from various sensors in near real-time.

    您好,我叫Andrey Sergeyev,我是Mail.ru Cloud Solutions的IoT解决方案开发负责人。 众所周知,没有通用数据库。 尤其是当任务是建立一个IoT平台时,它将能够近乎实时地处理来自各种传感器的数百万个事件。

    Our product Mail.ru IoT Platform started as a Tarantool-based prototype. I’m going to tell you about our journey, the problems we faced and the solutions we found. I will also show you a current architecture for the modern Industrial Internet of Things platform. In this article we will look into:

    我们的产品Mail.ru IoT Platform最初是基于Tarantool的原型。 我将向您介绍我们的旅程,遇到的问题以及找到的解决方案。 我还将向您展示现代工业物联网平台的当前体系结构。 在本文中,我们将研究:

    • our requirements for the database, universal solutions, and the CAP theorem

      我们对数据库,通用解决方案和CAP定理的要求
    • whether the database + application server in one approach is a silver bullet

      数据库+应用服务器在一种方法中是否是灵丹妙药
    • the evolution of the platform and the databases used in it

      平台及其中使用的数据库的发展
    • the number of Tarantools we use and how we came to this

      我们使用的Tarantools的数量以及我们如何实现这一目标

    Mail.ru物联网平台 (Mail.ru IoT Platform today)

    Our product Mail.ru IoT Platform is a scalable and hardware-independent platform for building Industrial Internet of Things solutions. It enables us to collect data from hundreds of thousands devices and process this stream in near real-time by using user-defined rules (scripts in Python and Lua) among other tools.

    我们的产品Mail.ru IoT Platform是一个可扩展且独立于硬件的平台,用于构建工业物联网解决方案。 它使我们能够从数十万个设备中收集数据,并通过使用用户定义的规则(Python和Lua中的脚本)以及其他工具来近乎实时地处理此流。

    The platform can store an unlimited amount of raw data from the sources. It also has a set of ready-made components for data visualization and analysis as well as built-in tools for predictive analysis and platform-based app development.

    该平台可以存储来自源的无限量的原始数据。 它还具有一组用于数据可视化和分析的现成组件,以及用于预测分析和基于平台的应用程序开发的内置工具。

    Mail.ru IoT Platform set-upMail.ru IoT平台设置

    The platform is currently available for on-premise installation on customers’ facilities. In 2020 we are planning its release as a public cloud service.

    该平台当前可用于在客户设施上进行本地安装。 我们计划在2020年将其作为公共云服务发布。

    基于Tarantool的原型:我们如何开始 (Tarantool-based prototype: how we started)

    Our platform started as a pilot project – a prototype with a single instance Tarantool. Its primary functions were receiving a data stream from the OPC server, processing the events with Lua scripts in real-time, monitoring key indicators on its basis, and generating events and alerts for upstream systems.

    我们的平台从一个试点项目开始–一个具有单一实例Tarantool的原型。 它的主要功能是从OPC服务器接收数据流,使用Lua脚本实时处理事件,在其基础上监视关键指标以及为上游系统生成事件和警报。

    Flowchart of the Tarantool-based prototype基于Tarantool的原型的流程图

    This prototype has even shown itself in the field conditions of a multi-well pad in Iraq. It worked at an oil platform in the Persian Gulf, monitoring key indicators and sending data to the visualization system and the event log. The pilot was deemed successful, but then, as it often happens with prototypes, it was put into cold storage until we got our hands on it.

    该原型甚至在伊拉克的一个多Kong井场的野外条件下展示了自己。 它在波斯湾的一个石油平台上工作,监视关键指标并将数据发送到可视化系统和事件日志。 试点被认为是成功的,但随后,就像在原型中经常发生的那样,将其放入冷藏室,直到我们动手为止。

    我们的目标是开发物联网平台 (Our aims in developing the IoT platform)

    Along with the prototype, we got ourselves a challenge of creating a fully functional, scalable, and failsafe IoT platform that could then be released as a public cloud service.

    除了原型之外,我们还面临创建一个功能齐全,可扩展且具有故障保护功能的物联网平台的挑战,该平台随后可以作为公共云服务发布。

    We had to build a platform with the following specifications:

    我们必须构建一个具有以下规范的平台:

    1. Simultaneous connection of hundreds of thousands of devices

      同时连接数十万个设备
    2. Receiving millions of events every second

      每秒接收数百万个事件
    3. Datastream processing in near real-time

      几乎实时的数据流处理
    4. Storing several years of raw data

      存储数年的原始数据
    5. Analytics tools for both streaming and historic data

      流数据和历史数据的分析工具
    6. Support for deployment in multiple data centers to maximize disaster tolerance

      支持在多个数据中心中进行部署以最大程度地提高容灾能力

    平台原型的优缺点 (Pros and cons of the platform prototype)

    At the start of active development the prototype had the following structure:

    在积极开发的开始,原型具有以下结构:

    • Tarantool that was used as a database + Application Server

      用作数据库+ Application Server的Tarantool
    • all the data was stored in Tarantool’s memory

      所有数据都存储在Tarantool的内存中
    • this Tarantool had a Lua app that performed the data reception and processing and called the user scripts with incoming data

      这个Tarantool有一个Lua应用程序,该应用程序执行数据接收和处理,并使用传入的数据调用用户脚本
    This type of app structure has its advantages:这种应用程序结构具有以下优点:
    1. The code and the data are stored in one place – that enables to manipulate the data right in the application memory and get rid of extra network manipulations, which are typical for traditional apps

      代码和数据存储在一个地方–可以在应用程序内存中直接处理数据,并且摆脱了传统应用程序常见的额外网络操作
    2. Tarantool uses the JIT (Just in Time Compiler) for Lua. It compiles Lua code into machine code, allowing simple Lua scripts to execute at the C-like speed (40,000 RPS per core and even higher!)

      Tarantool使用Lua的JIT(Just in Time Compiler)。 它将Lua代码编译为机器代码,从而允许简单的Lua脚本以类似于C的速度执行(每个内核40,000 RPS甚至更高!)。
    3. Tarantool is based upon cooperative multitasking. This means that every call of stored procedure runs in its own coroutine-like fiber. It gives a further performance boost for the tasks with I/O operations, e.g. network manipulations

      Tarantool基于协作式多任务处理。 这意味着存储过程的每次调用都在其自己的类似协程的光纤中运行。 对于具有I / O操作(例如网络操作)的任务,它可以进一步提高性能
    4. Efficient use of resources: tools capable of handling 40,000 RPS per core are quite rare

      有效利用资源:每个内核能够处理40,000 RPS的工具非常稀少
    There are also significant disadvantages:也有明显的缺点:
    1. We need storing several years of raw data from the devices, but we don’t have hundreds of petabytes for Tarantool

      我们需要从设备存储数年的原始数据,但是我们没有数百PB的Tarantool
    2. This item directly results from advantage #1. All of the platform code consists of procedures stored in the database, which means that any codebase update is basically a database update, and that sucks

      此项直接来自优势1。 所有平台代码都由存储在数据库中的过程组成,这意味着任何代码库更新基本上都是数据库更新,这很糟糕
    3. Dynamic scaling gets difficult because the whole system’s performance depends on the memory it uses. Long story short, you can’t just add another Tarantool to increase the bandwidth capacity without losing 24 to 32 Gb of memory (while starting, Tarantool allocates all the memory for data) and resharding the existent data. Besides, when sharding, we lose the advantage #1 – the data and the code may not be stored in the same Tarantool

      动态扩展变得困难,因为整个系统的性能取决于它使用的内存。 长话短说,您不能仅仅添加另一个Tarantool来增加带宽容量而不会丢失24到32 Gb的内存(启动时,Tarantool会为数据分配所有内存)并重新分片现有数据。 此外,在分片时,我们失去了#1的优势–数据和代码可能无法存储在同一Tarantool中
    4. Performance deteriorates as the code gets more complex with the platform progress. This happens not only because Tarantool executes all the Lua code in a single system stream, but also because the LuaJIT goes into interpreting mode instead of compiling when dealing with complex code

      随着平台的发展,代码变得越来越复杂,性能会下降。 发生这种情况,不仅是因为Tarantool在单个系统流中执行了所有Lua代码,而且还因为LuaJIT在处理复杂代码时进入了解释模式,而不是进行编译
    Conclusion: Tarantool is a good choice for creating an MVP, but it doesn’t work for a fully functional, easily maintained, and failsafe IoT platform capable of receiving, processing, and storing data from hundreds of thousands of devices.结论: Tarantool是创建MVP的不错选择,但不适用于功能齐全,易于维护且具有故障安全能力的IoT平台,该平台能够接收,处理和存储来自成千上万个设备的数据。

    我们要解决的两个主要问题 (Two primary problems that we wanted to solve)

    First of all, there were two main issues we wanted to sort out:

    首先,我们要解决两个主要问题:

    1. Ditching the concept of database + application server. We wanted to update the app code independently of the database.

      抛弃了数据库+应用服务器的概念。 我们想要独立于数据库更新应用程序代码。
    2. Simplifying the dynamic scaling under stress. We wanted to have an easy independent horizontal scaling of the greatest possible number of functions

      简化压力下的动态缩放。 我们希望对最大数量的功能进行简单的独立水平缩放

    To solve these problems, we took an innovative approach that was not well tested – the microservice architecture divided into Stateless (the applications) and Stateful (the database).

    为了解决这些问题,我们采用了未经测试的创新方法–微服务体系结构分为无状态(应用程序)和有状态(数据库)。

    In order to make maintenance and scaling the Stateless services out even simpler, we containerized them and adopted Kubernetes.

    为了简化维护和扩展无状态服务,我们将它们容器化并采用了Kubernetes。

    Now that we figured out the Stateless services, we have to decide what to do with the data.

    既然我们已经找到了无状态服务,我们就必须决定如何处理数据。

    物联网平台数据库的基本要求 (Basic requirements for the IoT platform database)

    At first, we tried not to overcomplicate things – we wanted to store all the platform data in one single universal database. Having analyzed our goals, we came up with the following list of requirements for the universal database:

    最初,我们尝试不使事情复杂化–我们希望将所有平台数据存储在一个通用数据库中。 在分析了我们的目标之后,我们提出了通用数据库的以下需求列表:

    1. ACID transactions – the clients will keep a register of their devices on the platform, so we wouldn’t want to lose some of them upon data modification

      ACID交易 –客户将在平台上保留其设备的注册,因此我们不希望在数据修改时丢失其中的一些设备

    2. Strict consistency – we have to get the same responses from all of the database nodes

      严格的一致性 –我们必须从所有数据库节点获得相同的响应

    3. Horizontal scaling for writing and reading – the devices send a huge stream of data that has to be processed and saved in near real-time

      用于写入和读取的水平缩放 –设备发送大量数据流,这些数据流必须实时处理和保存

    4. Fault tolerance – the platform has to be capable of manipulating the data from multiple data centers to maximize fault tolerance

      容错 –平台必须能够处理来自多个数据中心的数据,以最大程度地提高容错能力

    5. Accessibility – no one would use a cloud platform that shuts down whenever one of the nodes fails

      可访问性 –没有人会使用一个云平台,该云平台在任何一个节点发生故障时都会关闭

    6. Storage volume and good compression – we have to store several years (petabytes!) of raw data that also needs to be compressed.

      存储量和良好的压缩率 –我们必须存储数年(PB!)的原始数据,这些数据也需要进行压缩。

    7. Performance – quick access to raw data and tools for stream analytics, including access from the user scripts (tens of thousands of reading requests per second!)

      性能 –快速访问原始数据和用于流分析的工具,包括从用户脚本访问(每秒数以万计的读取请求!)

    8. SQL – we want to let our clients run analytics queries in a familiar language

      SQL –我们希望让客户以熟悉的语言运行分析查询

    用CAP定理检查我们的要求 (Checking our requirements with the CAP theorem)

    Before we started examining all the available databases to see if they meet our requirements, we decided to check whether our requirements are adequate by using a well-known tool – the CAP theorem.

    在我们开始检查所有可用数据库以查看它们是否满足我们的要求之前,我们决定使用一个众所周知的工具CAP定理来检查我们的要求是否足够。

    The CAP theorem states that a distributed system cannot simultaneously have more than two of the following qualities:

    CAP定理指出,分布式系统不能同时具有以下两个以上的性质:

    1. Consistency – data in all of the nodes have no contradictions at any point in time

      一致性 –所有节点上的数据在任何时间点都没有矛盾

    2. Availability – any request to a distributed system results in a correct response, however, without a guarantee that the responses of all system nodes match

      可用性 –对分布式系统的任何请求都将导致正确的响应,但是不能保证所有系统节点的响应都匹配

    3. Partition tolerance – even when the nodes are not connected, they continue working independently

      分区容限 –即使未连接节点,它们也可以继续独立工作

    For instance, the Master-Slave PostgreSQL cluster with synchronous replication is a classic example of a CA system and Cassandra is a classic AP system.

    例如,具有同步复制功能的Master-Slave PostgreSQL集群是CA系统的经典示例,而Cassandra是经典的AP系统。

    Let’s get back to our requirements and classify them with the CAP theorem:

    让我们回到我们的要求,并用CAP定理对它们进行分类:

    1. ACID transactions and strict (or at least not eventual) consistency are C.

      ACID交易和严格的(或至少不是最终的)一致性是C。
    2. Horizontal scaling for writing and reading + accessibility is A (multi-master).

      用于读写的水平缩放+可访问性为A(多主机)。
    3. Fault tolerance is P: if one data center shuts down, the system should stand.

      容错能力为P:如果一个数据中心关闭,则系统应处于待机状态。
    Conclusion: the universal database we require has to offer all of the CAP theorem qualities, which means that none of the existing databases can fulfill all of our needs.结论:我们需要的通用数据库必须提供所有CAP定理品质,这意味着现有数据库都无法满足我们的所有需求。

    根据IoT平台使用的数据选择数据库 (Choosing the database based on the data the IoT platform works with)

    Being unable to pick a universal database, we decided to split the data into two types and choose a database for each type the database will work with.

    由于无法选择通用数据库,我们决定将数据分为两种类型,并为每种数据库将使用的类型选择一个数据库。

    With a first approximation we subdivided the data into two types:

    通过第一近似,我们将数据细分为两种类型:

    1. Metadata – the world model, the devices, the rules, the settings. Practically all the data except the data from the end devices

      元数据 –世界模型,设备,规则,设置。 几乎所有数据,除了来自终端设备的数据

    2. Raw data from the devices – sensor readings, telemetry, and technical information from the devices. These are time series of messages containing a value and a timestamp

      来自设备的原始数据 –传感器读数,遥测和来自设备的技术信息。 这些是包含值和时间戳记的消息的时间序列

    为元数据选择数据库 (Choosing the database for the metadata)

    Our requirements我们的要求

    Metadata is inherently relational. It is typical for this data to have a small amount and be rarely modified, but the metadata is quite important. We can’t lose it, so consistency is important – at least in terms of asynchronous replication, as well as ACID transactions and horizontal read scaling.

    元数据本质上是关系的。 通常,此数据量很少且很少修改,但是元数据非常重要。 我们不会丢失它,因此一致性非常重要-至少在异步复制,ACID事务和水平读取缩放方面。

    This data is comparatively little in amount and it will be changed rather infrequently, so you can ditch horizontal read scaling, as well as the possible inaccessibility of the read database in case of failure. That is why, in the language of the CAP theorem, we need a CA system.

    此数据量相对较小,并且很少更改,因此您可以放弃水平读取缩放,以及在发生故障的情况下可能无法访问读取数据库。 这就是为什么用CAP定理的语言,我们需要一个CA系统。

    What usually works. If we put a question like this, we would do with any classic relational database with asynchronous replication cluster support, e.g. PostgreSQL or MySQL.通常会起作用。 如果我们提出这样的问题,那么我们将使用支持异步复制群集的任何经典关系数据库,例如PostgreSQL或MySQL。 Our platform aspects. We also needed support for trees with specific requirements. The prototype had a feature taken from the systems of the RTDB class (real-time databases) – modeling the world using a tag tree. They enable us to combine all the client devices in one tree structure, which makes managing and displaying a large number of devices much easier.我们平台的方面。 我们还需要对具有特定要求的树木的支持。 该原型具有从RTDB类系统(实时数据库)中提取的功能-使用标签树对世界进行建模。 它们使我们能够将所有客户端设备组合成一个树形结构,这使得管理和显示大量设备变得更加容易。
    This is how the device tree looks like这是设备树的样子

    This tree enables linking the end devices with the environment. For example, we can put devices physically located in the same room in one subtree, which facilitates the work with them in the future. This function is very convenient, besides, we wanted to work with RTDBs in the future, and this functionality is basically the industry standard there.

    通过该树,可以将终端设备与环境链接。 例如,我们可以将物理上位于同一房间中的设备放在一棵子树中,这便于将来与它们一起工作。 此功能非常方便,此外,我们希望将来与RTDB一起使用,并且该功能基本上是该行业的行业标准。

    To have a full implementation of the tag trees, a potential database must meet the following requirements:

    要完全实现标签树,潜在的数据库必须满足以下要求:

    1. Support for trees with arbitrary width and depth.

      支持任意宽度和深度的树木。
    2. Modification of tree elements in ACID transactions.

      修改ACID事务中的树元素。
    3. High performance when traversing a tree.

      遍历树时的高性能。

    Classic relational databases can handle small trees quite well, but they don’t do as well with arbitrary trees.

    经典的关系数据库可以很好地处理小树,但对于任意树却不能做到。

    Possible solution. Using two databases: a graph one for the tree and the relational one for all the other metadata.可能的解决方案。 使用两个数据库:一个图用于树,关系图用于所有其他元数据。

    This approach has major disadvantages:

    这种方法的主要缺点是:

    1. To ensure consistency between two databases, you need to add an external transaction coordinator.

      为了确保两个数据库之间的一致性,您需要添加一个外部事务协调器。
    2. This design is difficult to maintain and not so reliable.

      这种设计很难维护,而且不太可靠。
    3. As a result, we get two databases instead of one, while the graph database is only required for supporting limited functionality.

      结果,我们得到两个数据库,而不是一个,而图形数据库仅是为了支持有限的功能而需要的。
    A possible, but not a perfect solution with two databases两个数据库的可能但不是完美的解决方案 Our solution for storing metadata. We thought a little longer and remembered that this functionality was initially implemented in a Tarantool-based prototype and it turned out very well.我们用于存储元数据的解决方案。 我们考虑了一会儿,并记住该功能最初是在基于Tarantool的原型中实现的,结果非常好。

    Before we continue, I would like to give an unorthodox definition of Tarantool: Tarantool is not a database, but a set of primitives for building a database for your specific case.

    在继续之前,我想给出一个非常规的Tarantool定义: Tarantool不是数据库,而是用于为您的特定情况构建数据库的一组原语。

    Available primitives out of the box:

    开箱即用的可用原语:

    • Spaces – an equivalent of tables for storing data in the databases.

      空间–等同于用于在数据库中存储数据的表。
    • Full-fledged ACID transactions.

      全面的ACID交易。
    • Asynchronous replication using WAL logs.

      使用WAL日志的异步复制。
    • A sharding tool that supports automatic resharding.

      支持自动重新分片的分片工具。
    • Ultrafast LuaJIT for stored procedures.

      用于存储过程的Ultrafast LuaJIT。
    • Large standard library.

      大型标准库。
    • LuaRocks package manager with even more packages.

      LuaRocks软件包管理器,提供更多软件包。

    Our CA solution was a relational + graph Tarantool-based database. We assembled perfect metadata storage with Tarantool primitives:

    我们的CA解决方案是基于关系+图形Tarantool的数据库。 我们使用Tarantool原语组装了完美的元数据存储:

    • Spaces for storage.

      存放空间。
    • ACID transactions – already in place.

      ACID交易–已经到位。
    • Asynchronous replication – already in place.

      异步复制-已经到位。
    • Relations – we built them upon stored procedures.

      关系–我们基于存储过程建立它们。
    • Trees – built upon stored procedures too.

      树–也基于存储过程。

    Our cluster installation is classic for systems like these – one Master for writing and several Slaves with asynchronous replications for reading scaling.

    对于这样的系统,我们的集群安装是经典的-一个主服务器用于写入,而多个从服务器具有异步复制用于读取扩展。

    As a result, we have a fast scalable hybrid of relational and graph databases.

    结果,我们有了关系数据库和图形数据库的快速可扩展混合。

    One Tarantool instance is able to process thousands of reading requests, including those with active tree traversals.

    一个Tarantool实例能够处理成千上万的读取请求,包括那些具有活动树遍历的读取请求。

    选择用于存储设备数据的数据库 (Choosing the database for storing the data from the devices)

    Our requirements我们的要求

    This type of data is characterized by frequent writing and a large amount of data: millions of devices, several years of storage, petabytes of both incoming messages, and stored data. Its high availability is very important since the sensor readings are important for the user-defined rules and our internal services.

    这种类型的数据的特征在于频繁写入和大量数据:数百万个设备,数年的存储,传入消息的PB级和已存储的数据。 它的高可用性非常重要,因为传感器读数对于用户定义的规则和我们的内部服务非常重要。

    It is important that the database offers horizontal scaling for reading and writing, availability, and fault tolerance, as well as ready-made analytical tools for working with this data array, preferably SQL-based. We can sacrifice consistency and ACID transactions, so in terms of the CAP theorem, we need an AP system.

    重要的是,数据库必须提供用于读取和写入,可用性和容错能力的水平缩放,以及用于处理此数据数组(最好是基于SQL)的现成的分析工具。 我们可以牺牲一致性和ACID事务,因此就CAP定理而言,我们需要一个AP系统。

    Additional requirements. We had a few additional requirements for the solution that would store the gigantic amounts of data:其他要求。 对于存储大量数据的解决方案,我们还有一些其他要求:
    1. Time Series – sensor data that we wanted to store in a specialized base.

      时间序列–我们想要存储在专门基础中的传感器数据。
    2. Open-source – the advantages of open source code are self-explanatory.

      开源–开源代码的优势不言而喻。
    3. Free cluster – a common problem among modern databases.

      自由集群–现代数据库中的常见问题。
    4. Good compression – given the amount of data and its homogeneity, we wanted to compress the stored data efficiently.

      良好的压缩-考虑到数据量及其同质性,我们想有效地压缩存储的数据。
    5. Successful maintenance – in order to minimize risks, we wanted to start with a database that someone was already actively exploiting at loads similar to ours.

      成功的维护–为了最大程度地降低风险,我们希望从一个数据库开始,有人已经在以与我们类似的负载来积极利用数据库。
    Our solution. The only database suiting our requirements was ClickHouse – a columnar time-series database with replication, multi-master, sharding, SQL support, and a free cluster. Moreover, Mail.ru has many years of successful experience in operating one of the largest ClickHouse clusters.我们的解决方案。 满足我们要求的唯一数据库是ClickHouse,它是具有复制,多主数据库,分片,SQL支持和免费集群的柱状时序数据库。 此外,Mail.ru在运营最大的ClickHouse集群之一方面拥有多年的成功经验。

    But ClickHouse, however good it may be, didn’t work for us.

    但是ClickHouse不管它有多好,对我们都不起作用。

    设备数据数据库的问题及其解决方案 (Problems with the database for device data and their solution)

    Problem with writing performance. We immediately had a problem with the large data stream writing performance. It needs to be delivered to the analytical database as soon as possible so that the rules analyzing the flow of events in real-time can look at the history of a particular device and decide whether to raise an alert or not.书写性能问题。 我们立即就大数据流写入性能遇到了问题。 它需要尽快传送到分析数据库,以便实时分析事件流的规则可以查看特定设备的历史记录,并决定是否发出警报。 Solution. ClickHouse is not good with multiple single inserts, but works well with large packets of data, easily coping with writing millions of lines in batches. We decided to buffer the incoming data stream, and then paste this data in batches.解。 ClickHouse不能用于多个单个插入,但是可以处理大数据包,轻松应对成批写入数百万行的问题。 我们决定缓冲传入的数据流,然后分批粘贴此数据。
    This is how we dealt with poor writing performance这就是我们应对不良写作表现的方式

    The writing problems were solved, but it cost us several seconds of lag between the data coming into the system and its appearance in our database.

    解决了书写问题,但是这使我们花了几秒钟的时间才能将数据输入到系统中,以及它出现在数据库中的时间。

    This is critical for various algorithms that react to the sensor readings in real-time.

    这对于实时响应传感器读数的各种算法至关重要。

    Problem with reading performance. Stream analytics for real-time data processing constantly needs information from the database – tens of thousands of small queries. On average, one ClickHouse node handles about a hundred analytical queries at any time. It was created to infrequently process heavy analytical queries with large amounts of data. Of course, this is not suitable for calculating trends in the data stream from hundreds of thousands of sensors.阅读性能有问题。 用于实时数据处理的流分析不断需要来自数据库的信息-成千上万的小查询。 平均而言,一个ClickHouse节点可以随时处理大约一百个分析查询。 它的创建是为了不经常处理具有大量数据的繁重分析查询。 当然,这不适用于计算来自成千上万个传感器的数据流的趋势。
    ClickHouse doesn’t handle a large number of queries wellClickHouse不能很好地处理大量查询 Solution. We decided to place a cache in front of Clickhouse. The cache was meant to store the hot data that has been requested in the last 24 hours most often.解。 我们决定在Clickhouse前面放置一个缓存。 缓存旨在存储最近24小时内最频繁请求的热数据。

    24 hours of data is not a year but still quite a lot – so we need an AP system with horizontal scaling for reading and writing and a focus on performance while writing single events and numerous readings. We also need high availability, analytic tools for time series, persistence, and built-in TTL.

    24小时的数据不是一年,而是相当长的时间–因此,我们需要一个具有水平缩放功能的AP系统来读写,并在编写单个事件和大量读数时注重性能。 我们还需要高可用性,用于时间序列,持久性和内置TTL的分析工具。

    So, we needed a fast ClickHouse that could store everything in memory. Being unable to find any suitable solutions, we decided to build one based on the Tarantool primitives:

    因此,我们需要一个可以将所有内容存储在内存中的快速ClickHouse。 由于找不到合适的解决方案,我们决定基于Tarantool原语构建一个解决方案:

    1. Persistence – check (WAL-logs + snapshots).

      持久性–检查(WAL日志+快照)。
    2. Performance – check; all the data is in the memory.

      性能–检查; 所有数据都在内存中。
    3. Scaling – check; replication + sharding.

      缩放-检查; 复制+分片。
    4. High availability – check.

      高可用性–检查。
    5. Analytics tools for time series (grouping, aggregation, etc.) – we built them upon stored procedures.

      时间序列(分组,汇总等)的分析工具–我们在存储过程中构建了它们。
    6. TTL – built upon stored procedures with one background fiber (coroutine).

      TTL –基于具有一个背景光纤(协程)的存储过程而构建。

    The solution turned out to be powerful and easy to use. One instance handled 10,000 reading RPCs, including analytic ones.

    事实证明该解决方案功能强大且易于使用。 一个实例处理了10,000个正在读取的RPC,包括解析的RPC。

    Here is the architecture we came up with:

    这是我们想出的架构:

    Final architecture: ClickHouse as the analytic database and the Tarantool cache storing 24 hours of data.

    最终架构:ClickHouse作为分析数据库,而Tarantool缓存则存储24小时数据。

    一种新的数据类型-状态及其存储 (A new type of data – the state and it’s storing)

    We found a specific database for each type of data, but as the platform developed, another one appeared – the status. The status consists of current statuses of sensors and devices, as well as some global variables for stream analytics rules.

    我们为每种数据类型找到了一个特定的数据库,但是随着平台的发展,出现了另一个数据库-状态。 状态包括传感器和设备的当前状态,以及一些用于流分析规则的全局变量。

    Let’s say we have a lightbulb. The light may be either on or off, and we always need to have access to its current state, including one in the rules. Another example is a variable in stream rules – e.g., a counter of some sort.

    假设我们有一个灯泡。 指示灯可以打开或关闭,我们始终需要访问其当前状态,包括规则中的一种。 另一个示例是流规则中的变量-例如某种计数器。

    This type of data needs frequent writing and fast access but doesn’t take a lot of space.

    这种类型的数据需要频繁写入和快速访问,但不会占用太多空间。

    Metadata storage doesn’t suit this type of data well, because the status may change quite often and we only have one Master for writing. Durable and operating storage doesn’t work well too, because our status was last changed three years ago, and we need to have quick reading access.

    元数据存储不太适合此类数据,因为状态可能会经常更改,而且我们只有一个Master可以写。 持久和可操作的存储也无法正常工作,因为我们的状态在三年前更改过,我们需要具有快速读取权限。

    This means that the status database needs to have horizontal scaling for reading and writing, high availability, fault tolerance, and consistency on the values/documents level. We can sacrifice global consistency and ACID transactions.

    这意味着状态数据库需要具有用于读写的水平缩放,高可用性,容错能力以及值/文档级别的一致性。 我们可以牺牲全球一致性和ACID交易。

    Any Key-Value or a document database should work: Redis sharding cluster, MongoDB, or, once again, Tarantool.

    任何键值或文档数据库都应该起作用:Redis分片集群,MongoDB或再次是Tarantool。

    Tarantool advantages:

    Tarantool的优势:

    1. It is the most popular way of using Tarantool.

      这是使用Tarantool的最流行的方式。
    2. Horizontal scaling – check; asynchronous replication + sharding.

      水平缩放–检查; 异步复制+分片。
    3. Consistency on the document level – check.

      文档级别的一致性–检查。

    As a result, we have three Tarantools that are used differently: one for storing metadata, a cache for quick reading from the devices, and one for storing status data.

    因此,我们有三种不同使用的Tarantools:一种用于存储元数据,一种用于从设备快速读取的缓存,以及一种用于存储状态数据的缓存。

    如何为您的物联网平台选择数据库 (How to choose a database for your IoT platform)

    1. There is no such thing as a universal database.

      没有通用数据库。
    2. Each type of data should have its own database, the one most suitable.

      每种类型的数据都应该有自己的数据库,这是最合适的。
    3. There is a chance you may not find a fitting database in the market.

      您有可能在市场上找不到合适的数据库。
    4. Tarantool can work as a basis for a specialized database

      Tarantool可以作为专门数据库的基础

    翻译自: https://habr.com/en/company/mailru/blog/514766/

    展开全文
  • 工业物联网的价值发现以及解决方案通用模型
  • IIOT文献调研

    2020-08-16 08:25:44
    我们提出了一种告警流量的无授权随机接入方案,以及一种导频冲突解决算法,该算法在有效利用导频资源的同时保证了告警的传递。 我们提出了如何为警报流量分配导频信号以确保传递的一般问题,同时还使为警报保留
  • 工业物联网(IIoT)的主要挑战之一是设备无法在传统的安全环境中长期部署。由于IIoT端点设备暴露在外部环境,其...这些安全挑战由于不同安全解决方案之间缺乏结合力而不断加剧。企业通常会组织一个设备部门和一个...
  • 工业通信及联网领域 Moxa 正式发布预装微软 Azure IoT Edge 的工业互联网 (IIoT) 边缘网关,为微软 Azure 用户提供简单易用的解决方案,帮助他们在工业应用中扩展 IT 基础设施、实现 OT 数据互联。为促进 OT 与 IT ...
  • NI智能嵌入式系统加速工业物联网(IIOT)创新应用zip,包含物联网工程解决方案、工业物联网展望、从测试测量到用于工业互联网的智能嵌入式系统、专注于创新,而非集成等资源包。
  • 无线传输技术众所周知的,但是发射机的设计、位置、效率最大化以及验证整个系统的工况都是复杂的挑战,需要使用复杂的工程解决方案。布线不可避免的成本不仅增加了IIoT和工业4.0的壁垒,也增加了智能电网和智能城市...
  • 物联网,尤其是工业物联网 (IIoT),不仅要在很多业务部门之间产生变革性的影响,还要为嵌入式 IIoT 解决方案的开发带来根本性的转变。很多负责此类项目的工程师选择市售的单板计算机 (SBC) 作为设计的基础。
  • 霍尼韦尔与美国福斯公司近日宣布,两家公司将携手为用户提供工业物联网 (IIoT) 解决方案,帮助它们实现更加安全、高效及可靠的运营。这项合作将成为霍尼韦尔INspireTM项目的一部分,该项目是霍尼韦尔为其工业物联网...
  • 美国休斯顿,2016年11月21日讯 – 霍尼韦尔(纽约证券交易所代码:HON)与美国福斯公司近日宣布,两家公司将携手为用户提供工业物联网 (IIoT) 解决方案,帮助它们实现更加安全、高效及可靠的运营。这项合作将成为...
  • 工业物联网(IIoT)通过利用来自多个来源的实时数据来创建更智能的应用程序和系统。这需要语法上的互操作性-以可发现且明确的方式交换结构化数据的能力。它是构建IIoT组件和系统的连接基础架构的最低要求。 工业...
  • 包含物联网工程解决方案、工业物联网展望、从测试测量到用于工业互联网的智能嵌入式系统、专注于创新,而非集成等资源包。
  • 应用于工业4.0中的WSN技术及无线通信解决方案 将控制系统中的数据与物联网节点所获取的数据进行融合,可以提供更全面的数据集,使用户能够优化其整个价值链。例如,了解工厂关键设备的运行状态有助于预测问题可能...
  • 在工业物联网(IIoT)时代,OPC/OPC UA作为一种统一的通信架构,解决了互通性和标准性的问题。OPCClassic的访问规范都是基于微软的COM/DCOM技术,这会给新增层面的通信带来不可根除的弱点。本文概述了目前使用DCOM时...
  • 工业物联网由大量相连的工业系统所组成,这些系统会相互通讯,并协调数据分析与行动,有助于提升工业效能、有利于整个...目前各种系统,正在结合巨量模拟数据,解决方案,希望大家能透过资料与分析取得更深入的知识。
  • 波士顿--(美国商业资讯)--PTC (NASDAQ: PTC)今天发布了其屡获殊荣的工业物联网(IIoT)解决方案平台ThingWorx®的新版本。ThingWorx 8.4增加了多项新功能,包括旨在简化重要运营数据的收集、汇总和交付方式以提高工厂...
  • 随着软件开发超越网络应用,扩展到工业物联网(IIoT)设备,静态应用安全测试(SAST)变得更加必要,以从根本上确保软件的功能安全。根据Forrester Research的数据,Web攻击是2020年安全漏洞的主要来源。随之而来的是,...
  • 传统的数据收集方法,如SCADA,在这种方法中,被动传感器将原始数据传输回中央控制器,预计将会给IIoT解决方案提供更快速的响应时间、高效的数据收集能力和大数据服务,如预测性维护和自治系统自优化。  将数据...
  • 物联网,特别是物联网(IIoT),不仅对许多商业领域产生了革命性的影响,而且也为实现嵌入式IIoT解决方案开发的方式带来了根本性的转变。许多工程师面临这样的项目,他们选择了一个商业上可用的单板计算机(SBC)作为...
  • 工业物联网(IIoT)提供具有感应,处理和联网功能的智能基础架构和超连接设备。这些系统将产生惊人的数据量,共享同一网络。因此,有必要确保实时和关键任务消息在延迟和可靠性的严格限制内传输,而与其他网络流量...
  • 随之而来的是,IIoT和连接设备的扩展正在增加从医疗到汽车的每个行业的安全关键系统的攻击面。 由于SAST提供了大量的静态分析结果,开发团队必须在其创建的信息山中进行筛选,以找到有意义的数据。一旦发现缺陷,...
  • 2.1 IO-Link无线的产生——基于工业需求,解决有线的痛点 随着工业物联网(IIoT)的发展,通信需求也在迅速变化。机器对机器(M2M)通信(如连接的机器人、仓库自动化和工厂处理机器)变得越来越普遍,这要求更高的可用性...
  • 维也纳 -- (美国商业资讯) -- 濎通科技是一家致力于智能电网和IIoT (工业物联网) 通信解决方案的世界级无晶圆厂半导体公司,于 11 月 6 日至 8 日在奥地利维也纳举行的 EUW 2018 展会上展示了新的 PLC + RF (电力线 ...
  • Sullivan工业自动化团队最新报告认为,数字解决方案对成长极其重要。加工和离散制造产业因须提升资本、资产和资源效率,正在进行构造转型。这些趋势正在推动工业物联网(IIoT)及工业4.0的成长。算法、云端、数据、...
  • 霍尼韦尔推出了新的边缘控制PLC,被定位为帮助用户利用IIoT功能的解决方案。该产品作为边缘设备,采用OPC UA等开放标准,并提供通用I / O和嵌入式网络安全技术,具有很多优势以应对未来控制器的发展趋势。IIoT正在...
  • 随着网关技术的不断发展,创新和高效的软件解决方案及IT架构在工业物联网系统架构中发挥着更为重要的作用。其中,一个关键的问题在于如何利用软件,IT和创新算法来部署网络解决方案,并使生产效率更高。 当它用于...

空空如也

空空如也

1 2 3 4
收藏数 62
精华内容 24
关键字:

iiot解决方案