1. Технический Проект Асу Тп
2. Асу Тп Расшифровка
3. Эскизный Проект Асу Тп
4. Современные Асу Тп
5. Рабочий Проект Асу Тп

Разработка технической. Базовых цен на разработку технической документации на АСУ ТП. Разработка АСУ ТП осуществляется согласно стадиям описанным. Технический проект АСУ. Технический проект. Поставку изделий для комплектования АСУ ТП и технических.

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

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

Сюда выводится состояние технологического процесса, и отсюда при необходимости оператором подаются команды на изменение его параметров. Для упрощения разработки создано большое количество 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-пакетов (не путать с нами, асушниками — разработчиками проектов в этих пакетах) добиться принципиального преимущества над конкурентами, сделав продуманные библиотеки, из которых бы даже самый далёкий от дизайна и юзабилити инженер при всём нежелании делал бы гуманные интерфейсы и мнемосхемы. К сожалению, сейчас эта сфера идёт по пути экстенсивного развития, по которому развивалась IT до недавнего времени — наращивание функционала, добавление плюшек, больше, выше, сильнее, harder, better, 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 мА. Аналоговые выходные — то же, только на управление. Не встречал чтобы использовалось, т.к. Всегда существуют наводки. В измерении это допустимая погрешность, в управлении — нет. Да и неудобно это.

Вместо них используется цифровая передача данных по различным протоколам через коммуникационные модули. Порядок затяжки головки ямз 238. Температурные модули замеряют сопротивление в цепи либо термо-ЭДС.

Если на них подключаются термометры сопротивления — при нагревании металла его сопротивление, по законам физики, повышается, соответственно определяется температура. Если подключается термопара (два спаянных проводника из разных металлов, при нагревании стыка возникает разность потенциалов между другими концами), замеряется напряжение. Интерфейсные (или коммуникационные) модули предоставляют нам порты под 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) — текстовый паскалеподобный язык. По-моему, из всех пяти самый удобный. FBD (Function Block Diagram) — своего рода графический язык, «блоксхемоподобный». Программа составляется из функциональных блоков, которые представляют собой подпрограммы, написанные на каком-либо из языков стандарта МЭК61131.

У каждого ФБ есть входы и выходы, которые соединяются со входами и выходами других ФБ. Кому-то, возможно, удобнее делать так, чем писать всё на том же ST. 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. Заключение Пост не претендует на полное справочное описание всего — очень уж разное оборудование, софт и подходы к ним в целом. Самым формально безошибочным рассказом об АСУТП было бы перечисление соответствующих ФЗ, ГОСТов, техстандартов и регламентов. Все возможные расхождения с этими документами считать опечатками;-) С радостью принимаются комментарии, поправки и, если интересно, пожелания для следующих статей.

Метки:. Добавить метки Пометьте публикацию своими метками Метки необходимо разделять запятой. Например: php, javascript, андронный коллайдер, задача трех тел.

Подходы немного разные просто. Мы немного «избалованы» и денег на АСУТП у нас, как привило, не жалеют.

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

Второе — Так ребята, тут за 7-8 месяцев надо установочку автоматизировать (да, а физически мы ее соберем через 6-7 месяцев заодно и скажем как она должна работать), наладить, так чтоб работала и план выполняла, не взрывалась, если что не так. Да и смотри п.1. Так вот работа по этим 2м правилам немного поменяла меня. Стал как в армии — все должно быть параллельно и перпендикулярно. Понятно и просто.

И не надо ничего ПАРСИТЬ. Если надо что-то на чем-то парсить, то надо это выкинуть и поставить что-то другое. Чтоб просто работало)))) А си, парсинг и все остальное это у меня дома на ардуине)))). С ней, родимой Если честно, не знаю, чего я завелся Наверное привычка с работы — надежность, безопасность, ядерная безопасность, радиационная безопасность, не забыть про водород и так по кругу. Параноиком стал.

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

Это хорошо, когда у вас такие заказчики, а когда автоматизируемый объект содержит в себе зоопарк из оборудования различных производителей(ну не производит Siemens одоризационные установки, и никто не сделал таковой на основе контроллеров Siemens). То тут как не крути, надо парсить Да и система автоматики в нашем случае больше является точкой интеграции информации с различных подсистем, с бонусом в виде управления некоторыми технологическими процессами. Вот выше написали про IcpDAS, хорошие штуки, мы их используем, но к сожалении заказчики не признают их как основные системы управления Вот в последнее время они и парсят, на C.

А если Вам требуется интеграция с оборудованием стороннего производителя? Ну вот не делает производитель вашего ПЛК, скажем, частотные приводы для двигателей, а по ТЗ он нужен. Слава богам, если привод будет поддерживать какой-либо стандартный протокол обмена, хотя бы и ModBUS.

А еще бывает такое: «система должна интегрироваться с существующим оборудованием». А под этим термином подразумевается, скажем (пример из личной практики) чудо-теплосчетчик отечественной разработки со своим, совершенно подкуренным протоколом обмена, да еще и не совсем соблюдающий спецификацию EIA-232. Вот тут становится реально дурно.

Я же сказал, что мы немного «избалованы», да и руководство понимает, что проще выкинуть неугодный привод и купить новый, пусть он и лимон стоит, но чтоб работало без выкрутасов. Мы (наш участок) большую часть времени поддерживаем работоспособность существующего АСУТП, чем создаем новое. Хотя даже если задача по автоматизации заказана «на стороне», то контролируем мы каждый шаг. Когда предприятие работает круглогодично, то вылезают неприятные моменты, такие как переполнения буфера, или память выделяется но не высвобождается. И если ошибка возникает раз в 3-4 месяца, то отловить ее непросто. Как правило у нас все «нестандартное» переделывается на «стандартное» со временем.

Тут наверное задачи разные. Многие, кто на сайте подстраиваются под заказчика, который хочет быстрее и дешевле А у меня задача такая — работа с ураном ошибок не прощает. Мы используем ТОЛЬКО LD и FBD.

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

Осталось ее решить. А когда у тебя установка на 1500 входов-выходов, и не дай бог, что-то пошло не так, то рыться в сишном/паскальном/ассемблерном коде и искать ошибку я врагу не пожелаю. Не стоит на ICP DAS наговаривать. Как и любое сложное оборудование не без особенностей, но годное для применения, кроме того отлично работает без всякого подогрева в шкафах (до -30 точно).

А возможность запрогать контроллер из-под VisualStudio после всяких Ultralogik'ов, TraceMod и WinCC, просто кайф. Я последнее время я вообще от общепромышленных SCADA отказался — написал свои библиотеки для низа и для верха. Заказчики безумно довольны, т.к. Стоимость владения системой и создания новых рабочих мест по сравнению с покупкой лицензий получается вообще копеечная, по NDA все необходимые исходники передаются им, так в случае чего они смогут решить и проблемы с поддержкой системы. И кроме того, доступ ко всем исходником качественно повышает уровень обнаружения дефектов.

Как страшный сон вспоминаю переписку с техподдержкой Iconics из-за жутких тормозов Genesis, так и не выяснили в чём причина. Пришлось полностью переустанавливать систему и кучу спец. Но конечно масштаб систем у меня не очень большой. Самые крупный — комбикормовый завод.

Прекрасно понимаю, что для нефти и газа мой подход не подойдёт в том числе и по формальным причинам. У нас сыпятся ICP DAS в тяжелых условиях (есть небольшие пары кислоты) иногда подвисают, хотя всего линеек 10-15 стоит.

А из опыта десяти лет эксплуатации SIEMENS (S7-200, 300, 400, и даже 488 есть 2 шт) а это порядка 2000 модулей (процессорные, входа-выхода) вышло из строя всего 3 модуля. Первый это ET-200 модуль, и 2 аналоговых входа (сожгли сами, не так включили). В общем с учетом того, что у нас остановка оборудования тянет за собой расходов на переработку брака лимона на 2-3 сразу. SIEMENS окупился уже сто раз. А ICP DAS будем менять скоро на SIMATIC.

В крупных АСУ ТП обычно не используют LD или FBD слишком много писать и слишком сложно это. Пакеты используются более комплексные и более тяжеловесные. У нас например используют пакет проектирования Siemens PCS 7 v7.1 на части оборудования. (Не Step 7 а PCS, причем 80% его возможностей). Все программы написаны на CFC и SFC (Именно сименсовской вариации). А еще в более крупных системах используется финская система metsoACN (MetsoDNA/DamaticXDi).

Странно что фирму Metso в статье не упомянули. Одна из крупнейших в России ситем автоматизации построена именно на ее решениях.

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

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

Технический Проект Асу Тп

А ПЛК гарантирует, что цикл будет выполнятся 20мс, не больше, не меньше. Здесь нужно идти от обратного. Возьмем обычный ПК. Допустим вы написали программу которая может выполнится за 20мс и по требованиям должна выполнится. Обычный ПК с какой нибудь типичной ОС не даст вам однозначной гарантии. Может выполнит, а может заставит программу подождать, потому что ОС занимается чем то другим.

Здесь же, если вы поместили программу в 20мс цикл, то вы уверены, что ПЛК гарантированно выполнит ее за данное время и не отправит ее в режим ожидания, пока обрабатывается другая программа. Вообще же к слову ни каких сложных вычислений и тем более ни каких программных циклов в таких программах там нет. Обычно это опрос датчиков и выдача дискретной команды на управление. Время вообще один из самых краеугольных камней в автоматизации. В непрерывных технологических процессах оно может стоить как поломки оборудования так и человеческих жизней. Не работал с S7 1200, но как пишет сам Сименс: SIMATIC S7-1200 представляют собой новое семейство микроконтроллеров, предназначенных для решения самых различных задач автоматизации малого уровня.

Контроллеры способны обслуживать от 10 до 284 дискретных и от 2 до 51 аналогового канала ввода-вывод У нас на предприятии в цеху используются 4 контроллера S7 400H, и обслуживают они в общей сложности порядка 10 000 контуров. В 1200 на сколько я сылшал даже отдельная своя среда разработки и своя ОС, отличная от 300/400 серии. Надо только вставить в программу (и загрузить в контроллер) OB80. Их там несколько разных OB на разные ошибки (превышение времени цикла, отвалившаяся периферия и т.д.). Соответственно, если возникает ошибка и в контроллер загружен блок обработки этой ошибки — контроллер выполнит этот OB. Если OB не загружен, то контроллер уйдёт в стоп. Если обработка ошибок должным образом выполнена (или контроллеру дана индульгенция в виде пустых OB обработки ошибок) — уронить сименс в стоп не получится.

На что уж я не избалован художественным видением этого мира, но всегда поражался, глядя на интерфейсы СКАДА-систем. Кровь же из глаз идет, даже у меня. Ну ведь сама среда разработки позволяет и цвета выбирать, и элементарные «выровнять это по центру, а вот эти элементы распределить равномерно» обычно поддерживает. В 90% случаев что-то типа «Вот тут у нас ярко-синим по ярко-красному мы напишем температуру, возьмем это еще в кислотно-зеленую рамочку с убогим бордюрчиком, ну и, конечно, выровняем значение не по центру, а руками и так чуть ниже и левее центра, чтобы уж вообще красиво было. А еще трубу мы до емкости 3 пикселя не доведем, и стык труб у нас будет тоже со смещением на пиксель — я сам видел, там сварщики именно так в реальности и сделали». А вы говорите — дизайн, юзабилити Эх.

Как человек, который касался и того, и того, могу сказать вот что: у ПЛК уровень абстракции от железа, конечно, выше. Но это и логично: инженер по автоматизации производства должен решать именно задачу автоматизации, а не разбираться с временной диаграммой работы, скажем, АЦП.

Асу Тп Расшифровка

Ему важнее понимать, что «вот на этот модуль у меня от датчика давления пришел унифицированный сигнал 4-20 мА», а уж как он там конкретно преобразуется в INT — дело, в общем-то, десятое. А инженер по эксплуатации хочет точно знать, что этот модуль не вынесет первым же разрядом, когда весенний первый гром, а как там эта защита конкретно реализована — для него это, опять же, дело десятое. А если развить сравнение, то с таким же удивлением и непониманием на всех нас смотрят программисты, пишущие на еще более высоком уровне: как ни крути, но про ООП мы только слышали, про многопоточность — тоже, и нет у нас ни динамического выделения памяти, ни прочих благ и красот. И им наш мирок тоже кажется непонятным и зачастую смешным (впечатление сложено по итогам разговора с хорошим другом — разработчиком на Java).

Мало того что интерфейс не интуитивен, непонятен, запутан, так еще и информации в интернетах по крупинке приходилось собирать. В рунетах как то не принято писать статей по поводу ПЛК и их программирования, а если и пишутся, то примерно так же как и сама эта CoDeSys, запутанно. В общем информации очень мало что к чему, форумы в основном закрытые, ресурсов посвященных этому мало. Вероятно я плохо искал и мало знал, но субъективное мое мнение сложилось очень плохое по поводу всех этих скада. Интересно, а какова сейчас вилка зарплат для асушников? Действительно, есть такая проблема. В основном нет информации в интернете потому, что все вопросы решаются в первую очередь через саппорт.

Хорошая техподдержка является не самым последним критерием выбора оборудования и софта (при удовлетворении всех основных критериев, первый их которых — требования заказчика). Приличные интеграторы не гнушаются отправлять сотрудников на платные обучающие курсы, проводимые разработчиками или официальными дистрибьюторами. С одной стороны — если есть курсы и саппорт, лучше через них решать вопросы, а не искать/писать на форумах. С другой — кто ж будет задаром писать всё это на форумах, если они продают эти знания, и их реально покупают. На одних таких курсах мне в ответ на замечание, мол, у вас тут в одном из ключевых диалогов жуткий косяк в юзабилити, на который я всё время попадался и наконец не выдержал и высказался, — кнопка «Отмена» (компиляции проекта) превращается в кнопку «ОК» (закрытия диалога после завершения компиляции и заливки проекта), мне сказали, мол, у нас тут такая охрененная система, а тебе ещё чота не нравится, пф!

Так что да, «не интуитивен, непонятен, запутан» это зачастую комплимент в сравнении с остальными)) Вилка субъективно, по хедхантеру, в больших городах (Мск, Спб) в среднем где-то на 30% меньше, чем программистам. Объективно (по нефтегазу) — чем ближе к объекту, тем больше, две крайности для примера: в проектном отделе выпустившийся студент без опыта — от 14к, специалист с опытом на северном месторождении (вахта) — около 100к. Вы знаете, CodeSys — это еще далеко не самый плохой вариант. Есть еще куча самодельных сред для всяких ПЛК, производитель которых счел, что он и сам с усами. Вот есть, например, такая EasyTools для контроллеров Carel. Так вот она при попытке скомпилировать такое: int i = 100000; вылетает с синим экраном без сохранения проекта. В той же среде (там один-единственный язык — FBD) при рисовании линий, соединяющих функциональные блоки, нет привязки.

То есть: не довел мышь на один пиксель — получи ошибку компиляции. Без детализации. В стиле «у блока № такой-то есть неподключенные линии».

Если этих линий штук 40, попытка найти ту, которую плохо нарисовал — крайне нетривиальная задача. Вот еще выше автор упоминал такую поделку, как Indusoft.

Тоже склонна при нажатии «compile» вылетать с исключением, не сохраняя проект. Так что — лучше уж CodeSys. C братьями-близнецами Beckhoff работаем, модели BX, CX. По ассортименту модулей — рулез немереный по сравнению и с Сименсом, и со Шнайдером, и еще с чем-нибудь.

На борту ПЛК чистый Ethernet (или еще тысяча интерфейсов на выбор). Модули ввода-вывода начиная от дискретных на разные напряжения (от 5 В) и заканчивая диммерами, ключами на МОСФЕТах и измерителями токов и напряжений, плюс модули сопряжения со всеми популярными полевыми шинами (от 232/485 до KNX, LON, Dali). Так что можно строить абсолютно любые системы, от ЧПУ станка до умного здания, и самое главное — все легко программируется и работает:). Тоже думал на тему упомянутого развития «в вакууме» и пришел к такому выводу.

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

Время отработки даже аварийных устройств, заслонок, например — всё равно измеряется секундами. А отсюда простой вывод: нет смысла наращивать быстродействие. Числодробилки 80-х годов разработки будет достаточно для 99% и сегодняшних задач. А второй пункт — повышенные требования к надежности. Тот же Ethernet пришел в АСУТП совсем недавно — когда его уже обсосали со всех сторон в порядке, скажем так, бытовой эксплуатации. И именно из-за этих требований, если вывести на рынок абсолютно новую, передовую и вообще клевую среду разработки, многие инженеры отнесутся с изрядным недоверием — а вдруг оно глючит? Порой ставки слишком высоки, как писал выше тов.

А я расскажу, за что АСУТПшникам не любить безопасников. Во-1, производители средств автоматики очень любят разные проприеритарные протоколы, нестандартные (с точки зрения безопасников) порты, протоколы (UDP всякие, ISO) — а безопасники очень любят блокировать абсолютно всё, без чего могут существовать офисные хомячки. В результате мы имеет то, что связь либо не работает совсем, либо работает с совершенно необъяснимыми глюками. Я уж не говорю о том, что безопасники очень любят блокировать средства удалённого доступа — такие как VPN, TeamViewer, LogMeIn и RDP.

А автоматчик к объекту цепью не прикован. И вот, как обычно, случается ЧП ночью в выходные, тебя будят в тёплой постельке, а ты даже масштаб бедствия оценить не можешь. Потому, что со слов эксплуатации — «оно само», а зайти посмотреть логи — никак Вот и получается, что безопасники, в сущности, втыкают палки в колёса.

Абсолютно все, какие только можно воткнуть. И безопасникам никто за это голову не морочит. А когда автоматика не работает или работает странно (по причине тех самых плавающих глюков) — по голове получают автоматчики, и получают сильно. А безопасникам — хоть бы хрен.

Спасибо, я в курсе, как это делается сейчас. И делается это (чаще всего) с закрытием глаз на половину требований. Я хочу узнать, как это можно делать. Потому как, скажем, «Общие требования по обеспечению безопасности информации в ключевых системах информационной инфраструктуры» от 18 мая 2007 года устанавливают требования к КСИИ не ниже 1Г (вплоть до 1Б в ряде случаев), а это, среди прочего, таки контроль целостности и очистка памяти. А АСУТП кое-каких объектов (транспорт, ТЭК, например) — вполне себе КСИИ.

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

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

Сам проект, алгоритмы в скаде и в ПЛК, есть контроль на уровне какая версия проекта сейчас залита. А очистка памяти — от чего очищать, если сервер работает годами без перезагрузки, и оперативка используется почти вся. А как Вы будете определять, который из двух несовпадающих конфигов — некорректный?

Эскизный Проект Асу Тп

В системах с высокой надежностью обычно ставят три независимых контура, и совпадение по двум контурам считается правдой. Файловый монитор — это и есть по сути упрощенный контроль целостности. Только для него зеркалирование не нужно. Это иной принцип обеспечения надежности. Скада свое содержимое проверяет на изменение? Если я перехвачу работу с памятью — она это обнаружит? Если я сяду на канал и начну гнать неверные показания датчиков — она это почувствует?

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

Это касается и жестких дисков, и оперативки. Я тоже не понимаю, зачем оно в КСИИ — но есть требования, утвержденные на федеральном уровне — и хоть тушкой, хоть чучелком, но их надо либо выполнять, либо обходить. И это уже зависит от степени занудности надзорных органов. Для определения который из двух несовпадающих конфигов некорректный — у инженера отдельно хранится последняя актуальная версия. Можно использовать систему контроля версий и там защитить по полной.

Если перехватите работу с памятью на одном из серверов и начнёте изменять данные — перехватит как расхождение синхронизации серверов. Сядете на канал как? Физически на канал 4-20 мА? Или тоже перепишете память одного из контроллеров — расхождение синхронизации контроллеров. Прогрузить одновременно два контроллера — загрузка новой прошивки много дольше времени исполнения цикла, авария случится.

Поэтому проект загружают поочереди на каждый контроллер под звуки соответствующего оповещения, предупреждая оператора чтобы не пугался. Поковыряйте архитектуру АСУТП — два сервера, читают данные из двух контроллеров. Между серверами heartbeat, и между контроллерами heartbeat. Что либо перестаёт откликаться — переходим на резерв с оповещением.

Если обсуждать что это гостребование и хоть разбейся но выполни, то адекватного диалога не получится — требования не адекватны. Готового решения вам тут не скажут, кому охота чтобы надзорные органы знали как обходят их требования. Представил я себе, как автор вопроса внедрится в S7-400H, и подменит там программу в обоих контроллерах (3 раза ха):)) На всякий случай, разверну мысль. S7-400H — это физически дублированный контроллер.

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

И никогда на 100% заранее не знаешь, что система ответит. А есть 2 варианта: переход возможен (и он выполняется) либо переход невозможен: контроллер, по своим соображениям, считает, что изменения слишком большие и требуется полная остановка, загрузка обеих половинок и рестарт. Или внедриться на Profibus (закрытый протокол) и слать левые данные Конечно, если это получится, я сниму (и, возможно, даже съем) свою шляпу. Но я искренне не понимаю, зачем такие сложности.

Есть уйма более простых, надёжных, дешёвых и быстрых способов поставить производство раком. В большинстве случаев это называют человеческим фактором:)))).

О техническом задании на разработку систем управления. Технический проект Техническое задание является обязательным исходным документом для проведения работ по разработке СПИО систем автоматизации. Допускается разработка технических заданий для отдельных подсистем как составных частей технического задания на СПИО системы.

Современные Асу Тп

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

Sep 22, 2008 - +8 трейнер (для версии 1.5.10). Распакуйте все файлы из архива в каталог с игрой. Запустите трейнер. Запустите игру, не закрывая. Тренер s.t.a.l.k.e.r ветер перемен v1.00. Наш Форум: Скачать Чит: Посетить. Коды сталкер ветер перемен, 0, 61, 0,00, 4 000. 60, —, 3, —, 12 860, 3 800, Мод Ветер Перемен 2 Сталкер Зов Припяти v1.0.1| Stalkermod.ru, 3 авг 2012. Wind of Time: Трейнер/Trainer (+13) [Mod 1.2-1.3 Final], Скачать глобальные моды на Сталкер, полностью. Также есть звуковые моды на Сталкер, воспроизводящие определенные композиции на фоне., 18:00. Jan 7, 2011 - Трейнер для S.T.A.L.K.E.R.: Чистое Небо версии 1.5.10. Ссылка на скачивание файла: 0.

исходные данные для проведения работы;. технические требования;. программа поведения работы;. порядок приема работы;.

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

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

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

Рабочий Проект Асу Тп

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

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

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