Публикация пресс-релизов Поиск по компании
Решения, технологии, стандарты Рынок, отрасль, люди Основы
Отменить подписку Подписка
Производители Системные интеграторы Дистрибьюторы
Продукты месяца Поиск по категории Добавить продукт
Добавить мероприятие
Добавить вакансию Специалисты по АСУ ТП, КИП Специалисты по электротехнике, энергетике Главные инженеры, технологи, электрики Менеджеры по продажам, консультанты, другое
Технические требования Публикация статей Публикация пресс-релизов Media Kit 2014
 


 

Решения, технологии, стандарты - статьи Ua.Automation.com

Масштаб и охват - краеугольные камни "Промышленность 4.0"

Масштаб и охват - краеугольные камни

Крупный производитель стали решил использовать операционные данные для улучшения своей конкурентоспособности. Фокус на технической поддержке, основанной на текущем состоянии оборудования, а также на качестве продукции, позволил производителю повысить уровень доступности оборудования на 13%, а выход продукции уровня «премиум» - с 76% до 91%. Одновременно доля более дорогостоящего «реактивного» ТО понизилась с 80% до всего 20%.

 
На бумаге все это очень похоже на историю успеха для «Промышленность 4.0», или «Интернета вещей». Однако эта история на самом деле намного старше этих модных словечек. Вышеописанный пример взят из презентации Dofasco (сейчас входит в ArcelorMittal), сделанной в 2002 г. Словосочетание «Промышленность 4.0» прозвучит на Hannover Messe еще только через 9 лет после этого.
 
В автоматизации всегда любили модные слова и стандарты. Специалисты спорят об определении концепций вроде «большие данные», «интернет вещей», «машинное обучение», «Промышленность 4.0», «цифровая трансформация», «цифровые двойники». Но на самом деле все они об одном и том же – позитивных изменениях, основанных на увеличении двух параметров: охват и масштаб. Увеличивая охват (количество источников данных) и масштаб (объем собираемых данных), компании расширяют и углубляют информацию, которую они используют для более точной картины реального мира, на основе которой можно действовать. Чем выше охват и масштаб, тем больше возможностей повышать продуктивность, эффективность, безопасность, а значит, и надежность вашего бизнеса. Какая разница между тем, что происходит сейчас, и тем, что было в 2002 или даже в 1992 годах? 
 
С одной точки зрения, все по-прежнему. Хорошим инженерам всегда недостаточно данных, которые у них есть. Они постоянно должны (и обычно так и делают) искать новые пути улучшения различных процессов и опираться в своем поиске на цифры, которые могут или поддержать их гипотезы, или опровергнуть. 
 
С другой точки зрения, все поменялось. За-кон Мура, искусственный интеллект, рост глобальной конкуренции, меняющаяся экономическая среда создали новый деловой ландшафт. Производители теперь должны быть более чувствительны к требованиям поставщиков, регуляторных органов и своих заказчиков. Интеллект, эффективность и гибкость ценны как никогда. Компании уже не могут себе позволить быть простыми поставщиками. Им приходится быть и разработчиками ПО, и производителями. Охват и масштаб ваших данных определяют собой фундаментальные изменения в том, как функционирует вся отрасль. 
 
Промышленность 4.0 хорошо задокументирована. В этой статье я буду использовать ее как модель описания требований мира реального бизнеса, а также того, какие нужно использовать архитектуры данных для соответствия этим требованиям. 
 
Краткая история архивов исторических данных
 
Новые требования, вызванные расширением охвата и масштаба, привели к эволюции архивов исторических данных и инфраструктур данных. Первые системы данных собирали информацию от разобщенных производственных активов. Позднее эти системы были расширены и усовершенствованы с тем, чтобы собирать данные с целых цехов, а то и предприятий. Сейчас создаются архитектуры данных, которые позволят предприятиям «бесшовно» обмениваться данными друг с другом, для улучшения цепей поставок. Еще лет семь тому назад большинство крупных промышленных компаний резко отрицательно отнеслись бы к идее поделиться своими данными или разместить их где-то в облаке. Сейчас почти все они изучают пути создания «цифровых общин».
 
Аналогично сообщество пользователей этой информации также растет и охватывает уже не только инженеров и операторов, но и финансовых директоров, аналитиков, покупателей и других. Также мы видим, как старые промышленные активы из 70-х и 80-х подключаются к современным корпоративным сетям с помощью надежных и недорогих беспроводных технологий и стратегий управления данными. 
  
Золотое правило роста
 
Информация тем ценнее, чем больше людей ее потребляют. Поэтому всегда нужно смотреть за пределы преимуществ единственного проекта. Слишком быстрое внедрение также может привести к провалу проекта. Основным правилом, которое позволяет сбалансировать амбициозные цели и ограничения режима реального времени, является следующее: контролируйте расходы на проект через процесс внедрения, а не изменяя свои цели.  
 
Большинство из проектов, которые оканчивались неудачей, можно разделить на две группы: или проекты оказывались сложнее, чем ожидалось, что требовало значительных доделок на месте, или охват проекта оказывался слишком мал для затраченных времени, энергии и денег. Это те ошибки, которые нужно исправлять на стадии проектирования, а не внедрения. В одном из примеров первого сценария работа не была адекватно оценена. Требовалось больше, чем могли обеспечить просто данные. Из-за этого понадобились дорогостоящие изменения и дополнения, чтобы соответствовать ожиданиям заказчика. Во втором случае проект был нацелен на решение проблемы слишком незначительной для того, чтобы ее решение принесло пользу. Было ошибочное ожидание, что меньшая цель предполагает меньший риск. Это неправильно. Небольшие проекты могут представлять собой такой же высокий технологический риск, как и крупные. Если цели установить правильно, обычные инженерные процедуры могут принести конечный успех. А вот если они установлены неправильно – никакое инженерное мастерство не принесет нужного результата. В идеальной ситуации создается система, которая может соответствовать насущным требованиям и одновременно иметь потенциал для будущего развития. 
 
Чтобы создать масштабируемую систему, надо вначале посмотреть на модели, лежащие в ее основе. На промышленных предприятиях есть три типа моделей активов: физическая, процессная и продуктовая. Исторически масштабируемые системы, как правило, основаны на физической модели: вот сенсор, записывайте его данные как можно точнее и храните их сколько потребуется (это типичный принцип дизайна систем SCADA, ПЛК, РСУ и других систем автоматизации. Приложения, которые используют современные информационные инфраструктуры, почти на 100% состоят из ПО, но это не делает их менее ценными. В конце концов Apple iPhone – это в основном ПО, как и Uber, Airbnb, Lime и другие).
 
Напротив, системы управления производственными процессами основываются на процессной модели, и хотя являются очень ценными в большинстве случаев, обладают внутренне обусловленными проблемами масштабирования и настройки. Особенно это заметно, если пытаться интегрировать метаданные в общую систему. То же самое справедливо и для систем управления жизненным циклом продуктов, основанных на продуктовой модели. И те и другие системы приносят много пользы. 
 
После того как принято решение по архитектуре для масштабирования, необходимо определить другие модели метаданных, к примеру, цифровых двойников, которые позволяют людям работать с данными, представленными понятным для них образом. Приложение по управлению надежностью будет получать данные из того же источника, что и приложение для обзора процессов, однако расчеты, индивидуальные источники данных и техники очистки данных будут другими. Решением является отделение процесса управления данными от приложений, которые эти данные используют, и разработка ясного и открытого интерфейса между ними. После того как вы построите инфраструктуру управления данными, которая может по-настоящему масштабировать и обеспечивать формирование, надежность и безопасность данных – вы получите мощный репозитарий данных.  
 
По мере того как возникнет необходимость включить другие приложения, например, для управления цепочками поставок или оптимизации производства, охват проектов по управлению данными должен достичь поставщиков, производителей и заказчиков. При этом возможно появление сопротивления модернизации. Оно, как правило, коренится в ожидаемой надежности (или ненадежности) крупных программных систем, которые, в свою очередь, порождают впечатление, что затраты и риски безопасности могут оказаться слишком большими. Вообще все это звучит как нерешаемая задача до тех пор, пока вы не вспомните изначальную задачу: контролировать расходы через процесс внедрения, а не путем сокращения охвата. Если все делать правильно, необходимый охват не будет стоить намного больше.
 
Как эти архитектура и инфраструктурный подход соотносятся с требованиями «Промышленность 4.0»?
 
Совместимость – способность машин, устройств, датчиков и людей соединяться и общаться друг с другом с помощью интернета вещей и стандартного интернета.
 
Прозрачность информации – способность информационных систем создавать виртуальную копию физического мира, обогащая цифровые модели предприятий путем агрегации исходных данных датчиков в контекстную информацию высокой ценности. 
 
Децентрализованные решения – способность киберфизических систем принимать самостоятельные решения и выполнять свои задачи с максимальной степенью осторожности. Только в случае исключений, вмешательств или конфликтующих целей задачи переносятся на следующий уровень.
 
Техническая поддержка – во-первых, это способность поддерживающих систем помогать людям, собирая и визуализируя информацию для принятия обоснованных решений и решения насущных проблем. Во-вторых, это способность киберфизических систем реально помогать людям, решая целый ряд задач, которые неприятны, утомительны или безопасны для людей. 
 
Совместимость
 
На самом нижнем уровне нужно определиться с потоком данных, необходимых для данного охвата. Как правило, сейчас он характеризуется огромными объемами необработанных данных. Существуют системы, оперирующие миллионами новых событий каждую секунду, и этот тренд будет только становиться сильнее, по мере того как продолжится работа над точностью данных, а количество сенсоров и оборудования будет только расти. С осторожностью относитесь к разработке систем сбора информации без учета их будущего использования. К примеру, комментарий от операционного пользователя, гласящий, что все, что ему нужно, – это 15-минутные усредненные показатели, лишь создаст схему, которая будет бесполезна для задач автоматизации или поддержки. Обработка информации, особенно таких потоков –
 серьезная нагрузка на системы обработки информации в режиме реального времени. 
 
Одной из задач разработки является устранение любых ненужных расчетов и обработок уже на этом уровне. Комментарий, содержащий слова типа «компьютеры быстрые, а память – дешевая», является очевидным признаком того, что в архитектуре есть проблемы. 
 
Следующим шагом является разработка простых и легко находимых микросервисов для управления обменом данными между модулями. Легкая находимость важна, так как позволяет приложениям автоматически присоединяться к данным и их архивам для поддержки режима «plug and play» – это насущное требование к крупным системам, создание которых с ожиданием ручной настройки ограничивает масштаб. 
 
Прозрачность
 
Датчики и компьютеры могут генерировать очень много информации. Часто она предоставляется в измененном, дополненном виде, чтобы обеспечить ее улучшенную интерпретацию. Стандарт «Промышленность 4.0» в явном виде предполагает наличие моделей для обеспечения этого добавленного контекста. Полностью необходимые функции реализуются конкретным приложением, однако управление формой, метаданными, являются важными функциями инфраструктуры, поскольку это помогает различным приложениям обеспечивать схожее представление данных. Являясь частью определения цифровых двойников, формирование данных также используется для отчетности, обзора, расчета продукции, а также в качестве моделей. При внедрении в онлайн-виде и использовании для операционной деятельности цифровые двойники требуют того же уровня технической поддержки, что и инфраструктура, обеспечивающая потоки данных. 
 
Техническая поддержка
 
Неподдерживаемое ПО быстро становится негодным к использованию. Техническая поддержка включает исправление ошибок и багов, новую логику, апдейты безопасности, функционал онлайн-помощи.
 
Разделение на «слои» в рамках концепции «Промышленность 4.0», а также определение сервисной архитектуры обеспечивает базовые требования для обслуживаемого ПО и помогает решить вопросы совместимости и открытой инфраструктуры. Наконец, систему необходимо разрабатывать с учетом устойчивости к нештатным происшествиям, как внешним (атака хакера), так и внутренним (ошибка в логике), а также к стандартным процедурам (обновление системы). Это часто приводит к использованию систем высокой доступности или резервированию систем. К тому же системы необходимо мониторить на предмет ошибок, которые могут быть обнаружены.  
 
Децентрализованное принятие решений
 
Наконец, еще одно требование «Промышленности 4.0» состоит, на самом деле, из двух требований к архитектуре. Я хочу особо подчеркнуть: автоматизация должна осуществляться системами управления, разработанными под конкретную задачу. Большинство статей, в которых превозносится ценность интернета вещей, который может завести вашу машину, открыть вашу дверь и сделать что угодно еще, недостаточно рассматривают возможность ненормальных событий, которые могут принести вред людям или оборудованию. То же самое касается тревог и предупреждений. Процедура управления тревогами более сложна, чем может показаться, и требует знания полного контекста происходящего. 
 
Многие из современных трендов, концепций, экспериментов с использованием компьютеров для улучшения промышленных процессов – большие данные, интернет вещей, искусственный интеллект, «Промышленность 4.0», цифровая трансформация – превращаются в то, что профессор Майкл Портер описал как «система систем». Никакая индивидуальная система или отдельное оборудование не имеют эксклюзивных прав на компьютеризированные расчеты, от нижнего уровня (процессор датчика) до наивысшего (национальная система балансирования энергопитания). Единственной разницей между малой системой и большой является охват, и для правильного охвата система систем должна уметь масштабироваться.
 
Дж. Патрик Кеннеди