Страница 1 из 2

Проектный инжиниринг

Добавлено: 18 окт 2012, 19:01
san
Вот раз уж сайт разработчиков системы управления, давайте обсудим как вы создаёте свои системы. Так сказать степ бай степ. Не, я конечно понимаю, что есть стандарты и т.д. но кто бы вот написал алгоритм с историей, типа берем объект и .... подписываем акт здачи/приема и получаем деньги. Можно конечно и далее, типа ...повзонили мне через месяц... хороший был бы рассказ (или роман), а главное полезный.

Re: Проектный инжиниринг

Добавлено: 18 окт 2012, 21:30
CHANt
Ну, я то шабашник, и конкурентов по сименсу в городе нет :D поэтому, все частные фирмы работающие по теплоснабжению, увидев страшную аббревиатуру siemens, не важно на чем, и требования к проектируемой АСУТП, звонят либо мне, либо моим подельникам :) Вкратце (у меня САУ),
1) Получаю проект раздела технического обеспечения АСУТП. В наших краях экспертиза промбезопасности и РТН согласовывают только чертежи с кратенькими пояснениями. Остальные разделы АСУТП их особо не интересуют, хотя РТН иногда спрашивает.
2) Обсуждаю с исполнителем -правильность выбора датчиков, ПЛК, частотников, систем безопасности (они должны быть сертифицированы). Проверяю правильность схем соединений в части подключения к ПЛК, ПЧ, панелям, связь. Если что, разработчик исправляет, меняет ит.д. Отправляет проект на экспертизу и заказ на закупку оборудования и материалов.
3) Мой коллега разрабатывает первый документ – Таблица соединений и подключений.
4) Собираю, конфигурирую ПЛК, ПЧ и заполняю данные в HWConfig в соответствии с таблицей соединений.
5) Конфигурирую связь с верхним уровнем в NetPro.
6) Конфигурирую, ранее разработанные FB/FC по аналоговым датчикам. Это достаточно длительный и нудный этап, очень много тегов с учетом диагностики и защит ит.д. Заодно появляется файл с расчетом уставок защит. Если они не определены заказчиком.
7) Обрабатываю дискретные входа. Часть из них идет на конфигурирование ранее разработанных алгоритмов защит. К этому времени у меня начинают заполняться три блока данных: Аналоговые величины. Дискретные теги. Команды управления от панели оператора и скады. Почему так, потому что работаю с самыми младшими контроллерами S7-300, где памяти под переменные просто недостаточно.
8) Затем обрабатываю входные данные по заданиям регуляторам – всякие температурные графики и прочее.
9) Забрасываю напрочь степ7, открываю MSVisio и начинаю декомпозицию задачи. Сначала делается структура технологического контура в квадратиках, ни к чему не обязывающих. Затем разработка алгоритмов механизмов (насос, задвижка, котел ит.п.). Далее разработка технологических алгоритмов управления механизмами типа – АВР, каскадное управление и т.д. Пока не закончу все технологические контура объекта, вплоть до нажатия единственной кнопки, или физического тумблера «Включить объект». Заодно собираю в интернете заводскую документацию по всему оборудованию. Включаю ее потом в электронную версию проекта.
10) Кодирую автоматы по шаблону. Тестирую каждый новый или измененный из разработанных ранее по отдельности.
11) Собираю программу одного контура. Попутно внося данные в ДБшки для обмена с верхним уровнем. По окончании сборки обычно еще и собираю раздел таймеров учета работы оборудования, и вношу в ОВ 35/ОВ100 регуляторы этого контура, связь с ПЧ. И так пока все контура не соберутся.
12) Пишу документ Математического обеспечения «Алгоритмы».
13) Пишу пояснительную записку. Заодно данные по конфигурированию ПЧ, профибаса ит.п.
14) Разрабатываю Программу и методику испытаний
15) Выдаю все это разработчику панели и скады. Если надо составляю в свободной форме задание или пояснения. Вообще, за годы, коллега уже не спрашивает как, он и так понимает.
16) Другой коллега составляет инструкции, паспорт, перечни БД, входных/выходных данных и т.д. Проверяет что я написал в документах, исправляет, оформляет и передает заказчику РД по разделам ИО, МО, ПО ит.д. на согласование и утверждение.
17) Коллега по панели и скаде разрабатывает проект панели до момента наступления ПНР.
18) Пока идет закупка, СМР, нам хватает времени на все. Ну дальше все как обычно. Проверка монтажа вместе с монтажниками. Загрузка контроллера проверка поступления данных от датчиков и механизмов. Далее монтажников отпускаем и начинаем работать по уже утвержденной ПМИ: Калибровка, проверка срабатывания защит, проверка дистанционного управления оборудованием, проверка работы алгоритмов контура, настройка ПИД. После чего испытания, акты и опытная эксплуатация, через месяц, еще раз испытания, если есть замечания, то их устранение и опять проверки и испытания. Акт ввода в пром. эксплуатацию. И только потом деньги. Все накладные за свой счет. В среднем занимает 6-8 месяцев, поэтому если есть возможность тянем 3-5 объектов. Но, не всегда есть такие объемы работ, поэтому и работаю в эксплуатации, а разработка это почти как хобби))))

Re: Проектный инжиниринг

Добавлено: 18 окт 2012, 23:10
san
Спасибо за глубокий ответ.
1) что понимается под проектом раздела ТО? Аля эскизный проект?

Re: Проектный инжиниринг

Добавлено: 19 окт 2012, 04:41
Михайло
Совершенно другой рассказ будет у меня. Мы разрабатываем системы автоматизации, то есть низ АСУ. Работаем по старинке по ЕСКД, то бишь по ГОСТ 2.ххх. Техническое задание, как правило, состоит из полупустого листочка формата А4, где изложено лишь общее содержание функций новой системы автоматизации. Коллеги-механики, гидро-пневматики, как правило, приступают первыми к разработке. Они чертят конструкцию, согласовывают с нами отдельные моменты функционирования автоматики, подбираем вместе также датчики и исполнительные механизмы. Потом начинаем мы. К тому времени уже общие очертания железа вырисовываются. Схема электрическая принципиальная Э3 и перечень элементов ПЭ3 - центральные документы. Параллельно чертится компоновка пультов. Потом я свои наработки передаю нашим девушкам, они проектируют пульты и шкафы управления. Я в это время схему подключения и кабельный журнал выдаю, ну и в конце там остатки документов типа ВП, РЭ остаются... Самое главное отличие от Chant'а - разработка идет обычно месяц-два и документация используется для внутренних нужд большого предприятия, то есть с оплатой нашей работы проблем абсолютно никаких. Сейчас ЗП такая, что ни в какую Москву и Питер не хочется, мало там дают... :p
Потом иногда участвуем в ПНР, типа авторский надзор. Программирования у нас немного, отдельных программистов не держим. Стараемся программы писать перед самим ПНР. Такая вот хитрость.

Re: Проектный инжиниринг

Добавлено: 19 окт 2012, 05:35
CHANt
san писал(а):что понимается под проектом раздела ТО? Аля эскизный проект?
В РФ сейчас, постановлением №87 определены две стадии - проект и РД. Вот я получаю проект, а делаю РД. :) На самом деле сейчас бардак полный, кто как. Обычно, по крайней мере в нашей местности, комплект проектной документации выглядит следующим образом:
1) Общие данные (ведомость рабочих чертежей, общие указания);
2) ФСА
3) План объекта с схемой кабельных трасс;
4) Схемы внешних соединений
5) Электрические принципиальные схемы щитов и подключения оборудования
6) Щиты. Общий вид;
7) Спецификации
и все :)

Re: Проектный инжиниринг

Добавлено: 19 окт 2012, 13:19
Автоматизатор
Михайло писал(а):Программирования у нас немного, отдельных программистов не держим.
Аналогично.
Михайло писал(а):Потом иногда участвуем в ПНР, типа авторский надзор
А вот здесь расхождение. Участвую в ПНР всегда. Всегда требуется подправить алгоритм, т.к. технология проработана крайне слабо. Наладчики научились только проверять входные / выходные цепи, да и то дискретные. Аналоговые - только после получения ЦУ. Модбас/профибас - это только я.

Отсюда:
- с каждом годом документирование занимает все больше времени
- программа на этапе ПНР должна быть отлажена (исключены ошибки программирования)
- начал писать программу и методику испытаний, чтобы самому не делать работы, а спрашивать с кого нибудь :)

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

Чтобы облегчить документирование, стал во время проработки ТЗ и разработки Э3 писать РЭ - основной документ, в который стараюсь запихнуть все. Так как в ТЗ не требований к диагностированию, приходится формулировать требования самому. Стараюсь до программирования подробно описать как все будет работать и согласовываю с механиками-технологами.

Re: Проектный инжиниринг

Добавлено: 19 окт 2012, 23:24
san
CHANt писал(а):В РФ сейчас, постановлением №87 определены две стадии - проект и РД.

Это типа ТП?
CHANt писал(а):2) ФСА
Кстати, а всё таки сейчас как принято называть ФСА или схемы автоматизации? Проде как по ГОСТ 34... и 21... схемы автоматизации, или я что-то пропустил?

Re: Проектный инжиниринг

Добавлено: 19 окт 2012, 23:34
san
Михайло писал(а):Совершенно другой рассказ будет у меня. Мы разрабатываем системы автоматизации, то есть низ АСУ. Работаем по старинке по ЕСКД, то бишь по ГОСТ 2.ххх.
Так у CHANt я так понимаю в основном работы по созданию прикладного ПО + доки, так что одно другое дополняет.
Меня занесло на преподавание проектирования интегрированных автоматизированных систем (так сложились обстоятельства). В реальных проектах в основном работал над созданием прикладного ПО для ПЛК и СКАДА. В принципе учавствовал на всех этапах, но так и не вывел полноценную формулу от начала до конца, хоть как раз в координировании между подсистемами довелось поучавствовать.
Так что опыта маловато, пытаюсь выудить у всех понемножку полезную инфу.

Re: Проектный инжиниринг

Добавлено: 20 окт 2012, 07:40
Автоматизатор
Подметил интересную особенность: насколько помню, еще в институте учили при проектировании разбивать машину на части. То же предлагает Сименс в руководстве на контроллер S7-200:
Расчленение процесса или машины
Разделите ваш процесс или машину на участки, не зависящие друг от друга. Эти участки определяют границы между несколькими системами автоматизации и влияют на описания функциональных областей и назначение ресурсов.
Описание функциональных областей
Запишите описания работы каждого участка процесса или машины. Включите следующие пункты: входы и выходы, описание функционирования, состояния, которые должны достигаться, перед тем как станет возможным управление исполнительными механизмами (например, выключателями с соленоидным приводом, двигателями и приводами), описание интерфейса оператора и интерфейсов с другими участками процесса или машинами.
Проектирование схем защиты
Определите оборудование, требующее для обеспечения безопасности аппаратно реализованной логики. Устройства управления могут выходить из строя опасным образом, вызывая неожиданный запуск или изменение в работе машинного оборудования. Там, где неожиданная или неправильная работа машинного оборудования может привести к физической травме людей или значительному материальному ущербу, нужно уделить внимание использованию электромеханических блокировок, которые работают независимо от S7–200, чтобы предотвратить опасные операции. В проектирование схем защиты должны включаться следующие задачи:
- Выявление ненадлежащей или неожиданной работы исполнительных механизмов, которая может оказаться опасной.
- Определение состояний, которые гарантировали бы, что работа не опасна, и выяснение того, как обнаруживать эти состояния независимо от S7–200.
- Определение влияния CPU S7–200 и входов/выходов на процесс при подаче и выключении питания и обнаружении ошибок. Эта информация должна
использоваться только для проектирования нормального и ожидаемого аварийного режимов работы и не должна использоваться для целей безопасности.
- Проектирование ручных или электромеханических блокировок, которые блокируют опасную операцию независимо от S7–200.
- Предоставление в S7–200 надлежащей информации о состоянии от независимых цепей тока, чтобы программа и любые интерфейсы оператора имели необходимую информацию.
- Определение любых других связанных с безопасностью требований для безопасного протекания процесса.
Сейчас же стараюсь разбивать не на механизмы, а на технологические операции. Часто отдельный механизм выполняет отдельную технологическую операцию. В этом случае подходы совпадают.

Во вложении рисунок, который демонстрировал ход мыслей:
Этап 1. Текстовое описание основных технологических операций (Обычно выдергиваю из ТЗ, где все намешано в кучу. Разделяю операции на последовательные и параллельные).
Этап 2. Приведение текстового описания к "блочному" виду (Из текста делаю что то приближенное к блок-схеме).
Этап 3. Разбивка сложных операций на более мелкие, указание взаимодействия частей (Дальнейшая детализация, которая заканчивается появлением графов)

Вычисление номера упора
Попытка в виде графа изобразить алгоритм выбора упора.

Графы: Шлепперы, Экстракторы
Хотя изображены в виде графа, в программе реализованы как релейная схема (на LAD). Городить огород в виде классической реализации графа не стал, т.к. можно написать все в виде одной цепочки.

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

Re: Проектный инжиниринг

Добавлено: 20 окт 2012, 09:42
Михайло
картинку лучше скачать, нажав "Сохранить изображение..." или как там у вас в браузере?

Re: Проектный инжиниринг

Добавлено: 20 окт 2012, 13:00
CHANt
san писал(а):
Это типа ТП?
Это у меня ТП и часть РП - я это называю этап рабочей документации. А то что мне выдают - это полное соответствие ГОСТ 21.408-93 на ТО, Т.е. я довожу проект до состава по ГОСТ 34.201
Я ж говорю бардак сейчас. Кто что хочет, тот и делает. Лишь бы при экспертизе могли обосновать с какого ГОСТ, РД или прочего взяли состав этого проекта.
На основной работе (электроэнергетика) мы требуем выполнять в два этапа. Первый этап - Общие технические решения (ОТР), второй этап - проектная и рабочая документация (ПиРД). Все. по ГОСТ 34.201 соответствует 1 этап - ЭП, второй этап - ТП, РП, РД
ТЗ заказчик пишет сам.
san писал(а):
Кстати, а всё таки сейчас как принято называть ФСА или схемы автоматизации? Проде как по ГОСТ 34... и 21... схемы автоматизации, или я что-то пропустил?
Схема функциональная системы автоматизации.

Re: Проектный инжиниринг

Добавлено: 20 окт 2012, 14:07
san
CHANt писал(а):
san писал(а): Кстати, а всё таки сейчас как принято называть ФСА или схемы автоматизации? Проде как по ГОСТ 34... и 21... схемы автоматизации, или я что-то пропустил?
Схема функциональная системы автоматизации.
Это согласно какому ГОСТ? В ниженаведеных ГОСТах как 34. так и СПДС всюду упоминается "Схема автоматизации"
ГОСТ 34.201-89 писал(а):Схема автоматизации Код документа С3
ГОСТ 21.408-93 писал(а):4.3 Схемы автоматизации
ГОСТ 21.404-85ПРАВИЛА ВЫПОЛНЕНИЯ РАБОЧЕЙ ДОКУМЕНТАЦИИ АВТОМАТИЗАЦИИ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ писал(а):Настоящий стандарт устанавливает условные обозначения приборов, средств автоматизации и линий связи, применяемых при выполнении схем автоматизации технологических процессов...

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 08:00
CHANt
san писал(а):Это согласно какому ГОСТ? В ниженаведеных ГОСТах как 34. так и СПДС всюду упоминается "Схема автоматизации"
Да нет никаких нтд на слово "функциональная". Я повторюсь, я не делаю раздел ТО.

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 11:08
Степа
CHANt
В принципе путь такой же, только некоторые шаги не совсем такие.
Например, блоков данных "Аналоговые величины" нет, у меня в одной DB сгруппировано структурами по механизмам или по функционалу: например, аварии или состояние механизма 1 /тут все целиком: аварии механизма, состояние, все параметры/. Эти структуры заполняются при обработке входов. Поскольку, у меня принято деление DB на внутренние и для связи с верхним уровнем, то иногда структура "внутренних" и "внешних" таблиц несколько различаются. Например, в текущем проекте обработка температур идет в формате с плавающей запятой и во всех внутренних таблицах все поля температур имеют формат FLOAT, а во внешних - целое. Структуру "внешних" таблиц даю в "Описании программы" /код 13 по ГОСТ 19.ххх/ для разработчика проекта HMI.
Рисунки алгоритмов /хотя бы предварительные/ часто появляются до каких-либо практических телодвижений /по вашему списку - где-то в районе между п.1 и п.2/. Текущее состояние проработки алгоритмов также идет в "Описании программы" /код 13 по ГОСТ 19.ххх/.
Разработка проекта HMI ведется практически параллельно, начинается только попозже, после того как сформируется общее видение системы, сформируются структуры трех DB "Состояние", "Настройки", "Управление".
В DB "Состояние" содержится текущее состояние системы, формируется в конце каждого цикла, запись в него совершенно бесполезна - программа в ПЛК никак не опрашивает текущее состояние этой DB. В DB "Настройки" со SCADA пишутся различные настройки. Обычно предел изменения каждой величины у нас обговаривается заранее и контролируется на ошибку прямо в SCADA, но у меня в программе есть еще один уровень контроля и перенос профильтрованных значений во внутренние DB. Точно так же при работе программа ПЛК этот блок никак не использует. В DB "Управление" обычно битовые сигналы - состояние кнопок, которые прорисованы на HMI. За состояние этой таблицы целиком отвечает SCADA и биты напрямую используются в программе, если это допускается текущим режимом. Например, на состояние кнопки ручного управления программа не обратит никакого внимания, если сейчас включен автоматический режим.
По мере разработки пишется "Руководство по эксплуатации".

Документы по ГОСТ 34.ххх стараюсь не делать: кроме ТЗ тут получается чаще всего стопа почти бесполезной макулатуры, в которой что-то найти постороннему /не разработчику этой стопки, не выучившему эту стопочку почти наизусть/ человеку нереально. Проверено практикой.
Не, если заказчик хочет, то ему выдается "Описание алгоритма" по ГОСТ 34, это не проблема. Но обычно тот, кто видел "Описание программы" уже не желает читать "Описание алгоритма".

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 11:48
san
Степа писал(а):... ГОСТ 19.ххх ...Документы по ГОСТ 34.ххх стараюсь не делать: кроме ТЗ тут получается чаще всего стопа почти бесполезной макулатуры, в которой что-то найти постороннему /не разработчику этой стопки, не выучившему эту стопочку почти наизусть/ человеку нереально. Проверено практикой.
Не, если заказчик хочет, то ему выдается "Описание алгоритма" по ГОСТ 34, это не проблема. Но обычно тот, кто видел "Описание программы" уже не желает читать "Описание алгоритма".
Одного ГОСТ 19 не хватит для всей системы, если эта система включает все уровни АСУТП. А другие документы как?

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 12:02
Степа
san писал(а):Одного ГОСТ 19 не хватит для всей системы, если эта система включает все уровни АСУТП. А другие документы как?
Для программной части хватает. А железная - по ГОСТ 2.
А вот по ГОСТ 34 очень опасно документы делать. Иногда вполне законно разработчик может скрыть часть информации от конечного исполнителя, в строгом соответствии с ГОСТ. Самый простой /и у нас уже выстреливший/ пример: по ГОСТ 34 описание структуры базы данных - это набор таблиц и их взаимосвязь. В нашем случае тут все честно: таблицы, взаимосвязь, типы данных... Но современные СУБД это не только таблицы, это еще и встроенные функции. А вот их описывать ГОСТ не требует и исполнитель на голубом глазу их не описал - зачем лишнюю работу выполнять. Теперь за те функции знает только разработчик.

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 12:08
san
Степа писал(а):А вот по ГОСТ 34 очень опасно документы делать.
Так по тем же ГОСТ34 перчень документов оговаривается в ТЗ, разве нет?
В ГОСТ2 нет, например, схем автоматизации, я так понимаю они вам не нужны? Вы разрабатываете АСУТП?

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 12:21
Степа
san писал(а):Так по тем же ГОСТ34 перчень документов оговаривается в ТЗ, разве нет?
Перечень оговаривается. А их содержание - нет. Вот по ТЗ было "Описание базы данных", исполнитель его сделал. По ГОСТ 34 - только таблицы. Так исполнитель честно расписал все таблицы. А вот за те процедурки - в ГОСТ ни слова. И в доке тоже.
san писал(а):В ГОСТ2 нет, например, схем автоматизации, я так понимаю они вам не нужны? Вы разрабатываете АСУТП?
На моей памяти сколько раз применялись схемы автоматизации, так это только тогда, когда разработчики электрической и программной частей находились достаточно далеко друг от друга и по мере надобностев видеться не могли, обмен электронными письмами - раз в сутки /объекты режимные, с инетом напряги/, по телефону не всегда все можно решить. В таких случаях ведущие по электрической и программной частям садились за один стол и рисовали эту схему /а также первое приближение алгоритма/ - чтобы каждый понимал, что и для чего применяется. Еще по горячим следам делалось описание технологического процесса.

Разрабатываем. Чаще всего небольшие системки /самая большая система управления - пять контроллеров, почти никак не связанных между собой; самая сложная - четыре с кучей связей и панель визуализации/... Есть разработка распределенной системы по сбору данных, но та давно засохла по политическим мотивам /периодически к ней интерес вспыхивает, но как только инициатор понимает, что политически тут никаких бонусов, тут же забывает/.

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 12:26
CHANt
Степа писал(а):Для программной части хватает. А железная - по ГОСТ 2.
На мой взгляд, ГОСТы серии 2 предназначены для комплектной автоматики. Т.е. я покупаю готовый шкаф, к которому привязываю объектовые приборы и механизмы в соответствии с "инструкцией по монтажу, обкатке, пуску, регулированию и обкатке изделия" и настраиваю в соответствии с РЭ. Это типа как поставить всем небезызвестный аппаратный регулятор ТРМ или ПЧ и его настроить. Я же разрабатываю АСУТП проектным путем, и вызвано это тем, что основная работа идет с действующими (20,30,40 лет) объектом, где никто мне не будет переделывать технологию под какие-то стандартные шкафы с определенным набором функций.
Для вновь строящихся объектов, АСУТП в стиле ГОСТ 2 самое то, оно позволяет экономить деньги, так как разрабатывается один раз и потом копируется. Далее, подобные системы, обычно уже сертифицированы, либо выпущены по ТУ, отлажены и ПНР имеет сжатые сроки. Минусы, в случае выявленных сбоев надо ждать новой прошивки. Тем не менее рынок таких систем огромен - посмотрите на АВОК. При разработке ЭД по ГОСТ серии 2 никто не обязывает поставлять документацию к программному обеспечению.
Ну и обсуждение комплектной автоматики к проектному инжинирингу отношение вряд ли имеет.

Re: Проектный инжиниринг

Добавлено: 21 окт 2012, 12:54
Степа
CHANt писал(а):На мой взгляд, ГОСТы серии 2 предназначены для комплектной автоматики.
Да я бы так не сказал... Там и для комплектной системы есть все, что надо, и для собственной разработки. Но только для железа.
А программную часть мы описываем по ГОСТ 19. ГОСТ 2 не обязывает поставлять доки к программной части, ГОСТ 19 никак не рассматривает железо. Но других, лучше - нет. Разве что взять ГОСТ 34 и переработать его, чтобы исключить хотя бы известные мины. Но это будет наш, внутренний документ, следовать которому сторонники в общем-то не обязаны.
Да и зная, как у нас проходит стандартизация, то лучше не браться: не так давно была попытка ввести внутренние требования к текстовым документам. Получился документ, в котором тупо переписаны пара ГОСТ 2 группы и все. Любые попытки ввести некоторые прослабления /например, допустить, чтобы таблицы именовались не только "Таблица", но и "Табл." - так перекрестные ссылки лучше смотрятся/ разбились о стену "в текущей версии ГОСТ этого нет, вот они введут, ну тогда посмотрим...". Из-за этого у нас обычно два комплекта документов: для себя и для нормоконтроля /который потом уходит эксплуатационникам/. Для нормоконтроля документ делается из текущей "для себя". Комплект "для себя" стараюсь поддерживать в актуальном состоянии.