Русский
Русский
English
Статистика
Реклама

Интернет вещей iot

Перевод Топ-10 инструментов IoT-разработки в 2020

01.11.2020 18:17:43 | Автор: admin


Интернет вещей (IoT) оказывает многостороннее влияние на нашу жизнь, начиная с ТВ, которое вы можете контролировать со смартфона и заканчивая умными часами, которые отслеживают выполняемые вами ежедневно упражнения. Это обширная сеть, которая связана со множеством различных гаджетов, имеющих встроенные датчики. IoT обеспечивает платформу для получения с этих устройств информации, а также общий язык для их взаимодействия. Эта технология позволяет эффективнее реализовывать проекты, а также помогает сэкономить деньги. Результаты обширного исследования показали, что на 2015 год число подключенных к этой сети устройств составляло 15,41 миллиарда, в 2020 году это число возросло до 26,66, а к 2025 ожидается превышение показателя аж в 75 миллиардов. Ну а поскольку область разработки IoT-инструментов растет, в ней появляется все больше различных приложений и решений.

Проекты для интернета вещей реализуются во многих сферах, включая здравоохранение, промышленность и бизнес. Существует бесчисленное количество решений для разработки в области IoT, поэтому нередко озадачивает выбор наиболее подходящего инструмента. Вас ждет краткий обзор 10 наиболее актуальных из них на случай, если вы соберетесь нанять IoT-разработчиков для построения IoT платформы или просто интересуетесь этим вопросом в иных целях.

Eclipse IoT


Eclipse IoT это один из наиболее полезных инструментов разработки для IoT. Он является продуктом совместных усилий нескольких организаций из разных отраслей. С его помощью можно создавать фреймворки, получать реализации с открытым исходным кодом, предоставлять сервисы, помогающие в использовании IoT-решений, а также создавать инструменты для самих разработчиков в этой области.

Он зарекомендовал себя как инструмент, предоставляющий высококачественные сервисы доступным и прогнозируемым образом. Это удивительное средство разработки, достоинства которого оценили уже очень многие.

IBM Watson


IBM Watson используется компаниями при внедрении искусственного интеллекта, оказываясь также полезным для тех, кто только начинает свой бизнес или работает в банковской, производственной и других сферах. С его помощью вы сможете предоставить клиентам индивидуальный опыт использования продукта, минимизировать риски и стимулировать инновации. В данном случае все сервисы предоставляются экспертами, что ускоряет работу и предоставляет гарантии надежности.

Это приложение позволит вам прогнозировать будущие изменения и вносить необходимые соответствующие корректировки. Помимо прочего данная платформа предоставляет услуги в области блокчейна и аналитики.

Arduino


Arduino является одним из популярных средств разработки для IoT. Он легок в использовании и позволяет настроить управление удобным вам способом. Микроконтроллеры Arduino проектируются для выполнения самых различных задач. На ввод этих устройств можно подавать информацию, управляя таким образом различными устройствами, а с помощью вывода можно отображать и сохранять данные, например на ПК. Кроме этого, данный инструмент также позволяет объединять несколько устройств и управлять ими удаленно.

Arduino может послужить очень полезным добавлением в ваши проекты, так как спектр его возможностей по истине огромен.

Node-Red


Это средство завоевывает все большую популярность в мире технологий и интернета вещей, в частности. Node-Red это очень гибкий и полезный визуальный редактор с открытым кодом, который позволяет разработчикам любого уровня налаживать взаимосвязь между облачными системами, базами данных, API и не только.

Работать он может в том числе и на низкобюджетных машинах, включая недорогие облачные решения и Raspberry Pi. Состоит данный инструмент из 225,000 модулей, что облегчает расширение палитры узлов для добавления новых возможностей. Node-Red разработан IBM, поэтому с помощью данного редактора можно создавать Java-функции, которые в итоге можно сохранять для последующего использования, также как шаблоны и потоки.

Particle


Эта платформа была запущена в 2013 году, предоставляя облегченное взаимодействие с IoT как разработчикам, так и бизнесменам. Кроме того, попав в число быстрорастущих инновационных компаний, она была отмечена в докладе Gartner среди передовых решений в сфере IoT.

Данная платформа характеризуется надежностью и защищенностью, позволяя программистам разрабатывать, подключать, объединять и администрировать IoT-решения быстро и без особых усилий. Многие инженеры из разных стран используют этот сервис для организации и управления разработкой IoT-продуктов.

Kaa


Kaa относится к числу наиболее гибких и расширяемых платформ, позволяющих как создавать IoT-решения, так и управлять подключенными устройствами. Она предлагает богатый набор возможностей, включая сбор и обработку данных, аналитику, управление конфигурацией, визуализацию данных и многое другое. Kaa поддерживает открытые протоколы IoT и обеспечивает полноценную безопасность пользовательской информации. Она дает вам полный контроль над устройствами, при этом вы можете выбирать удобный для вас вариант хостинга, будь то публичное облако или частные локальные серверы.

С ее помощью можно подключать и управлять устройствами, используя графический UPI или REST API. Кроме того, она проста в использовании и имеет высокую совместимость. Создатели Kaa, имея богатый опыт в этой области, вложили в нее возможность обслуживания всех известных сфер жизнедеятельности, включая различные корпорации и более мелкие стартапы.

ThingsBoard


Эта IoT-платформа поможет вам организовать для своих проектов сбор и обработку данных, управление устройствами и визуализацию. При ее использовании вывод продукта на рынок занимает минимум времени, а возможные технические сложности решаются очень эффективно. Она позволяет отслеживать тысячи и даже миллионы устройств, осуществляя взаимосвязь посредством таких протоколов как HTTP, MQTT и ряда других.

Используя ThingsBoard, вы можете мониторить стек технологий и свободно выбирать провайдеров облачных услуг. Этот сервис позволяет моделировать файлы проектов, настраивать устройства, а также получать на основе их данных нужную информацию, делая эти процессы более эффективными.

Blynk IoT Platform


Также весьма популярная IoT-платформа, отличающаяся рядом уникальных возможностей, таких как отображение, хранение и визуализация данных. С помощью библиотеки Blynk можно подключать более 400 моделей оборудования, организуя соединение через Wi-Fi, Ethernet, 2G, 3G, 4G, LTE и т.д. Вся платформа подразделяется на три главных компонента:

  • Приложение Blynk предоставляет виджеты, с помощью которых вы можете создавать интерфейсы для своих проектов.
  • Сервер Blynk позволяет управлять тысячами устройств, а также налаживать связь между оборудованием и смартфонами.
  • Библиотеки Blynk обеспечивают взаимодействие с сервером и обработку команд.

Это открытая платформа, способная работать в любой среде. Для нее характерна скорость, надежность, а также возможность обработки миллиардов информационных потоков и запросов, получаемых с устройств.

Device Hive


Device Hive тоже является открытым инструментом, помогающим подключать к вашему приложению устройства и добавлять в него объекты. Подключение устройств осуществляется через WebSocket, REST API или MQTT. Платформа поддерживает несколько языков программирования, что делает ее универсальной для всех устройств.

Помимо прочего, она предоставляет участникам возможность обсуждения разработки или бизнеса, а также предлагает многообещающие подходы к созданию ПО в коммерческих целях. Подключенные устройства можно контролировать без использования сети конфигурации. Вы также можете оперативно проводить аналитику удобным для вас способом, приобретая лучшие в мире решения для работы с данными.

ThingWorx


ThingWorx отличая платформа, с помощью которой как программисты, так и другие клиенты создают бесчисленные решения для интеллектуальных подключенных операций (smart connected operations) и продуктов в сфере медицины, промышленности и производства. Этот ресурс предоставляет ведущие в области IoT возможности для промышленных организаций, которые позволяют эффективнее использовать бизнес-модели и наращивать сам бизнес.

Вы можете с минимальными затратами использовать данные, получаемые от подключенных продуктов, повышая продуктивность и эффективность предприятия. ThingWorx дает возможность безопасно реализовывать сервисы, продукты и операции, являясь надежным и гибким средством, постоянно повышающим качество обслуживания своих клиентов.

Заключение


Интернет вещей (IoT) это одна из самых бурно развивающихся технологий в мире. Тем не менее с ростом конкуренции в этой среде становится сложно найти наиболее подходящие инструменты.

Выше я перечислила одни из лучших приложений для работы с IoT, а также платформы, на которых вы сможете получать желаемые результаты, ведущие к успешному расширению вашего бизнеса.

Вопрос-ответ


Что такое интернет вещей?


В своей основе это система, объединяющая физические устройства с интернетом, что позволяет пользователям собирать, отправлять и получать данные. Для сообщения подключенные устройства используют протоколы, так как их главная цель в повышении уровня взаимодействия M2M.

Какие есть выгоды в использовании интернета вещей?


К ним можно отнести очень многие, включая снижение стоимости, повышение эффективности, производительности, качества обслуживания, раскрытие новых бизнес-возможностей, минимизацию человеческих усилий и др.

Что такое M2M и какая нам от этого польза?


M2M это пример технологии, позволяющей двум и более устройствам взаимодействовать друг с другом как через проводное соединение, так и без него. Она позволяет перекладывать на машины особо сложные задачи, которые они автоматизируют, облегчая нам жизнь.

Что делает провайдер Iot-решений?


Такие провайдеры обрабатывают данные с устройств, собирая необходимую информацию, а также предлагают решения и приоритетные направления для проектирования IoT. Они занимаются обработкой таких IoT-составляющих, как устройства, сенсоры, безопасность и сети.



Подробнее..

Уязвимости IoT-систем на примере LoRaWAN

21.12.2020 18:22:45 | Автор: admin

В данной статье мы рассмотрим уязвимости IoT систем и 3 сценария атаки на устройства данного типа.

Но для начала стоит разобраться в терминах: что такое IoT? Что плохого может произойти из-за атаки на IoTустройства? Почему кибербезопасность сейчас так важна?

Интернет вещей (англ. internet of things, IoT) концепция сети передачи данных между физическими объектами (вещами), оснащёнными встроенными средствами и технологиями для взаимодействия друг с другом или с внешней средой.Wikipedia

Описать интернет вещей можно как обыкновенные вещи, подключенные к сети. IoTсистемы объединяются в огромные сети, позволяющие управлять собой для удобства (умные дома), для отслеживания перемещений (камеры в городе), для сбора данных о пользователях (вышки сотовой связи).

Давайте разберемся с безопасностью. Почему IoT устройства не защищены по максимуму? Дело в том, что и обществу и бизнесу выгодно производить быстрые устройства с широким покрытием. Безопасность передачи данных уходит на второй план из-за снижения скорости и удорожания более защищенных устройств. Нельзя обвинять в этом только огромные корпорации, желающие нам зла. Сами покупатели выбирают устройства подешевле, и не обеспечивают минимальную защиту собственным персональным данным. Специалисты компании Trustlook опубликовали данные по количеству клиентов, оставляющих предустановленный пароль на своем устройстве, взаимодействующему с сетью и подверженному кибератакам. (Исследование) Вспомните, меняли ли вы пароль от своего роутера? Если нет, может быть и вам следует задуматься о безопасности?

Почему же избегать кибератак так важно? Давайте я расскажу о 5 прецедентах, произошедших в последние 10 лет и вызвавших переполох:

1.Ботнет Mirai

Случай произошел в 2016 году, когда из-за DDoS атаки с помощью IoTустройств были положены сервера многих крупных компаний, включая Твиттер, Нетфликс, Реддит и некоторые крупные СМИ, включая газету The Guardian и CNN.

2.Взлом сердечных устройств St.JudeMedical

В начале 2019 года CNN подтвердили, что имплантируемые сердечные устройства St.JudeMedicalуязвимы к атакам хакеров. Получив доступ можно разрядить батарею устройства, ввести неправильный ритм или ударить током пользователя.

3.Взлом системы мониторинга сердца у детей

Сразу после новости о взломе сердечных устройств последовала новая: аппарат The Owlet WiFi Baby Heart Monitor, позволяющий отслеживать сердечный ритм младенцев, тоже подвержен атакам.

4.Взлом веб-камеры TRENDnet

Компания TRENDnet продавала свои камеры для различных целей. В своей рекламной кампании они сосредоточили внимание на безопасности детей, за которыми можно следить из дома. Как можно догадаться из посыла этой статьи, доступ к камерам имели не только счастливые родители, но любой пользователь интернета, знающий IP-адрес камеры.

5.Взлом Джипа

В июле 2015 года команда исследователей взяла под полный контроль джип, используя CAN-шину автомобиля. Они могли заставить автомобиль ускориться, замедлиться, повернуть. К счастью, уязвимость была устранена немедленно.


Успешные атаки могут привести к финансовым потерям (например, измененные показания счетчиков), опасности для людей (крушение поезда, машины, отказ датчиков сердца), кроме того, злоумышленник может использовать IoT устройства в качестве вычислительных ресурсов для другого вредоносного действия, как в случае DDoS атаки ботнета Mirai.

Давайте поговорим про уязвимости IoT-систем

Здесь я хотела бы сосредоточиться только на одном из видов IoT устройств: LP-WAN(Low-power Wide-area Network энергоэффективная сеть дальнего радиуса действия)устройствах.

LP-WAN устройства обладают огромным покрытием и использую самые маленькие батареи из возможных. Для этого они работают на низких частотах (т.к. скорость затухания увеличивается с частотой), используют низкие скорости передачи данных и методы, повышающие надежность передачи. Самые известные члены семьиLP-WAN устройств - Sigfox, LoRa-WANиNB-IoT. Мы рассмотрим атаки на системы типа LoRaWAN.

Существует 5 типов атак на LoRaWAN: повтор, подслушивание, модификация пакетов, подмена АСК и истощение батареи.

Все эти атаки могут совершатся на все части IoT-коммуникации: аппаратное обеспечение, signal intelligence, помехи и ключи безопасности.

1.Угрозы физической безопасности

Если хакер смог получить доступ к какой-либо физической части IoT системы, будь то сетевой узел, шлюз или сервер, все устройство или даже вся сеть считаются скомпрометированными. Если захвачен сетевой узел или шлюз, все ключи безопасности возможно достать и переиспользовать, любое сообщение может быть перехвачено, а поддельное сообщение отправлено как настоящее. Если же захвачен сервер, вся система считается скомпрометированной. При потере ключей безопасности нарушается конфиденциальность и целостность устройства.

2.Угрозы РЭР (Signal Intelligence)

Протоколы, не предполагающие шифрования, могут быть легко перехвачены, что позволит хакеру прочитать payloadприложения.Злоумышленник может проанализировать изменения байтов при каждой передаче и определить, как выглядит нужный ему payload. Из-за конечного числа возможных структур данных и небольшого размера нагрузки в системах типа LP-WAN, задача становится легко выполнимой. Рассмотри пример отправки сообщения при открытии/закрытии двери. Узел передает сообщение только при изменении состояния, но даже если информация зашифрована, эти сообщения отправляются только при наличии триггера, и позволяют мошеннику узнать, когда эти триггеры сработали, а значит, определить, например, когда пользователь покинул дом.

3.Помехи

Т.к. изначально LP-WAN технологии обладают большим

охватом, широким каналом связи и несколькими шлюзами, принимающими сообщения, вызвать помехи в передаче данных может быть непросто. Но здесь нужно уточнить один немаловажный факт: пропускная способность связи этих устройств невелика. Для LoRaWAN она составляет всего лишь 125/250/500кГЦ. Еще они используют низкую мощность для передачи, поэтому устройство глушителя не обязано быть супер-сложным, пока оно посылает сигнал с достаточно высокой мощностью.

Атаки могут быть нацелены на разные уровни модели OSI:

а) Помехи физического уровня, когда злоумышленник посылает любой широкополосный сигнал с более высоким отношением сигнал/шум, чем жертва;

б) Помехи МАС-уровня, когда злоумышленник глушит только определенные части сообщения, гарантируя, что пакет будет отброшен получателем.

Как можно защититься от такого типа атак? Именно защищаться довольно сложно, так как такого рода атаки возможны всегда, но можно повысить стабильность системы, увеличив количество шлюзов.

4.Угрозы ключам безопасности

Всегда необходимо учитывать размер ключей безопасности и их криптопериод. Сейчас достаточно размера ключа в 128 бит, но эта цифра может сильно измениться в ближайшие годы. 10 лет сейчас являются предполагаемым сроком службы устройства LP-WAN. Национальный институт рекомендует криптопериод менее 5 лет для каждого типа ключа, чего будет трудно достичь для технологий, не позволяющих удаленно менять мастер-ключ.

Что же можем сделать мы, как пользователи?

Во-первых, ни в коем случае не использовать предустановленные пароли на таких устройствах, как роутеры.

Во-вторых, постараться максимально обеспечить физическую неприкасаемость к предметам, по которым можно отследить ваше местонахождение.

В-третьих, не экономить на покупке защищенных устройств: лучше потратить больше, но потом не потерять ни гроша из-за действий мошенников.

В-четвертых, использовать защищенные протоколы.


Безопасность - важная часть нашей жизни, но к сожалению, многие этого не понимают. Мы расплачиваемся за посещение сайтов в интернете не деньгами, но собственными персональными данными. Мы предпочитаем покупать устройства дешевле, но плохо защищенные. И мы слишком часто считаем себя умнее всех.

Только в первом полугодии 2020 года было зафиксировано 105 млн. атак на IoT-устройства.

Будьте осторожны, мойте руки с мылом!

Подробнее..

Edge платформа промышленного интернета вещей I-IoT

05.07.2020 16:17:42 | Автор: admin

Что такое I-IoT


После появления парового двигателя в 1760 году пар использовался для снабжения энергией всего, от сельского хозяйства до текстильного производства. Это вызвало Первую промышленную революцию и эпоху механического производства. В конце 19-го века пришли электричество, новые способы организации труда и массовое производство, что положило начало Второй промышленной революции. Во второй половине 20-го века разработка полупроводников и внедрение электронных контроллеров дали начало эпохе автоматизации и Третьей промышленной революции. На Ганноверской выставке 2011 года Хеннинг Кагерманн, Вольф-Дитер Лукас и Вольфганг Вальстер ввели термин Industry 4.0 для проекта обновления немецкой производственной системы с использованием возможностей новейших цифровых технологий.

image



Ожидается, что Industry 4.0 сможет воплотить следующее:

  • Объединить производство с информационными и коммуникационными технологиями
  • Объединить данные клиента с производственными данными
  • Максимально использовать возможности межмашинного взаимодействия
  • Управлять производством автономно, гибко и эффективно сохраняя ресурсы

Основатель и президент Всемирного экономического форума Клаус Шваб считает, что самостоятельность четвёртой промышленной революции можно обосновать тремя факторами.

  • Темпы развития. В отличие от предыдущих, эта промышленная революция развивается не линейными, а скорее экспоненциальными темпами. Это является порождением многогранного, глубоко взаимозависимого мира, в котором мы живем, а также того факта, что новая технология сама синтезирует все более передовые и эффективные технологии.
  • Широта и глубина. Она основана на цифровой революции и сочетает разнообразные технологии, обусловливающие возникновение беспрецедентных изменений парадигм в экономике, бизнесе, социуме в каждой отдельной личности. Она изменяет не только то, что и как мы делаем, но и то, кем мы являемся.
  • Системное воздействие. Она предусматривает целостные внешние и внутренние преобразования всех систем по всем странам, компаниям, отраслям и обществу в целом.

По определению, IoT это ключ к дальнейшему развитию промышленности, включая такие технологии, как анализ больших данных, облачные технологии, робототехника и, что наиболее важно, интеграция и конвергенция между ИТ и производством.
Термин I-IoT (Industrial internet of Things) относится к промышленному подмножеству IoT, представляющему собой цифровую трансформацию естественного бизнеса. I-IoT делает бизнес более гибким, более выгодным, понятным и создает новые цифровые цепочки ценности. Традиционные производственные цепочки это понятные последовательные этапы, например: разработка продукции, получение и поставка источников сырья, производство и обслуживание продукции. Суть новой цифровой трансформации в том, что вокруг некого цифрового ядра создается сервисная экосистема и новые бизнес-модели, придающие новые качества производству. Такие как снижение издержек между различными этапами подготовки производства, наладки и эксплуатации. Связи между различными департаментами и этапами становятся более быстрыми, что дает возможность работать более эффективнее и конкурентнее на рынке.

image

Ожидается, что I-IoT создаст большую ценность для бизнеса и окажет такое глубокое влияние на человеческое общество, что он введет Четвертую промышленную революцию.
Согласно Forbes:

  • Мировой рынок IoT вырастет с 157 млрд долларов в 2016 году до 457 долларов к 2020 году, достигнув годового темпа роста 28,5%
  • Производство, транспорт и логистика, а также коммунальные услуги приведут все отрасли к расходам на IoT к 2020 году, в среднем по 40 миллиардов долларов каждая.


IoT и I-IoT сходства и различия


  • Кибербезопасность является критически важной темой для любого цифрового решения, но его внедрение в промышленном мире требует особого внимания. Это связано с тем, что системы и устройства в промышленности имеют гораздо более длительный жизненный цикл и часто основаны на устаревших технологиях, которые не предназначены для подключения через Интернет. Часто они содержаться в изолированной локальной сети, защищенной от внешнего мира.
  • Очень важно, чтобы промышленные цифровые устройства продолжали работать, не смотря на кратковременные сбои в питании или сети; любое временное отключение может привести к большим экономическим потерям.
  • Решения I-IoT должны сосуществовать в среде со значительным количеством устройств и систем, выступающими в качестве источников данных.
  • Промышленные сети это специализированные и детерминированные сети, поддерживающие десятки тысяч контроллеров, роботов и машин. Поэтому решения I-IoT, развернутые в этих сетях, должны беспрепятственно масштабировать десятки тысяч датчиков и устройств.
  • Физические объекты в индустриальном мире являются более сложными и имеют более широкий спектр типов по сравнению с бытовым потреблением.
  • В промышленном мире надежность, устойчивость и доступность являются ключевыми факторы. Юзабилити и пользовательский опыт, однако, не так актуальны, как в мире потребителей.
  • Промышленные системы часто перепрограммируются и реконфигурируются для поддержки новых процессов. Решения I-IoT должны поддерживать и обеспечивать одинаковую гибкость и адаптивность в условиях эксплуатации.
  • Интеллектуальная собственность является важной темой в индустриальном мире, часто является коммерческой тайной и защищена патентом.


Понятие производственного процесса и промышленных устройств


CIM (computer-integrated manufacturing) это логическая модель для производственных систем, разработанная в 1990-х годах для интеграции производственных процессов, систем автоматизации и систем информационных технологий на уровне компании или предприятия. CIM не следует рассматривать как метод проектирования для создания автоматизированных фабрик, а скорее как эталонную модель для внедрения промышленной автоматизации, основанную на сборе, координации, совместном использовании и передаче данных и информации между различными системами и подсистемами посредством средства программных приложений и сетей связи. Модель CIM часто изображается в виде пирамиды, состоящей из шести функциональных уровней, как показано на следующей диаграмме

image

Уровень 1 датчики, преобразователи и исполнительный механизм


Электронный датчик конструктивно законченное средство измерения, способное преобразовывать одну или несколько физических величин в электрический сигнал для последующих преобразований, передачи, обработки и отображения измерительной информации. Исполнительный механизм (актуатор) это устройство, которое преобразует управляющую команду в физическое воздействие на процесс. По сути, его функция дополняет функцию датчика. Актуатор принимает управляющий сигнал в качестве входа в системе управления и передает энергию в качестве выхода в механизме.

Уровень 2 RTU, микроконтроллеры, CNC, PLC и DCS


  • Удаленный терминал (Remote terminal unit RTU) это электронное устройство, управляемое микропроцессором. Он служит интерфейсом для датчиков, исполнительных механизмов и интеллектуальных устройств, передавая данные и получая командные сообщения от главной системы. Он в основном используется для централизации ввода и вывода от датчиков и исполнительных механизмов, уменьшая сложность кабельной проводки.
  • Микроконтроллер (Embedded controller), как правило, представляет собой один чип или плату, которая включает в себя все необходимые компоненты для выполнения необходимых задач управления. Они обычно предназначены для конкретного применения и построены на основе определенной архитектуре выбранного производителя.
  • Контроллеры с числовым программным управлением ЧПУ (CNC) электронное устройство, предназначенное для управления станками. Движения и функции станков с ЧПУ предопределены и устанавливаются с помощью специального программного обеспечения. Они используются для выполнения высокоточной обработки, которая требует длительного времени без какого-либо взаимодействия с внешней средой.
  • PLC это промышленный контроллер, предназначенный для управления производственными процессами. PLC выполняет программу циклически, обрабатывая сигналы, поступающие в качестве входных сигналов от датчиков и переключателей, и отправляя выходные значения в исполнительные механизмы для управления физическим процессом. Чтение входных данных, их обработка, а также запись выходных данных происходит в течение предварительно определенного максимального времени, называемого циклом сканирования. Обычно это занимает от 10 до 100 миллисекунд.
  • DCS обычно используются в непрерывных процессах, таких как нефтеперерабатывающие, энергетические или химические заводы. Они объединяют как функцию управления, реализованную в PLC, так и функцию системы диспетчерского контроля (SCADA). В то время как PLC и SCADA являются двумя отдельными системами, каждая из которых имеет свои собственные адресные пространства, в DCS эти системы используют одни и те же переменные и структуры данных


Уровень 3 SCADA, Historian


Система SCADA представляет собой программный пакет для выполнения функций сбора, обработки, отображения и архивирования информации об объекте мониторинга или управления в реальном времени. Система сбора данных (Historian) позволяет собирать в режиме реального времени информацию о рабочем состоянии оборудования. Система SCADA реализует следующие основные функции:
  • Получает данные и информацию от PLC, состояние датчиков, RTU и других устройств, расположенных на нижних уровнях пирамиды CIM.
  • Обрабатывает собранные данные, сохраняя наиболее актуальную информацию.
  • Обнаруживает аварийные ситуации, формируя сигналы тревоги, которые передаются операторам.
  • Предоставляет информацию операторам в диспетчерской через человеко-машинный интерфейс (HMI).
  • С помощью HMI оператор контролирует производственные процессы и посылает необходимые команды в PLC.


Уровень 4 -MES


MES это программная система, расположенная между ERP и SCADA или PLC, предназначенная для эффективного управления производственным процессом компании. Основная функция MES заключается в синхронизации управления бизнесом и производственной системой путем объединения уровней планирования и контроля для оптимизации процессов и ресурсов.
Основными особенностями системы MES являются:
  • Управление заказами и планирование производства
  • Управление поступающим сырьем и полуфабрикатами
  • Управление активами и мониторинг
  • Отслеживание производства
  • Управление техобслуживанием
  • Проверка качества


Уровень 5 ERP


ERP включает в себя пакеты программного обеспечения, которые организация используют для управления повседневной деятельностью своего бизнеса, такого как учет, закупки, управление проектами и производство. ERP объединяет и определяют набор бизнес-процессов, регулирующих обмен информацией и данными между задействованными системами. ERP собирает и передает данные о транзакциях, поступающие из разных отделов организации, обеспечивая тем самым целостность данных, выступая в качестве единого источника.

Производственные сети


В интегрированной производственной системе требуются различные типы сетей связи, каждая из которых предназначена для определенных задач
  • Уровень 1: полевая шина
  • Уровень 2: сеть котроллеров
  • Уровень 3, 4, 5: корпоративная сеть

Полевые сети были введены для сопряжения контроллеров, датчиков и исполнительных механизмов, уменьшая потребность в сложной проводке. В полевой шине датчики и исполнительные механизмы оснащены минимальным набором обработки, чтобы обеспечить передачу информации детерминированным способом.
Сеть котроллеров должна обеспечивать связь между узлами PLC. Передача данных должна происходить в определенные интервалы времени. Сети управления и полевые шины также часто называют сетями реального времени за счет определенных временных промежутков при передаче данных и информации.
Корпоративная сеть это сеть, расположенная между системами управления и системами планирования и менеджмента. Этот уровень сети должен гарантировать обработку сложной информации, но в меньших промежутках времени. Поэтому нет необходимости в жестких временных рамках для этого уровня сети.

OPC сервер


Ни один другой стандарт промышленных коммуникаций не получил такого широкого признания среди многих отраслей и производителей оборудования, как OPC. Он используется для объединения большого разнообразия промышленных и бизнес-систем. SCADA, системы обеспечения безопасности (SIS), программируемые логические контроллеры (PLC) и распределенные системы управления (DCS) используют OPC для обмена данными друг с другом, а также с базами данных Historian, MES и ERP-системами. Причина успеха OPC очень проста это единственный действительно универсальный интерфейс, который можно использовать для связи с различными промышленными устройствами и приложениями, независимо от производителя, программного обеспечения или протоколов, используемых в системе управления. После появления стандарта ОРС практически все SCADA были перепроектированы как ОРС-клиенты, а каждый производитель аппаратного обеспечения стал снабжать свои контроллеры, модули ввода-вывода, интеллектуальные датчики и исполнительные устройства стандартным ОРС сервером.

OPC classic (Data access DA)


В 1995 году различные компании решили создать рабочую группу для определения стандарта взаимодействия. Этими компаниями были следующие: Fisher Rosemount, Intellution, Intuitive Technology, Opto22, Rockwell, Siemens AG.
Члены Microsoft также были приглашены для оказания необходимой поддержки. Задача рабочей группы состояла в том, чтобы определить стандарт доступа к информации в среде Windows на основе современных технологий того времени. Разработанная технология была названа Object Linking and Embedding (OLE) for Process Control (OPC). В августе 1996 года была определена первая версия OPC. На следующей диаграмме показаны различные уровни OPC Classic с основными протоколами связи COM, DCOM и удаленный вызов процедур (RPC):

image

COM это программная архитектура, разработанная Microsoft для создания компонентных приложений. В то время это позволяло программистам инкапсулировать повторно используемые фрагменты кода таким образом, чтобы другие приложения могли использовать их, не беспокоясь о деталях своей реализации. COM-объекты могут быть заменены более новыми версиями, без необходимости переписывать приложения, которые их используют. DCOM это сетевые версии COM. DCOM пытается скрыть от разработчиков программного обеспечения различия между COM-объектами, работающими на одном компьютере, и COM-объектами, работающими удаленно на другом компьютере. Для этого все параметры должны быть переданы по значению. Это означает, что при вызове функции, предоставляемой объектом COM, вызывающая сторона должна передать связанные параметры по значению. С другой стороны, COM-объект будет отвечать вызывающей стороне, передавая результаты также по значению. Процесс преобразования параметров в данные, передаваемые по сети, называется маршалинг (marshalling). После завершения маршалинга поток данных сериализуется, передается и восстанавливается в исходном порядке данных на другом конце соединения.
DCOM используют механизм RPC для прозрачной передачи и получения информации между COM-компонентами в одной сети. Механизм RPC был разработан Microsoft, чтобы позволить разработчикам системы запрашивать выполнение удаленных программ без необходимости разработки специальных процедур для сервера. Клиентская программа отправляет на сервер сообщение с надлежащими аргументами, а сервер возвращает сообщение, содержащее результаты, полученные из выполненной программы.

OPC Classic содержит ряд ограничений:
  • доступность только на операционных системах семейства Microsoft Windows;
  • связь c технологией DCOM, исходные коды которой являются закрытыми.
  • проблемы конфигурирования, связанные с DCOM;
  • неточные сообщения DCOM о прерываниях связи;
  • неприспособленность DCOM для обмена данными через интернет;
  • неприспособленность DCOM для обеспечения информационной безопасности.


Модель получения данных в OPC Classic


Цели стандарта OPC Classic заключаются в следующем:
  • Структурировать данные на стороне сервера, чтобы упростить сбор данных на стороне клиента.
  • Определить коммуникационные сервисы и стандартные механизмы обмена данными

По сути, стандарт OPC Classic работает следующим образом:
Сервер управляет всеми доступными данными.
Сервер отправляет запросы на данные, поступающие от устройств по требованию, и регулярно обновляет внутренний кэш. Сервер инициализирует и управляет кэшем для каждой группы переменных, запрошенных клиентом OPC. Частота сканирования на стороне клиента OPC не может быть меньше частоты сканирования OPC сервера для сбора данных с устройств и обновления своего внутреннего кэша. Рекомендуется настроить клиент OPC для чтения из кэша и его на обновление с удвоенной скоростью, по сравнению с которой сервер OPC сканирует устройства. Каждая часть обмениваемых данных имеет свое значение, обозначенное своей отметкой времени и качеством. Обмен данными включает в себя чтение, запись и автоматическое обновление при изменении значений. Чтение или опрос выполняется OPC-клиентом, который регулярно отправляет запросы на данные группы. Этап записи может быть синхронным или асинхронным. Автоматические обновления использует частоту запросов, предоставленную клиентом OPC. Сервер OPC для каждого обновления проверяет, больше ли абсолютное значение кэшированного значения минус текущее значение, чем мертвая зона, указанная клиентом, умноженная на диапазон, настроенный для этой переменной. Это можно записать следующим образом:
if (abs(last_cached_value  current_value) > (PERCENT_DEAD_BAND/100) * range) {//cache is updated, and the client is notified through a callback mechanism }


Информация с сервера OPC организована в группы связанных элементов для повышения эффективности. Есть два разных типа групп:

  • Public groups: доступны для любого клиента
  • Local groups: доступны только клиенту, который их создал


OPC UA


Первым ответом OPC Foundation на растущие ограничения, связанные с принятием архитектуры COM и DCOM, стала разработка OPC XML-DA. Это сохранило характеристики OPC, но приняло коммуникационную инфраструктуру, которая не связана ни с производителем, ни с конкретной программной платформой. Преобразование спецификаций OPC-DA в версии на основе веб-сервисов оказалось недостаточным для удовлетворения потребностей предприятий, которые все больше взаимодействуют и интегрируются с корпоративным и внешним миром.
Информация об архитектуре OPC UA представлена на сайте opcfoundation.org/developer-tools/specifications-unified-architecture
Поэтому был разработан протокол OPC UA с целью заменить все существующие версии на основе COM и преодолеть проблемы безопасности и производительности. Стандарт удовлетворяет потребность в независимых от платформы интерфейсах и позволяет создавать расширяемые модели данных для описания сложных систем без потери функциональности. OPC UA основан на сервис-ориентированном подходе, определенном стандартом IEC 62451. Он преследует следующие цели:

  • Использование компонентов OPC на платформах, отличных от Windows
  • Позволяет встроить его основные компоненты в небольшие устройства
  • Реализует стандартное взаимодействия через системы на основе файрвола

С технической точки зрения OPC UA работает следующим образом:

  • API изолирует код клиента и сервера от стека OPC UA
  • Стек UA преобразует вызовы API в сообщения
  • Стек UA получает сообщения, отправляя их клиенту или серверу через API


image

Информационная модель OPC UA


Основные принципы информационного моделирования в OPC UA:

  • Использование объектно-ориентированных методов, включая иерархию наследования.
  • Тот же механизм используется для доступа к типам и экземплярам.
  • Информация становится доступной благодаря использованию полностью связанных узлов в сети.
  • Иерархии типов данных и связи между узлами являются расширяемыми.
  • Нет ограничений на то, как моделировать информацию.
  • Информационное моделирование всегда размещается на стороне сервера.

Набор объектов и связанной информации, которую сервер OPC UA делает доступным для клиентов, является адресным пространством. Можно рассматривать адресное пространство как реализацию информационной модели OPC UA.
Адресное пространство OPC UA это набор узлов, которые связаны ссылками. Каждый узел имеет свойства, которые называются атрибутами. Определенный набор атрибутов должен существовать во всех узлах. Связь между узлами, атрибутами и ссылками показана на следующей диаграмме

image

Узлы могут принадлежать к разным классам узлов, в зависимости от их конкретной цели. Некоторые узлы могут представлять экземпляры, другие могут представлять типы и т. д. В OPC UA есть восемь стандартных классов узлов: variable, object, method, view, data type, variable type, object type, и reference type. В OPC UA наиболее важными классами узлов являются объект, переменная и метод

OPC UA сессии


OPC UA предоставляет модель связи клиент-сервер, которая включает информацию о состоянии. Эта информация о состоянии связана с сессией. Сессия определяется как логическое соединение между клиентом и сервером. Каждый сессия не зависит от базового протокола связи; любые проблемы, возникающие на уровне протокола, не приводят к автоматическому завершению сессии. Сессия заканчивается после явного запроса от клиента или из-за бездействия клиента. Интервалы бездействия устанавливаются во время создания сеанса.

Модель безопасности OPC UA


Модель безопасности OPC UA реализована посредством определения безопасного канала, на котором основан сеанс. Безопасный канал осуществляет обмен данными следующим образом:
  • Обеспечивает целостность данных с использованием цифровых подписей.
  • Обеспечивает конфиденциальность посредством шифрования.
  • Выполняет аутентификацию и авторизацию приложений с использованием сертификатов X.509.

На рисунке показаны следующие уровни: прикладной уровень, сеансовый и транспортный уровень:
Уровень приложений используется для передачи информации между клиентами и серверами, которые установили сеанс OPC UA. Сеанс OPC UA устанавливается на защищенном канале. Транспортный уровень это уровень, отвечающий за передачу и прием данных через сокетное соединение, к которому применяются механизмы обработки ошибок, чтобы гарантировать защиту системы от таких атак, как denial-of-service (DoS)

image

Обмен данными OPC UA


Самый простой способ обмена данными между клиентом OPC UA и сервером использовать службы чтения и записи. Сервисы чтения и записи оптимизированы для передачи группы данных, а не одного фрагмента данных или нескольких значений. Они позволяют читать и записывать либо значения, либо атрибуты узлов. Сервис чтения имеет следующие параметры:
maxAge: это максимальное время, необходимое для получения значений. Это указывается клиентом. Он заставляет сервер обращаться к устройству (например, к датчику), если копия в его кэше старше, чем параметр maxAge, настроенный клиентом. Если maxAge установлено в ноль, сервер должен предоставить текущее значение, всегда считывая его непосредственно с устройства.
Тип отметок времени: в OPC UA определены две отметки времени: отметка времени источника и отметка времени сервера. Исходная временная метка это временная метка, которая поступает от устройства, а серверная временная метка это временная метка, которая поступает из опреационной системы, на которой работает сервер OPC UA.
Список узлов и атрибутов выглядит следующим образом:

  • NodeId
  • AttributeId для значения экземпляра
  • DataEncoding: это позволяет клиенту выбрать подходящую кодировку данных, и значения по умолчанию XML, UA двоичный


Особенности OPC протокола


OPC протокол нельзя в полной мере назвать свободным. Для разработки ПО с использованием OPC SDK необходимо быть членом OPC Foundation. Однако сейчас существуют свободные реализации библиотеки клиента и сервера, например freeopcua.github.io, но в них отсутсвует пока реализация pub/sub.
По сравнению с другими протоколами, как MQTT, OPC не является легковесным

Программируемый логический контроллер PLC


Термин ПЛК (Programmable Logic Controller, PLC) впоследствии был определен в стандартах EN 61131 (МЭК 61131). ПЛК это унифицированная цифровая управляющая электронная система, специально разработанная для использования в производственных условиях. ПЛК постоянно контролирует состояние устройств ввода и принимает решения на основе пользовательской программы для управления состоянием выходных устройств.
Требования, предъявляемые к PLC:
  • Он должен быть способен функционировать в жестких производственных условиях, такими как температурные перепады, наличие грязи, некачественная сеть электропитания.
  • Он должен работать с дискретными входными и выходными сигналами характерными для промышленности 24В постоянного тока или 240В переменного тока, а также с аналоговыми сигналами (10В, 4-20мА и т.д.)
  • Язык программирования должен быть понятен инженерам по автоматизации
  • PLC должен непрерывно контролировать работу промышленного объекта
  • Операционная система должна обладать достаточным быстродействием для выполнения скан-цикла (20 100мс)

На следующем рисунке приведена структура основного режима работы PLC (на примере CPU Simatic)

image

OPC UA с SIMATIC S7-1500


Предварительные требования должен быть установлен программный пакет Simatic TIA Portal V13 16
Для выполнения симуляции контроллера с OPC сервером необходимо установить и настроить SIMATIC S7-PLCSIM Advanced версии 2 или 3. support.industry.siemens.com/cs/document/109772889/trial-download%3A-simatic-s7-plcsim-advanced-v3-0?dti=0&lc=en-WW Я выполнял установку симулятора версии 3 на систему с имеющимся пакетом Simatic TIA Portal V14 SP1. Перед установкой инсталлятор уведомил о том, что PLCSIM V14 не совместим с SIMATIC S7-PLCSIM V3, и его необходимо удалить. Я выполнил эти действия, после чего установка прошла суспешно. В TIA Portal был создан тестовый проект с CPU 1512C-1 PN. Особенностью стало то, что выполнить имуляцию с помощью кнопки Start simulation стало невозможно, однако работает кнопка Dowload to device при работающем PLCSIM Advanced.
Для доступа по сети к симулятору необходим включить PLCSIM Virtual Eth. Adapter, для чего предварительно необходимо установить софт WinPcap. Далее идут стандартные настройки Ethernet сети. После нажатия кнопки Start симулятор становится активным и виден в сети

image

Далее необходимо установить чекбокс Support simulation during block compilation на вкладке Protection в диалоговом окне вызова пукта Properties контекстного меню в корне проекта

image

Следующим этапом необходимо активировать OPC сервер в проекте и выбрать тип лицензии (можно упустить из вида, после чего не скомпилируется проект)

image

Далее процесс заливки софта в PLCSIM Advanced аналогичен загрузки в стандартный симулятор за исключением описанного ранее.
В тестовом проекте TIA Portal были созданы блок данных DB1 с одним тегом pressure, а также назначен цифровой выход Q0.1 Tag_2.
Для подключения к OPC серверу и мониторингу сети, узлов и тегов можно воспользоваться OPC клиентом UaExpert, который можно скачать с сайта www.unified-automation.com/products/development-tools/uaexpert.html. Для подключения к OPC серверу необходимо добавить новое соединение и прописать Endpoint Url, ранее установленное в настройках проекта OPC сервера в TIA Portale, в моем случае это opc.tcp://192.168.1.113:4840

image

При подключении OPC клиента к серверу симулятора можно наблюдать созданные узлы и теги.

image

Для программной реализации взаимодействия OPC клиента и сервера можно воспользоваться opensource реализацией библиотеки на Python github.com/FreeOpcUa/python-opcua, там же находятся и примеры с кодом. Перед использованием необходимо установить нужные зависимости:

pip install freeopcuapip install cryptography


Простейший пример создания OPC сервера c тремя тегами

from opcua import Serverfrom random import randintimport datetimeimport timeclass Opc:    def __init__(self):        self.server = Server()        self.url = "opc.tcp://127.0.0.1:4848"        self.server.set_endpoint(self.url)        self.namespace_uri = "OPCUA_SIMULATION_SERVER"        self.namespace = self.server.register_namespace(self.namespace_uri)        self.root_node = self.server.get_objects_node()        self.parameters = self.root_node.add_object(self.namespace, "Parameters")    def create_variable(self, name, initial=0):        variable = self.parameters.add_variable(self.namespace, name, initial)        variable.set_writable()        return variabledef main():    opc = Opc()    tag_1 = opc.create_variable("Temperature", 25)    tag_2 = opc.create_variable("Pressure")    tag_3 = opc.create_variable("Time")    opc.server.start()    print("Server started at {}".format(opc.url))    while True:        #tag_1.set_value(randint(10, 50))        tag_2.set_value(randint(200, 999))        tag_3.set_value(datetime.datetime.now())        time.sleep(2)if __name__ == '__main__':   main()


Такой же простейший пример клиенской части

from opcua import Clientimport timeurl = "opc.tcp://127.0.0.1:4848"client = Client(url)client.connect()print("Client connected")Temp = client.get_node("ns=2;i=2")Temp.set_value(25)if __name__ == '__main__':    while True:        temperature = Temp.get_value()        print(temperature)        time.sleep(1)


Наблюдать подключение также возможно с помощью клиента UaExpert

image

Понятие I-IoT Edge


Edge это узел между производственной средой и миром IoT в облаке. Edge может быть разложен на три макрокомпонента: Граничный шлюз (Edge Gateway), Утилиты для конфигурирования (Edge tools), Граничные вычисления (Edge Computing)

image

В 2017 году Gartner объявил следующее: The Edge will eat the cloud.. Хотя это утверждение может показаться немного спорным, оно подчеркивает роль, которую Edge играл за последние годы. Промышленные компании, после фазы перехода к облачным технологиям, осознали, что не всегда можно сделать все в удаленном месте. Причины этого заключаются в следующем:

  • Экспорт данных. Национальные правила могут запрещать экспорт конфиденциальных данных или данных высокого риска. Например, Саудовская Аравия применяет очень строгий контроль за экспортом данных, касающихся нефти и газа. Китай вообще не разрешает вывоз данных.
  • Пропускная способность сети: пропускная способность сети может быть недостаточной для передачи всех видов промышленных данных. Например, высокочастотные данные, такие как вибрации, связанные с вращением оборудования, должны собираться на частоте в диапазоне от 1 до 50 кГц.
  • Задержка сети: расширенные средства управления процессом или аналитика, связанные с изменениями данных для профилирования поведения оборудования в небольшом временном окне, страдают от высокой и изменчивой задержки сети. Оптимизация оборудования необходима для максимально быстрого выполнения в течение определенного интервала времени.
  • Подключение к данным. Для оптимизации рабочего процесса или обслуживания оборудования требуется замена комплектующих без доступа к интернет соединению.


Граничный шлюз (Edge Gateway)


Edge gateway является ядром граничного устройства. Основная обязанность граничного шлюза подключиться к промышленному источнику для сбора и отправки данных их в I-IoT хаб с помощью протокола передачи, такого как MQTT, CoAP, HTTPS или AMQP.
Наиболее важными компонентами пограничного шлюза являются промышленный адаптер и адаптер IoT. Промышленный адаптер обычно подписывается на данные из Field области и публикует их на шине данных. Как правило, он реализует коннектор для выбранного устройства, выступая в качестве источника в потоке данных I-IoT и делает их доступными на шине данных Edge. Адаптер IoT, с другой стороны, получает значения с шины данных и передает их в IoT Data Hub. Важной частью Edge шлюза является компонент Store-and-Forward. Это общий механизм хранения данных во временном локальном хранилище. Он обеспечивает устойчивость передачи данных к нестабильности сети. В глобальной сети нестабильность и задержка канала связи очень высоки. Механизм хранения и пересылки может представлять слудующее:

  • Ограниченный буфер памяти, который покрывает короткий период простоя
  • Специальную область хранения на диске, которая может покрывать длительный период простоя или огромный поток данных.

Диапазон временного окна, в течение которого должна быть обеспечена передача данных, зависит от конкретных сценариев и физических ресурсов граничной памяти и хранилища.

Утилиты для конфигурирования (Edge tools)


Edge tools должны иметь следующие особенности:

  • Возможность легко управлять и настраивать сбор данных как удаленно, так и локально
  • Возможность регистрации для получения исправлений и обновлений
  • Возможность логирования действий
  • Возможность просмотра и изменения данных с помощью пользовательского интерфейса
  • Возможность самостоятельной настройки и самостоятельной регистрации в облаке при запуске
  • Возможность получать и выполнять команды из облака


Граничные вычисления (Edge Computing)


Граничные вычисления имеют следующие особенности:
  • Возможность выполнять действия с помощью промежуточного программного обеспечения I-IoT (middleware), как в автономном режиме, так и в сети.
  • Возможность размещения пользовательских приложений
  • Возможность запуска аналитики в автономном оффлайн режиме, совместно с middleware I-IoT или удаленно.
  • Возможность выполнять действия или загружать аналитику из middleware I-IoT
  • Возможность отправлять неструктурированные и специфические данные в middleware I-IoT по требованию или при запуске по условию


Edge реализации


Поставщики облачных и OEM(original equipment manufacturer)-производители разрабатывают различные решения на основе собственной операционной системы или предлагают независимые от облака комплекты разработки программного обеспечения (SDK).

Azure IoT Edge


Azure IoT Edge это Edge решение, предложенное Microsoft для Azure IoT. Платформа поддерживает хранение и пересылку, Edge Analytics и несколько адаптеров для преобразования собственных или стандартных протоколов в интернет-протоколы. Azure IoT Edge также поддерживает OPC-сервер в своих реализациях: OPC Classic и OPC-UA. Обзор продукта:
  • Работает с устройствами Linux или Windows, поддерживающими подсистемы контейнеров.
  • Бесплатная среда выполнения с открытым кодом и лицензией MIT
  • Совместимые с Docker контейнеры из служб Azure или от партнеров Майкрософ Облачный интерфейс. Позволяет удаленно администрировать и развертывать рабочие нагрузки из облака с помощью Центра Интернета вещейт


Greengrass


Greengrass это новое поколение IoT Edge от AWS. AWS предоставляет SDK для создания Edge AWS и расширяет облачные возможности для граничных устройств с Greengrass. Это позволяет устройствам выполнять действия локально, при этом все еще используя облако для управления, аналитики и постоянного хранения. Greengrass поддерживает OPC UA, и не поддерживает OPC Classic. Преимущества:
  • Реакция на события в режиме, близком к реальному времени
  • Работа в автономном режиме
  • AWS IoT Greengrass выполняет аутентификацию и шифрование данных устройств при обмене как по локальной сети, так и с облаком
  • Упрощенное программирование устройств с поддержкой контейнеров


Android Things


Google предоставляет SDK для Edge разработки. Он спонсирует Android как следующее поколение Edge устройств. Особенности платформы:
  • Разработка с использованием Android SDK и Android Studio
  • Доступ к аппаратным средствам, таким как дисплей и камера, через платформу Android
  • Подключение приложения к сервисам Google
  • Интеграция дополнительных периферийных устройств через API периферийного ввода / вывода (GPIO, I2C, SPI, UART, PWM)
  • Использование консоль Android Things Console для отправки обновлений по беспроводной сети и обновления безопасности


Node-RED


Это инструмент визуального программирования для интернета вещей, позволяющий подключать друг к другу устройства, API и онлайн-сервисы. Среда выполнения Node-RED разработана на базе Node.js и благодаря этому максимально использует его событийно-ориентированную, неблокирующую модель. Node-RED это инструмент потокового программирования, первоначально разработанный командой IBM Emerging Technology Services и в настоящее время являющийся частью JS Foundation.
Особенности:
  • Создание программной логики прямо в браузере
  • Среда выполнения Node-RED разработана на базе Node.js
  • Потоки (логические модули), созданные в Node-RED, сохраняются в JSON-файлы, которые можно без труда экспортировать и импортировать
  • Запуск возможен на любом устройстве, поддерживающем node.js
  • Огромное количество расширений


Intel IoT Gateway


Особенности:
  • Связь облака и предприятий.
  • Возможность подключения к датчикам и существующим контроллерам.
  • Предварительная фильтрация выбранных данных для доставки.
  • Локальное принятие решений, обеспечивающее легкое подключение к устаревшим системам.
  • Аппаратный шифрование данных и блокировка программного обеспечения.
  • Локальные вычисления и аналитика в устройстве.


Flogo IOT


Project Flogo это легковесная экосистема с открытым исходным кодом на основе Go для создания приложений, управляемых событиями. Триггеры и действия используются для обработки входящих событий. Интерфейс взаимодействия предоставляет ключевые возможности, такие как интеграция приложений, обработка потоков и т. д.
  • Integration Flows Application движок с условным ветвлением и визуальной средой разработки
  • Потоковая обработка простое действие обработки потока на основе конвейера с возможностью объединения событий по нескольким триггерам и агрегации во временных окнах.
  • Декларативные правила для контекстных решений в реальном времени
  • Шаблон Microgateway для условной маршрутизации на основе содержимого, проверки JWT, ограничения скорости, circuit breaking и другие паттерны


Eclipse Kura


Eclipse Kura это расширяемый IoT Edge Framework с открытым ис ходным кодом, основанный на Java / OSGi. Kura предлагает доступ API к аппаратным интерфейсам шлюзов IoT (последовательные порты, GPS, сторожевой таймер, GPIO, I2C и т. Д.). Он включает в себя готовые к использованию полевые протоколы (включая Modbus, OPC-UA, S7), контейнер приложений и визуальное программирование на основе веб-интерфейса для получения данных, их обработки и публикации в облачные платформы.

EdgeX Foundry


EdgeX FoundryTM это независимый от поставщика проект с открытым исходным кодом, поддерживаемый Linux Foundation, который создает общую открытую среду для граничных вычислений IoT. В основе проекта лежит инфраструктура взаимодействия, размещенная на полной аппаратно-ОС-независимой платформе эталонного программного обеспечения, позволяющей создать экосистему компонентов plug-and-play, которая объединяет рынок и ускоряет развертывание решений IoT.

Варианты подключения Edge к промышленным источникам данных


  • Edge on fieldbus
  • Edge on OPC DCOM
  • Edge on OPC Proxy
  • Edge on OPC UA
  • OPC UA on the controller


Edge on OPC UA and on the controller


Подключение к серверу OPC UA является предпочтительным сценарием, поскольку это позволяет максимально использовать возможности OPC UA. Связь с OPC сервером можно развернуть двумя различными способами. В первом случае Edge подключается к серверу OPC UA через его клиентский интерфейс OPC UA. Источник данных может быть одним из: PLC, DCS, SCADA или Historian.

image

Во втором случае Edge подключается к OPC серверу, установленному прямо на PLC, как ранее было рассмотрено на примере Simatic CPU 1500.

image

MQTT протокол


Издание-подписка (pub/sub), является способом отделить клиента, передающего сообщение от другого клиента, получающего сообщение. В отличие от модели клиент-сервер, клиенты не осведомлены о каких-либо физических идентификаторах, наподобие IP-адреса или порта. MQTT это архитектура pub/sub, но не очередь сообщений. Очереди сообщений по природе своей хранят сообщения, а MQTT нет. В MQTT, если никто не подписывается (или не слушает) на тему, она просто игнорируется и теряется.

image

Клиент, передающий сообщение, называется издателем; клиент, получающий сообщение, называется подписчиком. В центре находится брокер MQTT, который несет ответственность за соединение клиентов и фильтрацию данных. Такие фильтры обеспечивают:
  • фильтрация по темам по задумке, клиенты подписываются на темы и определенные ветви тем и не получают данных больше, чем хотят. Каждое опубликованное сообщение должно содержать тему, и брокер несет ответственность за повторную передачу этого сообщения подписчикам или игнорирование его;
  • фильтрация по содержимому брокеры имеют возможность проверять и фильтровать опубликованные данные. Таким образом, любые данные, которые не зашифрованы, могут управляться брокером до того, как сохранить их или передать другим клиентам;
  • фильтрация по типу клиент, прослушивающий поток данных, на которые он подписан, может также применять свои собственные фильтры. Входящие данные могут анализироваться, и в зависимости от этого поток данных обрабатывается далее или игнорируется.

В MQTT есть три уровня качества обслуживания:

  • QoS-0 (незаверенная передача) это минимальный уровень QoS. Это аналогично модели сжечь и забыть, подробно описанной в некоторых беспроводных протоколах. Это самый эффективный процесс доставки без подтверждения получателем сообщения и без повторной передачи сообщения отправителем;
  • QoS-1 (гарантированная передача) этот режим гарантирует доставку сообщения хотя бы один раз получателю. Сообщение может быть доставлено несколько раз, и получатель отправит обратно подтверждение с ответом PUBACK;
  • QoS-2 (гарантированный сервис для приложений) это самый высокий уровень QoS, который убеждается в доставке и информирует отправителя и получателя, что сообщение было передано правильно. Этот режим генерирует больше трафика из-за многошагового рукопожатия между отправителем и получателем. Если получатель получает сообщение с уровнем обслуживания QoS-2, он ответит отправителю сообщением PUBREC. Это подтверждает сообщение, и отправитель ответит сообщением PUBREL. PUBREL позволяет получателю безопасно отбросить любые повторные передачи этого сообщения. Затем PUBREL подтверждается получателем с помощью PUBCOMP. Пока сообщение PUBCOMP не будет отправлено, приемник будет кэшировать исходное сообщение для обеспечения безопасности.


На данный момент существует две версии спецификации протокола MQTT: 3.1.1 и 5.0 github.com/mqtt/mqtt.github.io/wiki/Differences-between-3.1.1-and-5.0. Подробнее описание протокола можно посмотреть здесь docs.oasis-open.org/mqtt/mqtt или запись моей презентации github.com/vladipirogov/Message-Queue-Telemetry-Transport, www.youtube.com/watch?v=fYoGubQFz5c&t=5s и www.youtube.com/watch?v=8mupuCjedlc

В следующей статье я постараюсь на примере показать реализацию кастомной Edge I-IoT платформы используя Node-red в качестве Edge Gateway, Apache Kafka как диспетчер данных и временное хранилище, Kafka Streams как Rule Engine, Mosquitto(возможна другая реализация) как MQTT коннектор. Для хранения данных временных рядов будет использоваться технологии InfluxData.

Источники информации


Подробнее..

Ошибки и заблуждения заказчиков при подключении мониторинга станков

17.12.2020 16:16:33 | Автор: admin
Ошибки и заблуждения заказчиков при подключении мониторинга станковОшибки и заблуждения заказчиков при подключении мониторинга станков

Мутная вода и важность мониторинга

Удобно, когда не видно кто, что и когда делает?

Говоря о производстве, можно услышать да, конечно, многим это удобно!

Во-первых, это удобно операторам, которые работают непосредственно за станком. Сделал не по технологии - не страшно, никто не увидит. Сделал бракованную деталь не проблема, выбросил и работаешь дальше спокойно. Нужно сделать что-то на сторону легко, никто же не узнает. Хочется вздремнуть в ночную смену поставил выполнение программы на паузу или, наоборот, сделал обороты повыше и ушел отдыхать.

Во-вторых, это удобно тем, кто отвечает за приобретение нового оборудования и руководителям цехов. При слабых показателях выпуска всегда можно сослаться на нехватку станков. Не видя, как оборудование работает, обосновать закупку нового станка не составляет труда. По факту же станки недозагружены или не работают вовсе.

Ну и в-третьих, это удобно технологам, которые выполняют технологическую подготовку производства. Как правило, они формируют потребность в инструменте, расход которого на любом производстве это огромные траты бюджета. Поэтому, если кому-то нужно, чтобы закупалось больше режущего инструмента или, чтобы его номенклатура была шире, то обосновать это несложно, когда никто ничего не видит.

И таких недобросовестных выгодоприобретателей от ловли рыбки в мутной воде предостаточно: от производственного персонала (операторов станков), до инженерного персонала (технологов, главных инженеров, главных энергетиков) и руководителей (начальников цехов). К сожалению, при такой ловле страдает высшее руководство и все предприятие в целом, которое практически становится заложником данной ситуации. К примеру, руководителю крайне сложно возражать технологу, который настаивает, что именно такая номенклатура режущего инструмента является оптимальной. Или, например, начальнику цеха, который говорит, что не может выполнить план, так как свободных мощностей попросту нет, настаивая на покупке еще одного нового станка.

Всего несколько лет назад покупка еще одного станка или увеличение номенклатуры инструмента не была проблемой. Это не требовало первостепенного внимания со стороны высшего руководства. Не успеваем покупаем еще станок, есть узкое место по выпуску покупаем еще станок, много уходит в брак покупаем еще один более современный станок. Покупка новых станков требует больше инструмента. Станки все современнее, значит номенклатура режущего инструмента все шире. Это не проблема, пока у компании есть деньги.

Как только пропадает возможности купить новый станок и выделить с десяток миллионов рублей в год на режущий инструмент, все становится не так позитивно. Руководство начинает больше интересоваться работой производства изнутри и задавать непривычные вопросы нашим рыбакам. Например: Мы столько купили современных станков, а выпуск практически не растет?, Мы закрываем все больше и больше нормочасов ежемесячно, а готовой продукции больше выпускать не стали?, Все наши станки загружены, а на складе готовой продукции нет?, Мы столько тратим на режущий высокотехнологичный инструмент, а циклы обработки меньше не стали?. После таких вопросов многие начинают покупать и внедрять системы мониторинга станков, понимая, что с их помощью можно получить ответы и решить проблемы.

Сегодня убеждать в важности мониторинга станков уже никого не нужно. Мониторинг станков стал не столько важным, сколько обязательным элементом современного предприятия. Однако, как это ни странно, есть мониторинг, который делает еще хуже и только вредит предприятию. Давайте в этом разберемся подробнее.

Не все то золото, что блестит или заблуждения при мониторинге станков

Не все то золото, что блестит или заблуждения при мониторинге станковНе все то золото, что блестит или заблуждения при мониторинге станков

В современном быстроменяющемся мире очень важно знать, в какие годы та или иная система мониторинга начала создаваться. Отчасти это связано с тем, что в разные времена, были разные проблемы, которые можно было решать с помощь мониторинга. А также сильно повлияло развитие самих технологий (информационных, передачи данных, производственных), которые накладывали сильный отпечаток на возможности мониторинга, а следовательно, и на системы мониторинга. Если мы посмотрим, например, на технологии 10-15-летней давности, то увидим: Windows XP, MS Internet Explorer 8, .NET Framework 2.0, Java 5.0, iPhone первых поколений. Разве эти технологии смогут решить проблемы современного человека? Давайте посмотрим на производственное оборудование того же времени. Что мы увидим? Производители только начали использовать программируемые контроллеры (ПКЛ) Simatic S7-200, Mori Seiki только объединилась с Gildemeister, а станки не такие умные и производительные, как сейчас. Все это сильно сказалось на системах мониторинга того времени.

К глубокому сожалению, устаревшие системы мониторинга существуют и по сей день. Узнать их очень легко. Они, как правило, отслеживают небольшое количества параметров станка: работает, не работает, какая программа выполняется, авария, причина остановки. Источником данных в этих системах всегда выступает производственный персонал, который эти данные вводит вручную. Например, как только станок начинает работать по программе, они отмечают это в системе мониторинга указывая имя программы. Когда станок перестает работать они указывают причину остановки. На основе этих данных строятся разные отчеты, графики, таблицы, которые с разных ракурсов показывают информацию о простоях, сколько времени станок не работал и по какой причине.

Своевременность ввода данных и их корректность в таких системах мониторинга на совести того, кто эти данные указывал, то есть оператора, который работал непосредственно за станком. А как мы узнали в самом начале, эти ребята очень любят мутную воду. Но ведь раньше никто не знал, чем они занимаются, а теперь все увидят! Конечно нет, увидят только то, что они захотят показать. Если им будет выгодно - они укажут, если нет не будут. Нужно, чтобы оборудование меньше простаивало, значит нужно указать, что оно работает. Работает полезно или бесполезно это не важно, главное, чтобы работало. Все просто, всем удобно.

Помимо своевременности и корректности данных, есть еще один недостаток, который присущ всем системам мониторинга 10-летней давности и старше. Этот недостаток фокус, то есть цели и задачи, которые эти системы решают. Повторим, раньше в производстве были другие проблемы, нежели сейчас. Когда покупался новый станок, то главной задачей было сделать так, чтобы он как можно больше работал. Понятное желание, особенно если целью покупки было освоение денег или мнимое увеличение производственных мощностей. Однако, системы мониторинга, фокус которых направлен на простои, не могут показать, насколько хорошо или плохо работает станок. Их фокус направлен только на время, показывая работает он или нет.

Конечно, разработчики таких систем мониторинга стараются их развивать, добавляют новую функциональность, усовершенствуют интерфейс пользователя. Однако, как и ранее, все строится вокруг причин простоя. Изначальный фокус на простои, как сильнейший магнит притягивает все к себе.

Современные системы мониторинга тоже требуют отдельного изучения. Как правило, такие системы разрабатываются молодыми командами, которые испытывают нехватку опыта. Если у команды квалифицированные программисты, значит нехватка опыта будет ощущаться в области производства. Вряд ли они будут хорошо разбираться в циклах обработки, нюансах технологической подготовки производства, режимах резания и т.д. Обратная сторона, когда у команды опытные постановщики задач, которые хорошо разбираются в производстве, а программисты без большого опыта. При таком сценарии технологии больших данных вряд ли будут ими использоваться. В каждом случае системы мониторинга, созданные такими командами, не будут эффективными. Если у команды нет опыта в области производства, значит фокус системы будет направлен на такие простые в понимании вещи, как работает станок или нет. Кроме того, такие системы легко сможет обмануть производственный персонал, а это та же мутная вода. Если у команды нет опыта в программировании, значит будут проблемы с производительностью. Скорее всего технологии больших данных ими применяться не будут, а это значит, что спустя год или даже полгода система будет неработоспособной, так как не будет в состоянии обрабатывать накопленный объем данных.

Почему простои это вред?

Для начала разберемся, что такое простой. Простой это время, когда станок был включен, но программа на нем не выполнялась. Мы уже разобрались, что многие системы мониторинга имеют фокус на простои. Зная причину простоя оборудования, можно ее устранить. Например, зная, что станок часто простаивает из-за отсутствия нужного инструмента, можно реорганизовать процесс подготовки рабочего места, чтобы оператор не тратил время на подготовку, а использовал заранее подготовленный специальным человеком инструмент. Фактически устраняя необоснованные простои, увеличивается время, когда станок работает. Это логично и понятно многим. Давайте посмотрим на экономику.

Допустим стоимость 1 часа работы станка составляет 1 000 рублей. За 1 год станок не работал 4 380 часов. Если сократить это время на 1%, то повышение производительности станка будет 43 800 рублей (4 380 / 100 = 43.8 * 1 000 = 43 800). Можно и дальше пофантазировать. Например, если мы сократим на 100 станках время простоя на 10%, то получим 43800000 рублей. И так фантазировать можно бесконечно. Но это все только фантазии, так как если станок будет работать больше, это не означает, что он будет делать больше продукции. Одну и ту же операцию можно сделать за 4 часа, а можно за 40 минут. Получается, что, сократив время простоя станка, мы не повысим производительность станка. Здесь нет прямой зависимости, как многим хотелось бы.

При таком подходе не смотрят на то, как оборудование работает. Работает цель достигнута. На современном производстве рост производительности напрямую зависит от того, насколько хорошо станок работает. Что это значит? Под качеством работы станка понимается время, когда изменялась геометрия заготовки, нагрузка на всех управляющих органах была выше определенного установленного значения, положения подачи и скорости было на 100% и станок был в режиме AUTO. Давайте еще раз посмотрим на экономику, но уже полезной работы, а не простоев.

За 1 год станок полено работал 2 190 часов и сделал 1500 деталей. Если мы увеличим полезную работу на 1%, то сделаем на 15 деталей больше (1 деталь за 1.46 часа, 2 190 / 100 = 21.9 + 2 190 = 2 211.9 / 1.46 = 1 515). Верно и обратное. Если мы работаем над увеличением полезной работы станка, то в большинстве случаев время полезной работы будет уменьшаться, а количество деталей останется прежним. К примеру, за 1 год станок полено работал 2 190 часов и сделал 1500 деталей. Если мы уменьшим полезную работу на 1%, то высвободим 21.9 часа машинного времени, при этом сделаем те же 1500 деталей!

Лучшие практики и зарубежный опыт

Лучшие практики и зарубежный опытЛучшие практики и зарубежный опыт

Как вы уже поняли, основное заблуждение при подключении мониторинга станков это попытка сократить не то время, которое нужно. Вместо полезной и бесполезной работы станка внимание уделяется времени, когда станок не работал вовсе. Отчасти это связано с тем, что полезная работа станка это технология и лучшие практики подготовки производства. Специальная оснастка, подготовка инструмента вне станка, ограниченный перечень инструмента, работа на правильных режимах и без вмешательств, и многое другое. Увеличение полезной работы станка это постоянная ежедневная работа. Именно в этом колоссальная польза от мониторинга, которая ее сильно упрощает.

Современный мониторинг это в первую очередь линейка, которая показывает насколько все хорошо или плохо. Конечно, есть разные линейки, и отличаются они точностью. Точность в этом случае определяется своевременностью, объективностью и объемом данных.

Помимо линейки, современный мониторинг служит неким фонарем, который в мутной воде подсвечивает проблемные места. Также, как есть разные линейки, есть и разные фонари. Отличаются они тем, что именно освещают, куда и на что заставляют обращать внимание.

Как часто мы видим распечатанные графики с показателями загрузки на производстве? По этим графикам можно легко понять удалось ли ввести в заблуждение руководство при внедрении системы мониторинга станков. Если вы видите на этих графиках цифры в 70% загрузки и выше, значит авантюра удалась.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru