Что такое АСУ ТП на производстве и что это за система? (АУТП в Санкт-Петербурге)

Области применения систем автоматизации

Если рассматривать производственные процессы с точки зрения систем автоматизации и диспетчеризации, то их можно разделить на два основных вида:

• непрерывное производство;
• дискретное производство.

Непрерывным принято считать производство, в процессе которого продукция (изделие) претерпевает ряд непрерывных изменений без остановки технологического процесса. Такие типы производств характерны для металлургической, химической промышленности, электроэнергетики и др.

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

от 3-х дней (после предоставления Заказчиком необходимой информации).

АСУТП

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

.
.

Смотреть что такое “АСУТП” в других словарях

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

Полевой уровень

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

Определение настроечных параметров регулятора

На основании формул таблицы настройки регуляторов рассчитываем параметры регулятора в зависимости от типа желаемого переходного процесса:

Качество настройки контуров управления напрямую влияет на стабильность ведения технологических процессов и получение продукции требуемого качества.

Процесс АСУТП, Обозначение АСУТП

Большой успех автогиганта ВАЗ

Этим блоком мы особенно гордимся, поскольку теперь уже АвтоВАЗ располагается в одном городе с офисом разработки Ruli24, в Тольятти. Связан он с ними и другим образом, но об этом чуть позже.
Одно из первых полноценных и успешных внедрений АСУ прошло на Волжском автомобильном заводе имени 50-летия СССР (ВАЗ, ныне АвтоВАЗ). Оно и неудивительно – гигант такого масштаба просто не мог обойтись без автоматизации рабочих процессов.

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

«Железный» парк составляли 9 ЭВМ General Electric, комплекс традиционного оборудования (перфораторы – 8 единиц, контрольники – 4, расшифровки перфокарт и репродукторы – 2 единицы) и свыше 400 единиц периферийных устройств. Среднесуточное полезное время работы ЭВМ без учета времени профилактического обслуживания составляло 21,5 часов, ежедневное количество регистраций на единицу периферийного оборудования достигало 1000–1500. В системе обеспечивалась достоверность передачи информации, количество ошибочных регистраций по техническим причинам не превышало 0,1% от их общего числа. Высокая надежность функционирования комплекса АСУ-ВАЗ обеспечивалась возможностью гибкого резервирования внешних устройств и процессоров ЭВМ, что позволяло оперативно изменять конфигурации вычислительных систем с помощью периферийных и канальных переключателей.

Конечно, успех внедрения был обусловлен не только заинтересованностью руководства завода-передовика, но и рядом факторов, среди которых отдельно нужно упомянуть исключительное внимание к подготовке персонала (2680 работников завода). Были созданы проектные группы, между которыми были рационально распределены подсистемы АСУ, работа шла в соответствие с зонно-централизованным принципом технического обслуживания и ремонта средств вычислительной и периферийной техники. Обучение управленческого персонала шло в непрерывном режиме, а функциональные работники принимали активное участи в разработке АСУ.

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

Рассказывает Александр Нефёдов, генеральный директор ООО “ИЛАДА” и автор xRM-системы Ruli24:

Я работал в управлении организации производства УОП АвтоВАЗа с 1977 по 1990 г. и участвовал в создании АСУ и АСУТП. В частности была создана подсистема АСУ «Качество», в которой не только учитывались дефекты и брак, но рассчитывался прогноз и план качества для всех производств и цехов завода. Кроме того, именно ВАЗ подвигнул меня на разработку единой информационной системы с единым репозиторием, т.к. в то время каждый отдел УОП занимался автоматизацией своего направления деятельности. Кто-то снабжентем, кто-то производством, кто-то сбытом и т.д. Приходилось делать очень много «мостиков» между этими подсистемами. Кроме того был большой парк ЭВМ: СМ2, СМ4, PDP 11/70, EC 1055 и пр. Наш отдел занимался и автоматизацией работ главного сборочного конвеййра и созданием систем управления участками станков с ЧПУ. В период 1998 по 2003 г. мы уже в компании ИнфоЛада делали для АвтоВАЗа АСУ «Бухгалтерия», которая эксплуатируется до сих пор. Модифицируют её уже специалисты АвтоВАЗа.
Честно говоря, я мало знаю примеров внедрения в нашей стране стандартов MRP! На ВАЗе, ОАО «ТЗТО» — работает. А где ещё? Всё, что говорят о внедрении ERP — это в лучшем случае финансовый блок, управление персоналом и логистика. Но никак не MRP и CRP.

CRP (Capacity Requirements Planning) — планирование производственных мощностей на основе прогноза спроса на продукцию и календарного плана производства. На основе имеющихся производственных мощностей, технологии производства конечной продукции рассчитывается план оптимального распределения производственных мощностей. Формируются отчеты о возможностях и слабых местах в технологическом процессе производства.

MRP (Material Requirements Planning) — планирование потребности в материалах на основе объемно-календарного плана, конструкторских спецификаций изделий. Рассчитывается потребность в материалах и комплектующих изделиях; с учётом данных о складских запасах рассчитывается план закупок сырья — материалов и комплектующих изделий.

Принцип работы АСР и законы регулирования

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

Регулирование уровня в емкости:
1 – клапан; 2 – емкость; 3 – насос.

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

Автоматическое регулирование уровня в емкости:
1 – поплавок; 2 – рычаг; 3 – шток; 4 – клапан.

Поплавок 1 в этой системе перемещается вместе с уровнем, а клапан 4 изменяет расход на притоке. Поплавок связан с клапаном через поворотный рычаг 2 и прикрепленный к нему шток 3.
В такой АСР любое отклонение уровня от заданного, вызванное колебаниями потребления, приведет к перемещению поплавка и связанного с ним клапана. При отклонении уровня выше заданного клапан будет прикрываться, а при отклонении ниже заданного, наоборот, приоткрываться.
Таким образом, в этой системе все указанные составляющие процесса регулирования выполняются автоматически: при отклонении уровня от заданного значения поплавок отклоняет рычаг, а перемещение штока изменяет степень открытия клапана и приводит тем самым к требуемому изменению притока.
Из рассмотренного примера видно, что для управления любым объектом необходимо получить информацию о заданном и фактическом его состоянии, определить отклонение фактического состояния от заданного, и на основе данных параметров выработать целенаправленное воздействие на объект и осуществить его.
В процессе работы системы автоматического регулирования регулятор сравнивает текущее значение измеряемого параметра Х, полученного от датчика Д, с заданным значением (заданием Z) и устраняет рассогласование регулирования e (e=Z-X). Внешние возмущающие воздействия также устраняются регулятором. Структурная схема непрерывного регулятора с аналоговым выходом приведена на рисунке ниже.

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

АСУ ТП это

АСУ ТП – это Автоматизированная Система Управления Технологическими Процессами. Включает в себя спектр подсистем (компонентов), таких как:

• программируемые логические контроллеры (РLС – Programable Logic Controllers);
• распределенные системы управления (DCS – Distributed Control Systems);
• системы противоаварийной защиты (ESD – Emergency Shutdown Systems);
• системы диспетчерского управления и сбора данных (SCADA – Supervisory Control And Data Acquisition);
• системы обеспечения человеко-машинного интерфейса (HMI – Human-Machine Interface / MMI – Man-Machine Interface);

От печали до радости. История российской автоматизации

Время на прочтение

Современные разработчики систем автоматизации имеют богатые возможности: это многочисленные языки программирования, библиотеки, огромные репозитории открытого кода, наконец, относительно доступное практически любое оборудование, необходимое для разработки и тестирования. В 50-е годы, когда в СССР зарождалась идея создания АСУ и начала активно развиваться кибернетика, всех этих ресурсов не хватало. Учёные того времени были не только сухими прагматиками, но и мечтателями — им хотелось позитивных изменений социо-экономических отношений, которые была призвана обеспечить АСУ. Однако вся дальнейшая история создания автоматизированной системы управления в рамках командной экономики и бесконечной бюрократии не столь оптимистична. Но обо всём по порядку.

Типы действия регуляторов

По направлению действия выходного сигнала регуляторы бывают двух типов – прямого или обратного действия.

Функции АСУ

• планирование и (или) прогнозирование;
• учет, контроль, анализ;
• координацию и (или) регулирование.

Необходимый состав элементов выбирают в зависимости от вида конкретной АСУ. Функции АСУ можно объединять в подсистемы по функциональному и другим признакам.

Функции при формировании управляющих воздействий

• Функции обработки информации (вычислительные функции) – осуществляют учет, контроль, хранение, поиск, отображение, тиражирование, преобразование формы информации;
• Функции обмена (передачи) информации – связаны с доведением выработанных управляющих воздействий до ОУ и обменом информацией с ЛПР;
• Группа функций принятия решения (преобразование содержания информации) – создание новой информации в ходе анализа, прогнозирования или оперативного управления объектом

Контроллерный уровень

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

Промышленное программирование, или Пара слов об АСУ ТП

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

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

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

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

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

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

Верхний уровень

Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество SCADA-систем (от англ. supervisory control and data acquisition — диспетчерское управление и сбор данных). Это в некотором роде расширенный аналог IDE, в котором скомпилированная «программа» и выполняется.

Системы SCADA

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

А если совсем не повезёт, то вот так:

Скады неявно можно разделить на серверную и клиентскую части. Опрос полевых устройств и сбор данных производится сервером (обычно, через ПЛК), с сервера клиенты забирают эти данные к себе на монитор. Сами по себе понятия «серверная» и «клиентская» части условны. Фактически разделение производится по лицензиям на компоненты скады, а политика лицензирования у каждого производителя своя. Вплоть до разделения на: количество обрабатываемых сигналов с поля, драйвера протоколов, количество рабочих станций, возможность создания веб-интерфейса, мобильного интерфейса, да и вообще целые куски функционала могут быть за отдельные денжеки. Чаще проще обратиться к поставщику, предоставив исходные данные по проекту, чтобы помогли с подбором лицензий.

Подразумеваются два режима функционирования: режим разработки и режим выполнения (runtime). Не обязательно эти режимы взаимоисключающи: можно редактировать проект на одном АРМе, инженерном, заливать его, он обновится на пользовательских. Это очень важно — изменять проект без простоев и отключений, потому что технологический процесс прерывать нельзя, и операторы всегда должны иметь возможность его контролировать. В скаде создаются графические интерфейсы, настраиваются источники данных с полевых устройств, она отвечает за взаимодействие пользователя (оператора, диспетчера, технолога) с происходящим на производстве, а также за архивирование всех нужных данных в БД.

Архивирование — одна из обязательных функций, очень важно иметь возможность «вернуться назад во времени» для разбора полётов в случае чего-то непредвиденного либо для глобального анализа при медленных, длительных процессах. Например, недавно геологи попросили меня выгрузить табличкой данные по давлению нефти на скважинах за последний год.

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

Особым пунктом в скадах идёт информирование оператора: текущие сообщения и аварийные. Они тоже обязательно архивируются. В общем виде сообщения делятся на текущие и важные (аварийные). Текущие прячут подальше, но журнал аварийных всегда выводится на экране оператора. К текстовым аварийным сообщениям привязываются звуковые, чтобы кто-нибудь не проспал ЧП 🙂

Рынок SCADA

Самыми распространёнными, по-моему, считаются скады производства Invensys Wonderware, Iconics, Siemens, Indusoft, AdAstra, Emerson, Rockwell Automation.

Я лично работал с виндовыми: Invensys Wonderware InTouch и более мощной System Platform, с Iconics Genesis32 — и с (пока ещё?) малоизвестной B&R APROL под SLES (формально, это не совсем скада, а покруче — из-под апрола программируются и сами контроллеры).

По поисковым запросам, например, SCADA, HMI можно посмотреть примеры интерфейсов и мнемосхем.

Внешний вид и юзабилити по приоритету, увы, находятся на последнем месте. Причём, это касается не только рантайма, но и разработки. Для разработки в каждой скаде существуют как минимум дефолтные библиотеки символов — от кнопок и прочих контролов до графических изображений насосов, труб, задвижек, ёмкостей. Здесь-то и могли бы умные разработчики SCADA-пакетов (не путать с нами, асушниками — разработчиками проектов в этих пакетах) добиться принципиального преимущества над конкурентами, сделав продуманные библиотеки, из которых бы даже самый далёкий от дизайна и юзабилити инженер при всём нежелании делал бы гуманные интерфейсы и мнемосхемы. К сожалению, сейчас эта сфера идёт по пути экстенсивного развития, по которому развивалась IT до недавнего времени — наращивание функционала, добавление плюшек, больше, выше, сильнее, harder,

, stronger, и о пользователях пока думают мало.

Средний уровень

Средний уровень — ПЛК, программируемые логические контроллеры. Здесь всё достаточно просто, чаще всего физически ПЛК состоят из отдельных модулей. Для программирования у каждого ПЛК есть своя среда разработки, иногда она объединена со средой для создания SCADA.

Состав ПЛК

Модули бывают такие:

• блок питания;
• процессорный;
• дискретных входов;
• дискретных выходов;
• аналоговых входов;
• аналоговых выходов;
• температурных входов;
• интерфейсные/коммуникационные.

Контроллер B&R серии X20

Зачем нужен блок питания — понятно. БП сделан отдельным именно модулем, а не устройством, чтобы гарантировать совместимость с данной линейкой ПЛК. Чаще всего входное напряжение у БП 220 В переменного тока, выходное — 24 В постоянного тока.

Процессорный модуль — это голова ПЛК. Внутри у него, само собой, ЦПУ, ОЗУ и ПЗУ, сервисный порт для прошивки и, возможно, коммуникационный порт (ethernet, RS232/422/485, Profibus, etc). Иногда коммуникационный порт используется и как сервисный. Иногда на модуле есть переключатель (у Allen Bradley ещё круче — там натуральный ключ с замочной скважиной) для перевода ПЛК в различные режимы работы. Отдельной кнопки включения/выключения нет, в лучшем случае — тот переключатель, иначе, если есть питание — ПЛК запускается, а выключается и перезагружается «по-варварски» отключением питания.

Контроллер Allen Bradley серии CompactLogix

Дискретные и аналоговые модули обрабатывают соответствующие сигналы. Входные модули принимают эти сигналы с поля, выходные — формируют их.

Дискретный сигнал — это обычно напряжение цепи 24 вольта. Есть 24 — это «1», нет — «0». Бывают модули на 220В, есть модули с проверкой целостности цепи. Дискретные сигналы, приходящие с поля, могут информировать, например, о состоянии насоса включен/выключен. Управляющие дискретные сигналы могут запускать либо останавливать этот насос. Оптимизация здесь не оправдана, поэтому на запуск будет отдельная цепь, на останов — отдельная.

Модули I/O одного типа могут быть объединены: например, один модуль с 16 дискретными входами и 16 дискретными выходами.

Аналоговые входные сигналы — это приходят показания с датчиков. Здесь чаще всего используется токовая петля 4-20 мА, в соотетствие которой ставятся пределы измерения датчика. Начинается от 4 мА для диагностирования обрыва цепи (если меньше 4 мА, значит где-то что-то не в порядке с проводкой).

Рассмотрим на примере уровня жидкости в резервуаре. Стоит уровнемер, он измеряет уровень от 0 до 2 метров. Тогда: уровень 0 метров — это 4 мА, уровень 2 метра — это 20 мА. Промежуточные значения калибруются по ситуации, не всегда 1 метр соответствует 4+(20-4)/2=12 мА, может быть небольшая погрешность, уровень в 1 метр может быть какие-нибудь 12,7553 мА.

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

Температурные модули замеряют сопротивление в цепи либо термо-ЭДС. Если на них подключаются термометры сопротивления — при нагревании металла его сопротивление, по законам физики, повышается, соответственно определяется температура. Если подключается термопара (два спаянных проводника из разных металлов, при нагревании стыка возникает разность потенциалов между другими концами), замеряется напряжение.

Интерфейсные (или коммуникационные) модули предоставляют нам порты под RJ45, DB9, DB15, просто клеммники или что ещё бог производителю на душу положит. Помимо реализации непосредственно интерфейса (физического разъёма под коннектор, физического уровня модели OSI) они также реализуют протокол обмена через этот разъём.

Протоколы и интерфейсы

Протоколов напридумывали и используют кучу: ModBus (RTU, TCP, ASCII), Profibus, Profinet, CAN, HART, DF1, DH485 и т.д. Некоторые особо хитрые производители реализуют свои протоколы поверх общепринятых.

Я достаточно тесно знаком с интерфейсами RS232/485 и протоколами Modbus. RS232 это всем знакомый COM-порт, с тремя основными линиями: Tx (transmit, передача), Rx (recieve, получение) и GND (ground, земля). RS485 это асинхронный полудуплексный последовательный интерфейс по 2 проводам (совмещённые Tx/Rx+ и Tx/Rx-) или 4 проводам (отдельно Tx+, Tx-, Rx+, Rx-) с разностью потенциалов на каждой паре от 2 до 10 вольт.

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

Программная начинка

Первое, что нужно сказать, программа в ПЛК выполняется циклически с определённой частотой. Возможности зависят от контроллера, обычно это где-то 20, 50, 250 мс, 1, 2, 3, 4, 5 с. Естественно, это не гарантирует выполнение кода именно за такой промежуток времени, нельзя большие программы пихать в цикл 20 мс, к началу следующего цикла предыдущий должен быть завершён.

Второе, это языки программирования. По идее программируются ПЛК на языках, определённых стандартом МЭК61131:

• IL (Instruction List) — низкоуровневый ассемблероподобный язык.
• LD (Ladder Diagram) — графический язык, представляет собой программную реализацию электрических схем на базе электромагнитных реле. Придумано в лохматые года для тех асушников, которые больше электрики, чем программисты.

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

• ST (Structured Text) — текстовый паскалеподобный язык. По-моему, из всех пяти самый удобный.
• SFC (Sequential Function Chart) — графический высокоуровневый язык. Создан на базе математического аппарата сетей Петри. Описывает последовательность состояний и условий переходов. Ни разу не встречал и не слышал, чтобы где-то использовался.

Это «по идее». Но, например, Siemens придерживается своего наименования языков, а у B&R есть возможность писать на ANSI C.

Самые используемые контроллеры, безоговорочно, у Siemens и Allen Bradley (последним, к слову, принадлежит Rockwell Automation со своей линейкой SCADA-пакетов RSView). За ними по пятам идут Schneider Electric; ОВЕН; General Electric; AutomationDirect; ICP DAS; Advantech; Mitsubishi Electric; B&R.

Заключение

Уровень человеко-машинного интерфейса, обеспечивающий трудовую деятельность человека-оператора АСУТП в системе «человек-машина» (СЧМ), в иностранной интерпретации «HMI-Human-Mashine-Interface».

Вкалывают роботы — счастлив человек?

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

Арифмометр «Феликс» — самый распространённый в СССР арифмометр. Выпускался, с учётом многочисленных модификаций, с 1929 по 1978 год на заводах счётных машин в Курске (Счётмаш), в Пензе (Пензенский завод вычислительной техники) и в Москве

1950-е гг.

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

Начиная с 1960-го г.

Несмотря на командную экономику и «коллективное всё», в этот период будущее АСУ определялось учёными, чьи имена неразрывно связаны с отечественной автоматизацией: идеолог, мечтатель и, пожалуй, гений АСУ А.И. Китов, А.А. Ляпунов, А.И. Берг, выдающийся учёный В.М.Глушков и многие другие. Не будем говорить высокопарных слов об их личной борьбе за концепцию АСУ, но излагая исторические вехи, запомним, что именно эти люди определили историю автоматизированных систем управления СССР и даже постсоветской России. Итак, в 1955 году учёные обращают внимание коллег на возможности использования ЭВМ и кибернетики для автоматизации управления народным хозяйством. Это был смелый поступок, поскольку в те времена кибернетика переживала опалу и подвергалась критике в научных кругах. И вот уже в 1956 году Китов пишет книгу (первую в СССР книгу по программированию), в которой подробно рассказывает о концепции использования АСУ в социалистическом обществе:

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

В начале 1959 года Китов направляет Хрущёву письмо. В нём он рассказывает об огромных финансовых потерях, которые страна несёт из-за недостатков аппарата управления. Тут же, в письме, он предлагает решение: переход от ручных и личных форм управления к автоматизированным, основанным на использовании ЭВМ. По замыслу учёного должна быть создана единая сеть вычислительных машин, которая будет собирать и обрабатывать статистические и учётные данные как по стране в целом, так и по каждому предприятию. Это позволит анализировать показатели, оценивать потребности в рабочей силе, материалах, наличие денежных средств. Он предлагал установить отдельные ЭВМ в органах власти и на предприятиях, а затем объединить их, тем самым получив кластер, который поможет сократить управленческий и административный персонал (человеческий фактор) и ликвидировать часть правительственных учреждений.

Удивительно, но письмо было принято благосклонно и были созданы комиссии по работе над предложением. Такова уж она, советская, а может, и исконно российская, бюрократия. И вот уже осенью 1959-го года А. И. Китов посылает на имя Н. С. Хрущёва второе письмо с грифом «Совершенно секретно», содержащее проект автоматизации управления вооружёнными силами и народным хозяйством СССР с помощью национальной сети вычислительных центров двойного назначения. Разумеется, военное ведомство отвергло идею двойного назначения – вычислительные центры Министерства обороны должны были стать независимыми.

Уже к 1965 году назрела острая необходимость в АСУ, возникшая на волне первой информационной революции. Объём информации возрастал и необходимо было увеличить скорость её обработки. По подсчётам учёных, внешний документооборот среднего промышленного предприятия в 1965 году составлял примерно 100 тысяч документов и 1 млн. показателей.

Однако далее следует лишь множество продуктивных и серьёзных докладов, проектов, монографий и публикаций. В 1966-м году Министерством радиопромышленности СССР и ЦСУ СССР был утверждён «Аванпроект государственной сети вычислительных центров (ГСВЦ)». Научными руководителями этого аванпроекта были А.И. Китов и А.Я. Боярский. В 1967-м году А. И. Китов был утверждён Главным конструктором «Типовой отраслевой автоматизированной системы управления – ОАСУ», а научным руководителем этой ОАСУ утвердили В. М. Глушкова. В 1967-м году А. И. Китов по заданию ЦК компартии подготовил доклад, в котором он открыто показал сильное отставание в области ЭВМ СССР от США. Были названы и основные причины этого отставания: отсутствие координации работ в области создания ЭВМ и программного обеспечения, разобщённость разработчиков.

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

1971-1975 гг. — пятилетка с переменным успехом

АСУ должна была стать одним из символов сформировавшегося постиндустриального общества. В 1971 году директивами XXIV съезда КПСС по пятилетнему плану развития народного хозяйства СССР на 1971–1975 гг. предусматривалось увеличение выпуска ЭВМ в 2,6 раза. Предполагалось «обеспечить широкое применение экономико-математических методов, использование электронно-вычислительной и организационной техники» в целях совершенствования планирования и управления отраслями, предприятиями, объединениями. Ставилась задача ввести в эксплуатацию 1600 АСУ предприятиями и около 700 технологическими процессами. В первую очередь планировалось внедрять АСУ на предприятиях промышленности, которые давали 40% товарной продукции в стране.

Но план не задался. 22 августа 1975 года Совет Министров СССР сообщает о несоответствии темпов развития автоматизации потребностям экономики государства. Был поставлен план на пятилетку 75-80 — в три раза по сравнению с предыдущим периодом увеличить объемы работ по разработке и внедрению в промышленности АСУ технологическими процессами, агрегатами и производствами. АСУП требовало совершенствования всей производственной структуры предприятия: по расчетам ученых именно организационные меры обеспечивали 60–80% общего эффекта от внедрения АСУП. Однако интерес большинства предприятий к АСУ оставался бесконечно низким.

Стадии разработки АСУ ТП

Стадии создания систем автоматизации представлены ГОСТ 34.601-90 «Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания.»

Применительно к деятельности ООО «ЦентрПроектЗащита» перечень, представленный в указанном выше ГОСТ выглядит следующим образом:

Стадия «Формирование требований к АСУ ТП»

На данном этапе Заказчик представляет свои требования к разрабатываемой АСУ ТП. Возможно выполнение предпроектного обследования объекта автоматизации с оформлением отчета об итогах предпроектного обследования.

Стадия «Разработка концепции АСУ ТП»

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

Стадия «Техническое задание»

Разрабатывается Техническое задание автоматизированной системы. Данный этап очень важен, так как Техническое задание разрабатывается в соответствии с ГОСТ 34.602-89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы», в котором четко прописана структура документа и определен полный перечень требований, которые должны быть предъявлены к разрабатываемой системе

Разработанное таким образом Техническое задание является основополагающим документом, на основании которого строятся все последующие проектные решения.

Стадия «Эскизный проект»

На основании предшествующих стадий проектирования разрабатывается комплект основных технических (проектных) решений (ОТР/ОПР), которые согласуются с Заказчиком. На данном этапе уже вырисовывается четкая общая концепция разрабатываемой системы.

Стадия «Технический проект»

Применительно к современным реалиям здесь понимается разработка документации на стадии «Проектная документация» и согласование ее с Заказчиком, экспертными органами и сопровождение документации вплоть до получения положительного заключения экспертизы.

Стадия «Рабочий проект (Рабочая документация)»

Разработка комплекта рабочей документации, взаимодействие с разработчиками программных продуктов, составление спецификаций, заполнение опросных листов (при необходимости).

Стадия «Ввод в действие»

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

Стадия «Сопровождение АСУ ТП»

При необходимости выполнение послегарантийных обязательств, а именно – взаимодействие со службами эксплуатации, взаимодействие со сторонними проектными организациями в случае проведения работ по расширению или реконструкции АСУ ТП.

ОГАС — ещё одна задушенная мечта

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

Развитие проекта происходило в два крупных этапа. На первом этапе была предложена система объединения нескольких вычислительных центров в единую сеть сбора и обработки информации для целей управления народным хозяйством. Первый этап закончился тем, что совнархозы были упразднены и вернулись министерства. На втором этапе (1966–1969 гг.), ведомства (ЦСУ СССР, Госплан СССР и др.), которым было поручено доработать проект, предложили ограничиться созданием отраслевых (министерских) вычислительных систем, что противоречило первоначальному проекту ОГАС как единой общегосударственной автоматизированной системы. Вся концепция, над которой работали видные учёные, разваливалась на глазах. Но в конце 1969 г. стало известно, что США создали ARPANET, которая связала объекты обороны, университеты и органы управления. В разгар Холодной войны это был явный удар ниже пояса, нанесённый советском руководству. Которое не преминуло снова обратить взор к ОГАС. Теперь все ведомства должны были создать свои ГАС, и потом объединить их в общегосударственную сеть.

Проект ОГАС полностью не был реализован, а в 1991 году потерял смысл – переход к рыночной экономике указал свои правила игры. Однако некоторые функциональные звенья всё же сдавались в эксплуатацию. За период с 1966 г. по июнь 1984 г. было создано 6900 АСУ различного назначения, из них более 3300 АСУ на предприятиях и около 3200 ведомственных АСУ. Строительство сети вычислительных центров стартовало в конце 1970-х гг, был построен 21 опорный ВЦ для обслуживания 2000 предприятий. Средний эффект от работы одного опорного ВЦ составил примерно 2 млн. руб. В декабре 1978 года впервые в СССР был осуществлен межмашинный обмен данными между ВЦ, расположенными в Москве, Риге, Киеве, Ташкенте и Томске.

Последняя попытка «достучаться до небес» была предпринята отчаявшимся учёным Китовым в 1985 году, в письме Горбачёву. После 1991 года всем стало не до этого и автоматизация начала обретать те формы, очевидцами которых мы с вами сегодня являемся.