Протоколы (устройства) системы DevelSCADA (часть 2)

Протокол OPC является наиболее универсальным, так как поддерживает все популярные типы данных и механизмы обмена информации, поэтому многие SCADA системы в принципе не поддерживают никаких дополнительных протоколов, помимо OPC, и подключение к другим протоколам осуществляют посредством сторонних OPC серверов. В DevelSCADA же работа с наиболее популярными протоколами ведется напрямую, а OPC используется для работы с протоколами, поддержка которых еще не реализована в ядре. В DevelSCADA используется версия протокола OPC UA , так как он на данный момент является наиболее популярным и кросплатформенным. Так же протокол OPC UA имеет множество механизмов по защите соединения, что может быть актуальным при работе по незащищенном каналам связи (к примеру через сеть интернет).

https://habr.com/ru/articles/957034/

#JavaScript #DevelSCADA #SCADA #Промышленная_автоматизация

Протоколы (устройства) системы DevelSCADA (часть 1)

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

https://habr.com/ru/articles/955982/

#DevelSCADA #JavaScript #SCADA #Промышленная_автоматизация

Разработка приложений DevelSCADA

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

https://habr.com/ru/articles/954798/

#DevelSCADA #JavaScript #SCADA #Промышленная_автоматизация

Скрипты в DevelSCADA

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

https://habr.com/ru/articles/954694/

#DevelSCADA #SCADA #JavaScript #Промышленная_автоматизация

20 лет поисков идеальной промышленной метки: от наклеек до метки собственного производства

Представьте локомотив. Тысячи деталей, сотни узлов, десятки систем. Каждый элемент должен быть учтен, его история обслуживания записана, характеристики доступны. Казалось бы, простая задача — наклеить метку и сканировать. Но что если эта метка должна выдержать температуру эксплуатации до 200°C, удары (при транспортировки и ремонте аппарата), вибрацию на скорости 120 км/ч, облитие маслом и дизелем? А еще быть читаемой через 10 лет эксплуатации?

https://habr.com/ru/articles/943628/

#rfidметки #rfid_считыватель #rfid_паспорт #qrкоды #маркировка #идентификация #промышленная_автоматизация

Проектирование Информационных систем. Итоги, краткое изложение курса

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

https://habr.com/ru/articles/941672/

#проектирование_систем #анализ #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #требования_к_системе #спецификации #стандартизация #стандартизация_разработки

Русский IT против немцев и финнов в условиях кризиса // Самые модные конвейерные весы

«В последнее время все меньше иностранных компаний остаются доступны в России. В связи со сложными внешнеполитическими процессами, внутренний рынок требует все больше отечественных независимых „импортозамещающих“ разработок во всех сферах производства, включая и горную промышленность.» Примерно с такой формулировкой к нам обратилось одно крупное предприятие из области добывающей промышленности. --------------------------------------------------- На большинстве крупных предприятий так или иначе всегда присутствует конвейер. Вещь очень полезная, тем более если необходима постоянная транспортировка материала из цеха в цех, на переработку или куда‑нибудь еще. В нашем случае, точнее в случае заказчика, конвейер установлен в цехе среднего дробления и задача его — загружать руду в мельницу, для получения более мелкой фракции на выходе.

https://habr.com/ru/articles/940762/

#конвейерные_весы #промышленная_автоматизация #уровнемер #лазерный_дальномер #горная_промышленность #инжиниринг #техническое_зрение

Глубокий инженерный анализ: Технический обзор мощного модуля LoRa1121F33-2G4 от NiceRF

LoRa6100Pro-mini — это современный беспроводной UART-модуль от компании NiceRF, построенный на базе чипа Semtech SX127X и использующий технологию LoRa с расширенным спектром. Модуль предназначен для передачи данных на большие расстояния при низком энергопотреблении и высокой помехоустойчивости, что делает его идеальным решением для IoT-приложений.

https://habr.com/ru/articles/938208/

#беспроводной_модуль #дальняя_связь #энергосбережение #промышленная_автоматизация

Неделя в российском AI: от управления «мыслями» нейросетей до победы человека над ИИ

Собрали главные события недели с 21 по 26 июля 2025 года в российском AI-сегменте: технические прорывы, корпоративные внедрения и неожиданные результаты соревнований человека с машиной.

https://habr.com/ru/articles/932744/

#искусственный_интеллект #машинное_обучение #llm #табличные_данные #промышленная_автоматизация #machine_learning

Проектирование Информационных систем. Часть 11. Управление изменениями требований

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

https://habr.com/ru/articles/931652/

#проектирование_систем #анализ #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #требования_к_системе #спецификации #стандартизация #стандартизация_разработки

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

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

https://habr.com/ru/articles/927972/

#mes #Интеграция #Промышленная_автоматизация #Видеоаналитика_в_производстве #Микросервисная_архитектура #opencv

Почему промышленность — это второе лучшее применение для AI (первое — создание мемов с котами)

AI — это дикий хайп. Все про него говорят. Если ты на этой неделе еще не сказал хоть что-то про нейросети, то ты, как Брежнев: медленный, смешной и ретро. Помнят тебя только бумеры, да и то не все. Но значит ли это, что AI не приносит пользу? Доказываю: приносит. Причем в таких тяжелых областях, как энергетика, производство и металлообработка.

https://habr.com/ru/articles/927916/

#AI #ии #промышленная_автоматизация

Введение в обслуживание АСУ ТП на примере эффективных предприятий

Сегодня автоматизированные системы управления технологическими процессами (АСУ ТП) являются неотъемлемой частью любого современного производства. Однако сама установка и пусконаладка системы — лишь половина дела. Настоящее испытание начинается в момент, когда оборудование переходит в эксплуатацию. Именно тогда становится очевидной роль обслуживания АСУ ТП — комплекса действий и организационных мер, позволяющих поддерживать системы в работоспособном состоянии, минимизировать простои и обеспечить надёжную работу всего предприятия. Опыт эффективных предприятий в этой сфере показывает, что качественное обслуживание АСУ ТП напрямую влияет на экономические показатели компании, а также на гибкость и безопасность производства. В данной статье рассматриваются ключевые аспекты обслуживания АСУ ТП, опираясь на опыт компаний-лидеров отрасли, избегающих кризисных ситуаций и добивающихся устойчивого успеха за счёт выверенных стандартов и технологий.

https://habr.com/ru/articles/926088/

#асутп #стандарты #опыт #промышленное_программирование #промышленная_автоматизация #промышленная_революция #промышленные_сети #промышленные_системы_управления #промышленные_роботы #промышленное_оборудование

Проектирование Информационных систем. Часть 10. Разработка требований 10.2. Формирование спецификаций требований

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

https://habr.com/ru/articles/922458/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #требования_к_системе #спецификации #стандартизация

Проектирование Информационных систем. Часть 10. Разработка требований 10.1. Правила формирования требований

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

https://habr.com/ru/articles/921622/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #спецификации #iso #ISO_29148

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.2. Моделирование процессов управления

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

https://habr.com/ru/articles/920838/

#проектирование_систем_управления #проектирование_по #анализ #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #управление_продуктом #управляемые_сервисы

Проектирование Информационных систем. Часть 9. Моделирование поведения 9.1. Теория систем часть 2

После того как мы определились с перечнем основных сценариев, выявили сущности предметной области и спроектировали для них хранилище, необходимо соотнести все эти артефакты друг с другом, распределив поведение системы по ее классам. Как обычно зададим цели на следующий этап работ: На основании выявленных сущностей и процессов, разрабатываемого целевого продукта спроектировать поведение системы, распределив ее по классам. Добавим на диаграмме, иллюстрирующей наш процесс, новый элемент – Модель поведения, связанный, как упоминалось выше, со Сценариями и Моделью данных.

https://habr.com/ru/articles/919454/

#проектирование_систем #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #системный_аналитик #промышленная_автоматизация #поведенческий_анализ #ингерентность #эмерджентность

Проектирование Информационных систем. Часть 8. Разработка логической структуры данных. 8.2. Шаблонный подход

В 1950 году математик по имени Клод Шеннон опубликовал в журнале статью «Как запрограммировать компьютер для игры в шахматы». В этой статье он подсчитал, что количество комбинаций в шахматах будет равно 10 120 . Это на самом деле превосходит количество атомов в известной Вселенной, которое оценивается от 10 78 до 10 82 атомов. Но среднестатистическому шахматисту для успешного старта не обязательно изучать все существующие варианты начала игры, а достаточно выбрать несколько популярных дебютов за каждый цвет. По факту это использование формализованных шаблонов успешных тактических позиций для достижения желаемых результатов. Аналогично шахматным, успешные шаблоны используют и в ИТ. Для того, чтобы, при решении однотипные задачи проектирования не изобретать каждый раз велосипед, принято использовать паттерны проектирования. Давайте рассмотрим некоторые из них, применительно к моделированию хранилищ данных. Приспособленец (Flyweight) - структурный паттерн проектирования, который нужен для эффективной работы с большим количеством мелких объектов. Основная идея: разделить общее состояние объектов и вынести его в отдельное место , чтобы не плодить кучу дубликатов данных и экономить место. При этом объект, представляет себя как уникальный экземпляр в разных местах программы, но фактически не являющийся таковым.

https://habr.com/ru/articles/918450/

#проектирование_систем #проектирование_по #анализ_и_проектирование_систем #системный_анализ #системный_аналитик #инженерия_требований #промышленная_автоматизация #паттерны_проектирования #моделирование_данных #моделирование_предметной_области

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов 7.2. Применение BPMN. Ресурсоемкость

Один из популярных инструментов BPMN (Business Process Model and Notation) — стандарт графического моделирования бизнес-процессов, разработанный Object Management Group (OMG). Он широко используется для визуализации, анализа и оптимизации процессов внутри организаций. Но в отличие от прочих нотаций, BPMN может использоваться совместно со специальным BPM-движком (engine), встроенным в различные ИТ-платформы. То есть бизнес-процессы, описанные с помощью BPMN, не просто визуализируются, а управляют логикой выполнения в реальных ИТ-системах, превращая нотацию в исполняемый код , который интерпретируется движком, При этом продвигая процессы в соответствии с описанной в диаграммах бизнес-логикой, BPMN-движок следит за выполнением шагов, направляет задачи сотрудникам, вызывает API сервисов, генерирует события, фиксирует в Базе Данных (далее – БД) результат и тому подобное. Помимо того, такой инструмент выполняет мониторинг и логирование каждого запущенного экземпляра процесса и фиксирует прогресс и актуальные состояния в БД.

https://habr.com/ru/articles/916942/

#проектирование_систем #проектирование_по #проектирование #анализ_и_проектирование_систем #системный_анализ #промышленная_автоматизация #bpmn #ресурсное_планирование #предварительные_оценки #оценка_трудозатрат

Проектирование Информационных систем. Часть 7. Инжиниринг бизнес-процессов заказчика 7.1. Применение UML Activity

В качестве следующего шага на пути формирования проектного решения определим процессы, которые должны проистекать внутри разрабатываемой системы и окружать ее из вне. Поддерживая непрерывность процесса проектирования, будем отталкиваться от функций, которые мы выявили на предыдущем этапе. Как всегда, обозначим цели текущего шага: на основании выявленных функций, определить сценарии использования/применения, разрабатываемого целевого продукта . На текущем этапе проектирования воспользуемся Алгоритмизацией , еще одним приемом дисциплины «Системный Анализ». Рассмотренные нами ранее модели в большей степени отражали статику, ведь в итоге формализованные функции воплощают свойства системы, которые можно использовать. Теперь внесем немного динамики, моделируя действия. Важное отличие алгоритмов от используемых нами ранее диаграмм IDEF0, это возможность организовывать условные переходы, то есть в зависимости от выполнения некоего условия на определенном шаге сценария, предпринимать далее те или иные варианты действий. Концепция инжиниринга бизнес-процессов подразумевает осмысление различных моделей текущего состояния системы и прогнозирования будущих с целью достижения существенных улучшений по ключевым показателям: стоимость, качество, скорость, ресурсоемкость и прочее. В зависимости от актуальных условий может использоваться: 1) Экстраполяционная модель

https://habr.com/ru/articles/916676/

#проектирование_систем #проектирование_по #анализ #анализ_и_проектирование_систем #системный_анализ #инженерия_требований #промышленная_автоматизация #activity #uml #umlпроектирование