АВТОМАТИЗИРОВАННАЯ АНАЛИТИЧЕСКАЯ СИСТЕМА ПОДДЕРЖКИ И УПРАВЛЕНИЯ КОНТРОЛЬНО НАДЗОРНЫХ ОРГАНОВ МЧС И ПРОМЫШЛЕННОГО ПРОГРАММИРОВАНИЯ ИЛИ НЕСКОЛЬКО СЛОВ ОБ АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ

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

• обеспечение повышенной производительности
труда за счет более высокой квалификации
работников и четких алгоритмов их
работы;

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

• приобретение типового программного
решения исходя из минимальной цены и
максимальной скорости внедрения системы;

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

Принципиально важным является выбор
способа реализации электронной системы
управления персоналом: реализация
электронной системы управления персоналом
как автономного модуля или её реализация
в составе единой автоматизированной
системы управления предприятием.

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

Однако чаще наблюдается действие
негативных субъективных факторов:

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

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

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

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

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

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

• Степени загрузки сотрудников основной
работой. Проблему может решить наем на
временную или постоянную работу новых
сотрудников;

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

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

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

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

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

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

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

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

Внедрение автоматизированных систем управления

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

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

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

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

Как внедрить на предприятии системы автоматизации?

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

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

Основные элементы АСУ на предприятии

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

Основными элементами АСУ на предприятии являются:

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

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

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


АВТОМАТИЗИРОВАННАЯ АНАЛИТИЧЕСКАЯ СИСТЕМА ПОДДЕРЖКИ И УПРАВЛЕНИЯ КОНТРОЛЬНО НАДЗОРНЫХ ОРГАНОВ МЧС И ПРОМЫШЛЕННОГО ПРОГРАММИРОВАНИЯ ИЛИ НЕСКОЛЬКО СЛОВ ОБ АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ

Отлаживаем и запускаем насосную станцию ВЗУ

Довольно часто я слышу такое мнение среди своих коллег и сотрудников, и, будем честными, на то есть причины.

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

Что не так с АСУ, с точки зрения программиста? Сложный и объемный фронт работы, при этом невысокие зарплаты. Программист на объекте чаще всего и швец, и жнец, и на дуде игрец. Помимо процесса разработки программного обеспечения, он обязан также понимать сам процесс, который автоматизирует. Необходимо разбираться в датчиках, исполнительных механизмах и нюансах процесса. Нужно уметь читать электрические схемы и разбираться во всех внутренностях шкафа управления, находить нестыковки в проекте и сборке. Добавим сюда панель оператора, на нее тоже нужно написать программу и увязать с алгоритмом. Надо разработать верхний уровень, установить SCADA-систему, настроить базу данных, отчеты, графики, написать кучу скриптов, увязать опять-таки с алгоритмом и с панелью оператора. Не забываем про сетевую инфраструктуру, коммутаторы, свичи и т. д. Добавим еще и графический интерфейс для панели и для SCADA-системы. По-хорошему этим должны заниматься несколько специалистов, но в реальности все делает именно программист, используя готовые библиотеки для экономии времени. Почему так происходит, я писал в этой статье. Стоит еще обязательно сказать о том, что редко компания работает только с одним вендором, чаще это 2-4 разных производителя железа и софта, отсюда разные среды разработки и разные языки, разные нюансы и подходы. Многовато выходит, да? И это все делается в полевых, не самых комфортных условиях, не в уютном офисе и точно не в кафешке. Даже перечислять непросто, а разобраться во всем одному человеку и довести до рабочего состояния крайне сложно, притом что вилка зарплаты — 80-150 тыс. р.

Что не так с АСУ, с точки зрения предпринимателя? Крайне сложно продать свои услуги дорого. Почему-то так сложилось, что вся эта работа стоит существенно дешевле, чем она должна стоить. Каждый раз приходится объяснять и обосновывать, почему заказчик должен заплатить за то или иное.

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

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

Идем дальше. Всю внутреннюю кухню по реализации проекта давайте оставим внутри компании. Такие слова, как «интерфейс», «шлюз», Modbus, SCADA, ПЛК и т. д. , будем использовать между собой и не выносить за пределы. Нет смысла погружать клиента во все технические тонкости. У клиента (читаем — бизнеса) есть свои проблемы и задачи, которые нам необходимо решить. Как именно это будет происходить — дело третье.

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

Резюмирую. Мы сейчас внутри себя все автоматчики. Контроллеры, SCADA, HMI, Siemens, Schneider. Мы на процесс смотрим изнутри, и большинство, с кем мы работаем, тоже видит процесс изнутри. Нам нужно общаться с клиентами на принципиально ином языке. Рекламировать себя и давать информацию именно как компания, которая реализует комплексно сложные технические проекты (не объекты). Правильнее всего будет ориентироваться на топовые диджитал-студии, к которым обращаются крупные компании за их компетенцией и проектами под ключ. Мы должны позиционироваться так же, как профессионалы, решающие комплексные задачи. Когда идет работа такого плана, как заменить контроллер, запустить вентиляцию, собрать шкаф, — это здорово, и на таком можно зарабатывать. Но в долгосрочной перспективе этим заниматься неинтересно, и к росту это не приведет.

Есть еще один существенный плюс отрасли АСУ, который я стараюсь использовать в последнее время. Организовав правильно процесс, отдавая монтаж и сборочную работу на аутсорс, можно реализовывать действительно крупные и серьезные проекты очень маленькой командой инженеров, буквально из 2‐4 человек

Приложениек постановлению Правительства Москвыот 21 марта 2013 г. N 154-ПП

Положениеоб автоматизированной системе управления городскими финансами города Москвы

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

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

3. А СУ ГФ является собственностью города Москвы.

4. Целями использования АСУ ГФ являются:

4.1. Повышение качества управления финансами и планирования в городе Москве.

4.2. Повышение эффективности функционирования органов государственной власти города Москвы, государственных учреждений города Москвы.

4.3. Обеспечение прозрачности и открытости информации о бюджете города Москвы, государственных программах города Москвы и государственном долге города Москвы.

5. Основными функциями АСУ ГФ являются:

5.1. Технологическое и информационное обеспечение процесса планирования бюджета города Москвы.

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

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

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

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

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

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

5.8. Централизованное хранение информации о пользователях АСУ ГФ и истории предоставления им доступа к электронным сервисам.

5.9. Защита передаваемой информации от несанкционированного доступа, искажения или блокирования с момента поступления указанной информации в АСУ ГФ.

6. А СУ ГФ включает в себя следующие подсистемы:

6.1. Подсистема формирования проекта бюджета по расходам в программном представлении.

6.2. Подсистема формирования и доведения государственных заданий, расчета объемов финансирования государственных заданий.

6.3. Подсистема сбора и актуализации данных.

6.4. Подсистема составления и ведения сводной бюджетной росписи бюджета города Москвы, бюджетных росписей главных распорядителей бюджетных средств.

6.5. Подсистема мониторинга подготовки и реализации государственных программ города Москвы.

6.6. Подсистема “Плановый и уточненный реестр расходных обязательств города Москвы”.

6.7. Подсистема мониторинга начисления заработной платы в государственных учреждениях города Москвы.

6.8. Подсистема “Свод по сети, штатам и контингентам получателей бюджетных средств”.

6.9. Подсистема “Открытый бюджет”.

7. Участниками информационного взаимодействия с использованием АСУ ГФ являются пользователи и поставщики информации в АСУ ГФ, Департамент финансов города Москвы, оператор АСУ ГФ.

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

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

10. Оператор АСУ ГФ:

10.1. Обеспечивает эксплуатацию АСУ ГФ в соответствии с Регламентом функционирования АСУ ГФ, утверждаемым Департаментом информационных технологий города Москвы и Департаментом финансов города Москвы.

10.2. Обеспечивает развитие программно-аппаратной части АСУ ГФ по согласованию с Департаментом финансов города Москвы.

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

10.4. Обеспечивает целостность и неизменность информации с момента ее поступления в АСУ ГФ, ее защиту, резервное копирование, восстановление.

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

11. Отдельные функции оператора могут быть переданы другому органу государственной власти города Москвы, подведомственному ему государственному учреждению города Москвы или иным организациям в соответствии с законодательством Российской Федерации и города Москвы, за исключением функций заказчика эксплуатации и обеспечения развития программной части АСУ ГФ, которые могут быть переданы Департаменту финансов города Москвы.

12. Департамент финансов города Москвы:

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

12.2. Осуществляет учет и регистрацию в АСУ ГФ участников информационного взаимодействия.

12.3. Осуществляет методическую поддержку участников информационного взаимодействия АСУ ГФ.

12.4. Обеспечивает составление и актуализацию справочников и классификаторов АСУ ГФ.

13. Поставщик информации АСУ ГФ:

13.1. Осуществляет формирование и ведение информационной составляющей АСУ ГФ в части, относящейся к его компетенции, в соответствии с Регламентом функционирования АСУ ГФ.

13.2. Обеспечивает достоверность и полноту предоставляемой информации.

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

13.4. Обеспечивает обновление данных с момента получения доступа к АСУ ГФ.

14. Пользователь АСУ ГФ:

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

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

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

Состав указанных данных детализируется в правовых актах, принимаемых в соответствии с пунктами 10.1 и 12.1 настоящего Положения.

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


АВТОМАТИЗИРОВАННАЯ АНАЛИТИЧЕСКАЯ СИСТЕМА ПОДДЕРЖКИ И УПРАВЛЕНИЯ КОНТРОЛЬНО НАДЗОРНЫХ ОРГАНОВ МЧС И ПРОМЫШЛЕННОГО ПРОГРАММИРОВАНИЯ ИЛИ НЕСКОЛЬКО СЛОВ ОБ АВТОМАТИЗИРОВАННЫХ СИСТЕМАХ УПРАВЛЕНИЯ ТЕХНОЛОГИЧЕСКИМИ ПРОЦЕССАМИ

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

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

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

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

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

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

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

Верхний уровень — это серверы и пользовательские ПК (у нас они называются АРМ — автоматизированное рабочее место). Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество 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. R S232 это всем знакомый COM-порт, с тремя основными линиями: Tx (transmit, передача), Rx (recieve, получение) и GND (ground, земля). R S485 это асинхронный полудуплексный последовательный интерфейс по 2 проводам (совмещённые Tx/Rx+ и Tx/Rx-) или 4 проводам (отдельно Tx+, Tx-, Rx+, Rx-) с разностью потенциалов на каждой паре от 2 до 10 вольт.

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

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

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

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

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *