Smart Mfg, более умные микроконтроллеры: смотрите данные

Умное производство часто описывается с помощью роботов, облачных платформ и подключенных производственных линий. Однако многие заводские решения принимаются гораздо ближе к машине. Двигатель меняет скорость. Датчик обнаруживает тепло. Клапан открывается. Аварийный выключатель реагирует на нештатное состояние. Эти действия зависят от блока микроконтроллера или MCU внутри оборудования. Когда микроконтроллер плохо соответствует поставленной задаче, завод может столкнуться с медленной реакцией, сложным программным обеспечением, высоким потреблением энергии или трудностью обслуживания. Когда MCU выбирается с учетом всей машины, он может обеспечить более стабильное управление, более четкий сбор данных и более простой путь к подключенному производству. Я рассматриваю выбор MCU как практическое инженерное решение, а не гонку за выбор самого мощного чипа. ## Начните с реальной рабочей нагрузки машины Производственной машине не нужна вычислительная мощность сама по себе. Ему требуется достаточная производительность, чтобы контролировать свои задачи с подходящим запасом безопасности. Инженеру может потребоваться управлять: - Управлением двигателем и обратной связью по положению - Датчиками температуры, давления или вибрации - Функциями человеко-машинного интерфейса - Промышленной связью - Локальным обнаружением неисправностей - Безопасными обновлениями встроенного ПО - Работой с низким энергопотреблением в режиме ожидания. Небольшой контроллер конвейера может хорошо работать с компактным микроконтроллером и ограниченным набором периферийных устройств. Роботизированной руке могут потребоваться более быстрые контуры управления, несколько интерфейсов связи и поддержка точного времени. Я начну с перечисления всех задач, которые микроконтроллер должен выполнять во время нормальной работы и во время сбоя. Этот список часто показывает, что память, ресурсы таймера, аналоговые функции и поддержка связи имеют такое же значение, как и ядро ​​ЦП. ## Используйте пограничную обработку там, где время отклика имеет значение. Отправка показаний каждого датчика на удаленный сервер может создать ненужный трафик и задержки. Многие машинные решения могут приниматься непосредственно на оборудовании. MCU может считывать данные о вибрации, сравнивать их с определенным рабочим диапазоном и вызывать локальный ответ. Система может замедлить работу двигателя, остановить насос или отправить предупреждение, не дожидаясь подключения к облаку. Упаковочная машина представляет собой простой пример. Если датчик обнаруживает, что продукт расположен неправильно, контроллер может локально остановить следующий цикл движения. Производственной линии не нужно ждать, пока удаленная платформа одобрит действие. Облако по-прежнему играет свою роль. Он может хранить производственные данные, поддерживать планирование технического обслуживания и помогать менеджерам сравнивать производительность машин. MCU выполняет работу по быстрому управлению. Такое разделение может снизить нагрузку на сеть и сделать машину менее зависимой от постоянного соединения. ## Относитесь к подключению как к части проекта. Промышленному оборудованию часто необходимо взаимодействовать с другими машинами, шлюзами и системами управления. MCU должен поддерживать интерфейсы, соответствующие заводской среде. Общие варианты включают в себя: - CAN или CAN FD для сетей транспортных средств и машин - RS-485 для проводной связи на большие расстояния - Ethernet для более высоких скоростей передачи данных - USB для обслуживания и настройки - SPI и I²C для датчиков и локальных модулей - Беспроводные интерфейсы для выбранных задач мониторинга. Правильный выбор зависит от длины кабеля, шума, объема данных, потребностей в обновлении и существующей системы управления. Производителю машин, который поздно добавляет возможности подключения, возможно, придется перепроектировать печатную плату или переписать большие части программного обеспечения. Я предпочитаю отображать путь к данным на ранней стадии проектирования. Это означает принятие решения, какие значения остаются локальными, какие перемещаются между машинами и какая информация достигает заводской платформы. Такой подход упрощает тестирование и обслуживание системы. ## Встройте безопасность в план MCU. Подключенные машины могут обмениваться полезными данными, но каждое соединение также нуждается в защите. Микроконтроллеру для промышленного оборудования могут потребоваться такие функции, как: - Безопасная загрузка - Аппаратное хранилище ключей - Проверка целостности встроенного ПО - Защищенный доступ для отладки - Поддержка шифрованной связи - Контролируемые обновления встроенного ПО Безопасность – это не только проблема программного обеспечения. Аппаратное обеспечение, процесс загрузки, метод производственного программирования и процедура обслуживания — все это влияет на результат. Рассмотрите возможность удаленного обновления прошивки. Контролер должен иметь возможность проверить, что обновление получено из утвержденного источника и что файл не был изменен. Неудачное обновление не должно приводить к невозможности использования компьютера. Инженерам также может понадобиться образ восстановления или безопасный метод отката. Эти детали можно спланировать до того, как продукт попадет на завод. ## Проверьте энергопотребление, выходящее за пределы указанного в паспорте. Машина может работать годами, и ее профиль энергопотребления включает в себя больше, чем активное время ЦП. Группа разработчиков должна проверить: - Активный ток во время выполнения задач управления - Ток в режиме сна или ожидания - Время пробуждения - Поведение периферийного питания - Диапазон напряжений - Нагрев, выделяемый внутри корпуса Инспекционному прибору с батарейным питанием может потребоваться длительный срок службы в режиме ожидания. Фиксированный контроллер может больше заботиться о нагреве и размере шкафа. Оба продукта используют микроконтроллеры, но их целевые показатели энергопотребления различны. Меньшая мощность также может способствовать более простой тепловой схеме. Это может снизить потребность в больших радиаторах или дополнительном потоке воздуха, в зависимости от общей нагрузки на систему. ## Планируйте повторное использование программного обеспечения, не применяя везде один чип. Производителям часто нужна одна программная платформа для нескольких моделей продуктов. Общий код может сократить усилия по разработке, но MCU по-прежнему должен соответствовать каждому продукту. Полезная структура программного обеспечения может разделить: 1. Аппаратные драйверы 2. Логику управления устройством 3. Службы связи 4. Безопасность и обработку ошибок 5. Функции приложений. С помощью этой структуры команда может повторно использовать логику управления при адаптации драйверов для другого микроконтроллера или конструкции платы. Я бы не рассматривал повторное использование программного обеспечения как причину выбора одного и того же MCU для каждой машины. Небольшой сенсорный узел и многоосный контроллер могут иметь разные потребности в синхронизации, памяти и связи. Общий метод разработки может обеспечить согласованность, не приводя к неудовлетворительному аппаратному обеспечению. ## Протестируйте всю систему перед производством. Микроконтроллер, работающий на макетной плате, может вести себя по-другому внутри шумного заводского шкафа. Тестирование должно охватывать: - Шум переключения двигателя - Изменения температуры - Ошибки связи - Неисправности датчиков - Перебои в подаче электроэнергии - Восстановление сторожевого таймера - Сбой обновления встроенного ПО - Длительные периоды работы Например, система управления двигателем может пройти базовые функциональные тесты, но показывать нестабильные показания при запуске двигателя. Проблема может быть связана с заземлением, компоновкой, временем выборки или фильтрацией, а не с самим ядром MCU. Ранние прототипы помогают команде находить эти проблемы, в то время как изменения в схемах и программном обеспечении все еще остаются управляемыми. ## Выбирайте инструменты, которые помогают инженерам решать проблемы. Инструменты разработки влияют на график выпуска продукта и процесс его обслуживания. Инженерам необходим доступ к понятной документации, стабильным библиотекам программного обеспечения, поддержке отладки и оценочному оборудованию. Практический обзор MCU должен включать: - Поддержка среды разработки - Опции компилятора и отладки - Инструменты настройки периферийных устройств - Эталонные проекты - Примеры программного обеспечения - Планы непрерывности поставок - Каналы технической поддержки Чип - это только часть рабочего решения. Хорошо поддерживаемый MCU может облегчить команде диагностику неисправностей, обучение новых инженеров и обслуживание продуктов после запуска. Умное производство не начинается с добавления дополнительных панелей мониторинга. Все начинается с принятия лучших решений внутри каждой машины. Когда я оцениваю MCU, я рассматриваю потребности в управлении, потоке данных, безопасности, мощности, структуре программного обеспечения, тестировании и долгосрочной поддержке как одну связанную картину. Подходящий MCU дает оборудованию надежную локальную точку принятия решений, оставляя при этом место для данных и управления на уровне завода. Этот баланс помогает производителям создавать машины, которыми легче управлять, обновлять и обслуживать.

Многие команды собирают данные каждый день, но по-прежнему принимают решения, руководствуясь привычкой, неполными отчетами или одной цифрой, вырванной из контекста. Я видел эту модель в отделах продаж, операционных отделах и интернет-магазинах. Панель мониторинга может показывать рост трафика, в то время как доход остается неизменным. Менеджер может увеличить запасы, увидев высокие продажи, только для того, чтобы обнаружить, что спрос возник в результате короткой акции. Данные полезны только тогда, когда они помогают людям задавать более правильные вопросы и предпринимать четкие действия. В этом и заключается идея «Смотрите данные. Стройте разумнее». ### Начните с бизнес-вопроса Полезный проект обработки данных не начинается с информационной панели. Оно начинается с вопроса. Возможно, вам будет интересно узнать: - Почему клиенты уходят до оформления заказа? - Какие товары привлекают постоянных покупателей? - Где производство теряет время? - Какой маркетинговый канал приносит продажи, а не просто клики? - Какой запас следует держать на следующий месяц? Четкий вопрос позволяет сосредоточить работу. Без него команды часто собирают больше данных, чем могут использовать. Я предпочитаю писать вопрос в одном предложении, прежде чем просматривать какой-либо отчет. Если предложение слишком широкое, я разбиваю его на более мелкие части. «Как мы можем расти?» трудно измерить. «Какая категория продуктов имела самый высокий уровень повторных покупок в прошлом квартале?» дает команде четкое направление. ### Объедините нужные данные Данные часто находятся в разных местах: - Записи о продажах - Посещаемость веб-сайта - Сообщения службы поддержки клиентов - Рекламные отчеты - Системы инвентаризации - Финансовые файлы - Данные об использовании продукта. Когда в этих источниках используются разные имена, даты или идентификаторы клиентов, отчет может рассказать неправильную историю. Продукт может отображаться как «Синяя рубашка» в одном файле и «Синяя рубашка» в другом. Продажа может учитываться по дате заказа в одной системе и дате оплаты в другой. Прежде чем доверять результату, я проверяю три области: 1. Точность — соответствует ли число исходной записи? 2. Полнота – отсутствуют ли ключевые заказы, клиенты или даты? 3. Последовательность. Все ли системы используют одни и те же определения? Небольшой словарь данных может помочь. Следует объяснить, что означает каждая метрика, откуда она берется и как часто она меняется. Это не позволяет двум командам использовать слово «клиент» для описания двух разных групп. ### Не ограничивайтесь поверхностными цифрами. Большие цифры не всегда свидетельствуют о высокой эффективности. Трафик веб-сайта может вырасти после рекламной кампании, но и стоимость продажи также может вырасти. Товар может хорошо продаваться из-за скидки, а его прибыль останется низкой. Служба поддержки может закрыть больше заявок, но получить более низкие оценки клиентов. Я рассматриваю связанные показатели вместе: - Трафик и коэффициент конверсии - Заказы и размер прибыли - Объем продаж и уровень возврата - Скорость доставки и жалобы клиентов - Расходы на рекламу и совершенные покупки Это дает мне более полное представление о том, что происходит. Цель не в том, чтобы найти число, которое выглядит хорошо. Цель – понять связь между деятельностью и результатами бизнеса. Netflix предлагает знакомый пример. Компания изучает поведение зрителей, поисковую активность и то, как люди прекращают или продолжают просмотр. Эта информация может помочь в принятии решений относительно рекомендаций и контента. Урок прост: данные становятся полезными, когда они связывают поведение клиентов с решением о продукте. ### Превратите результаты в небольшие тесты. Отчет должен привести к решению, которое кто-то может выполнить. Если данные оформления заказа показывают, что многие пользователи уходят после появления стоимости доставки, я мог бы проверить более четкую информацию о доставке на более раннем этапе процесса. Если клиенты часто задают один и тот же вопрос о продукте, я мог бы улучшить страницу продукта, прежде чем добавлять больше сотрудников службы поддержки. Практический тест может идти по следующему пути: - Определите проблему - Выберите одно изменение - Выберите меру - Установите период проверки - Сравните результат с предыдущим процессом - Сохранить, скорректировать или удалить изменение. Небольшие тесты снижают риск. Они также помогают командам узнать, что привело к результату. Одновременное изменение цен на продукты, дизайна страниц и таргетинга рекламы затрудняет понимание результата. ### Создавайте информационные панели для принятия решений Полезная информационная панель должна помочь кому-то решить, что делать дальше. Ему не нужны двадцать карт. Обычно я ищу: - Небольшой набор ключевых показателей - Четкий диапазон дат - Сравнение с предыдущим периодом - Обзор по продуктам, регионам или группам клиентов - Примечания, объясняющие необычные изменения - Простое поле действий для команды Цвет может помочь людям заметить движение, однако слишком много цветов создает шум. Короткая заметка, такая как «продажи выросли после кампании по электронной почте», часто бывает более полезной, чем другая диаграмма. Выбор правильной панели управления также зависит от пользователя. Менеджеру склада могут потребоваться уровни запасов и задержки доставки. Менеджеру по маркетингу может потребоваться цена за лид и продажи по каналам. Один общий отчет может поддержать компанию, но каждой команде по-прежнему необходимо представление, соответствующее ее работе. ### Придерживайтесь человеческого суждения. Данные могут отражать закономерности. Оно не может объяснить все причины, стоящие за ними. Внезапное падение продаж может произойти из-за ошибки на сайте, задержки поставщика, праздника или изменения потребностей клиентов. Прежде чем превратить шаблон в деловое решение, я разговариваю с людьми, близкими к работе. Их опыт может выявить детали, которые не отражены в отчете. Хорошие решения сочетают доказательства с контекстом. Данные помогают уменьшить количество догадок, а люди помогают объяснить, что означают цифры. ### Станьте более разумным благодаря регулярному анализу. Процесс, управляемый данными, — это не разовый проект. Показатели меняются по мере изменения продуктов, клиентов и рынков. Я регулярно просматриваю вопросы, определения и отчеты. Я удаляю показатели, которые больше не направляют действия. Я проверяю, доверяют ли команды по-прежнему данным. Я также спрашиваю, помог ли отчет кому-то сделать лучший выбор. Лучший результат — это не увеличенная приборная панель. Это команда, которая видит, что происходит, понимает, почему это важно, и реагирует осторожно. Четко смотрите данные. Задавайте лучшие вопросы. Создавайте решения, которые можно протестировать, понять и улучшить.

Многие производители собирают данные с двигателей, датчиков, контроллеров и производственных станций, однако данные часто остаются внутри отдельных систем. MCU может регистрировать температуру, ток, вибрацию, время цикла, коды ошибок и потребление энергии. Если эта информация не связана с ежедневными производственными решениями, она останется потоком цифр, а не источником улучшений. Я вижу одну и ту же проблему на многих заводах: машина останавливается, бригада проверяет сигнализацию, заменяет деталь и снова запускает производство. Причина сбоя может остаться неизвестной. Небольшие задержки повторяются. Проблемы с качеством возникают после того, как несколько партий уже проданы. Менеджеры получают отчеты, но отчеты не всегда объясняют, что произошло на уровне машины. Данные MCU могут помочь устранить этот пробел, если завод дает каждой точке данных четкую цель. Начните с выбора одной производственной задачи. Заводу не обязательно подключать каждую машину в первый день. Обычно я рекомендую выбрать одну проблему, которая влияет на производительность, качество или обслуживание. Типичные примеры включают в себя: - Неожиданные остановки двигателя - Высокое потребление энергии в периоды простоя - Повторяющиеся сигналы тревоги по температуре - Длительное время настройки машины - Дефекты продукции, связанные с нестабильными условиями процесса - Отсутствующие производственные записи - Задержки, вызванные вводом данных вручную. Этот шаг сохраняет фокус проекта. Ясная проблема также позволяет легче оценить, полезны ли данные. Подключите MCU к правильным сигналам. Микроконтроллеры могут собирать информацию с датчиков температуры, датчиков давления, энкодеров, датчиков тока, переключателей и других компонентов. Целью не является сбор всех доступных сигналов. Цель — собрать сигналы, которые помогут объяснить выбранную проблему. Для проекта технического обслуживания двигателя полезные данные могут включать в себя: - Ток двигателя - Рабочая температура - Частота запуска и остановки - Уровень вибрации - Время работы - Коды неисправностей - Изменения нагрузки. Для упаковочной линии большую ценность могут иметь время цикла, состояние датчика, температура уплотнения, положение материала и сигналы брака. Данные должны иметь отметку времени и идентификатор машины. Без этих подробностей становится сложно связать неисправность с производственным заказом или конкретной сменой. Фильтруйте данные рядом с машиной. Отправка всех необработанных показаний на центральную платформу может увеличить потребность в хранении и затруднить анализ. MCU или периферийное устройство могут обрабатывать простые правила рядом с производственным оборудованием. Например, система может записывать: - Значение температуры каждую секунду - Событие высокой температуры, когда показания превышают установленный предел - Характер тока, связанный с запуском двигателя - Изменение вибрации по сравнению с нормальным диапазоном машины - Увеличение времени цикла, которое продолжается в течение нескольких циклов. Такой подход сохраняет полезные события, одновременно сокращая ненужный трафик. Это также позволяет машине реагировать, когда соединение с центральной системой ограничено. Пределы должны соответствовать машине. Уровень температуры, нормальный для одного двигателя, может быть слишком высоким для другого. Фиксированные значения, скопированные из другой строки, могут вызвать ложные срабатывания. Превратите показания в производственные сигналы. Необработанные данные сложно использовать оператору. Производственной команде нужна информация, которая поможет принять решение. На информационной панели может отображаться: - Текущее состояние машины - Время работы и время остановки - Количество завершенных циклов - Частота сбоев - Среднее время цикла - Энергопотребление на партию - Отбраковка продукции, связанная с условиями процесса. Группе технического обслуживания может потребоваться другое представление. Это может быть связано с увеличением вибрации, увеличением времени запуска, повторными перегрузками или изменениями тока двигателя. Я предпочитаю информационные панели, которые отвечают на простые вопросы: Что происходит сейчас? Что изменилось по сравнению с обычной картиной? Какое действие должна проверить команда? Экран, заполненный диаграммами, может выглядеть полезным, создавая больше работы для операторов. Лучшим отображением часто является тот, который указывает на конкретную машину, событие и следующую проверку. Свяжите данные MCU с производственными записями. Машинные данные становятся более полезными, когда они связаны с информацией из более широкого процесса. Температурное событие может означать что-то другое во время настройки машины, нормального производства, очистки или смены продукта. Полезные ссылки могут включать: - Производственный заказ - Тип продукта - Партия материала - Смена оператора - Рецепт машины - Запись о техническом обслуживании - Результат проверки качества - Причина простоя Эта связь помогает команде находить закономерности. На заводе может обнаружиться, что дефекты появляются только после определенной партии материала, во время определенного рецепта или после нескольких часов работы машины. Данные не заменяют знания оператора. Это дает оператору больше доказательств при проверке проблемы. Используйте оповещения с осторожностью. Слишком большое количество оповещений может привести к утомлению оповещений. Когда каждое небольшое изменение вызывает предупреждение, люди могут перестать реагировать на систему. У оповещения должно быть четкое условие и ясный владелец. Его можно отправить на техническое обслуживание, если температура двигателя остается выше заданного диапазона в течение пяти минут. Предупреждение о качестве может быть создано, когда давление выходит за пределы утвержденного окна процесса на определенное количество циклов. Команда должна просмотреть каждое предупреждение: - Было ли событие реальным? - Кому-то нужно было действовать? - Лимит подходил? - Оповещение пришло в нужное время? - Привело ли мероприятие к полезному рекорду? Некоторые оповещения должны информировать. Другие должны потребовать принятия мер. Разделение этих типов упрощает управление системой. Используйте данные для принятия решений по техническому обслуживанию. Многие заводы полагаются на календарное обслуживание. Деталь заменяется через определенный период времени, даже если ее состояние хорошее. Другая деталь может выйти из строя до запланированной даты обслуживания. Данные MCU могут поддерживать проверки на основе условий. Рост тока может указывать на повышенное механическое сопротивление. Повторяющиеся изменения температуры могут указывать на проблемы с охлаждением. Более длительное время запуска может указывать на износ, проблемы с центровкой или нестабильное питание. Эти сигналы не доказывают, что деталь выйдет из строя. Они помогают команде технического обслуживания решить, что и когда проверять. Практические записи технического обслуживания могут включать в себя: - Состояние машины перед обслуживанием - Структура данных, которая привела к проверке - Проверенную деталь или участок - Предпринятые действия - Состояние после обслуживания - Любое изменение времени простоя или частоты неисправностей. Это создает полезную связь между данными датчиков и работами по техническому обслуживанию. Используйте данные для улучшения контроля качества. Команды качества часто проверяют готовую продукцию после производства. Данные MCU могут помочь им проверить условия технологического процесса во время производства. Например, машина для формования пластмассы может регистрировать температуру, давление, время впрыска и время охлаждения. Изменение этих значений можно сравнить с результатами проверки продукции. Линия по производству пищевых продуктов может связывать температуру нагрева и время выдержки с записями о партии. На сборочной станции показания крутящего момента могут сопоставляться с серийными номерами. Цель не состоит в том, чтобы предположить, что каждое изменение создает дефект. Цель состоит в том, чтобы найти отношения, которые заслуживают проверки. Завод должен подтвердить любое технологическое правило с помощью образцов, проверок и технической проверки. Данные могут помочь в расследовании, но съемочной группе все равно необходимо подтвердить причину. Пример небольшой фабрики показывает, как может работать этот процесс. Представьте себе цех с шестью станками с ЧПУ. Операторы сообщают, что одна машина останавливается во время длительных производственных циклов. Код тревоги не всегда определяет причину. Команда соединяет данные MCU от двигателя шпинделя, температуры охлаждающей жидкости, времени цикла и состояния неисправности. Через несколько недель записи показывают, что остановки часто происходят после повышения температуры охлаждающей жидкости и ток шпинделя остается высоким в течение нескольких циклов. Команда проверяет систему охлаждения, очищает засоренный фильтр и добавляет регулярный этап проверки. Они также создают оповещения для той же комбинации условий. Результатом не является обещание нулевого времени простоя. Практическая выгода – лучшая видимость. Команда может проверить известный риск до того, как он приведет к более длительной остановке производства. Защитите качество данных и доступ к системе. Проект данных может потерять ценность, если показания отсутствуют, датчики расположены неудачно или машинные часы не совпадают. Рекомендую проверить: - Точность датчика - Частоту выборки - Синхронизацию времени - Отсутствующие записи - Дублирующиеся записи - Перебои в работе сети - Версию прошивки - Права доступа пользователя - Правила резервного копирования и хранения Доступ должен соответствовать каждой роли. Операторам может потребоваться состояние машины и активные оповещения. Обслуживающему персоналу может потребоваться кондиционирование тенденций. Персоналу, ответственному за качество, может потребоваться история процесса. Менеджерам могут понадобиться производственные сводки. Безопасность также имеет значение. Устройства MCU должны использовать контролируемые соединения, обновленное программное обеспечение и отдельный доступ к обычным офисным системам, где это возможно. Точная конструкция зависит от заводской сети и оборудования. Измеряйте прогресс с помощью полезных показателей. Проекту нужны практические меры, а не длинный список цифр. Подходящие индикаторы могут включать в себя: - Минуты незапланированного простоя - Повторяющиеся неисправности - Среднее время на ремонт - Изменение времени цикла - Уровень брака или брака - Энергопотребление на единицу - Часы ручного ввода данных - Время, необходимое для поиска истории машины. Установите базовый уровень перед изменением процесса. Затем завод может сравнить период до и после проекта данных MCU. Результат может показать явный выигрыш, небольшой выигрыш или отсутствие полезных изменений. Каждый результат помогает команде решить, что нужно изменить. Моя точка зрения проста: данные MCU создают ценность, когда они приводят к лучшему вопросу и практическому действию. Увеличение количества датчиков не приводит автоматически к улучшению производства. Целенаправленный путь данных работает лучше: сигнал машины → надежная запись → полезное предупреждение или просмотр → командные действия → измеренный результат. Когда заводы идут по этому пути, данные MCU могут поддерживать техническое обслуживание, качество, управление энергопотреблением и планирование производства, не добавляя при этом ненужных сложностей. Реальное улучшение достигается за счет передачи технических данных людям, которые принимают ежедневные решения на производстве. Мы имеем большой опыт работы в сфере промышленности. Свяжитесь с нами для получения профессионального совета: Хуан: mr.huang@foyotrobotclaw.com/WhatsApp +8613600570999.

Ссылки 1. Национальный институт стандартов и технологий 2018 г. Структура кибербезопасности для производства 2. Международная электротехническая комиссия 2018 г. Сети промышленной связи Управление сетями и системами 3. Международная организация по стандартизации 2018 г. Требования к системам управления качеством 4. Национальный институт стандартов и технологий 2020 г. NIST SP 800-193 Рекомендации по обеспечению устойчивости встроенного программного обеспечения платформы 5. Международное общество автоматизации 2018 г. Безопасность для систем промышленной автоматизации и управления 6. Всемирный экономический форум 2022 г. Глобальная сеть маяков, преобразующая производство с помощью данных и технологий.