Писать не писать ПО...

[Raiken]

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

Вот листаю нормативку, конкретно ГОСТ 34.201-89 "ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ" и РД 50-34.698-90 "АВТОМАТИЗИРОВАННЫЕ СИСТЕМЫ. ТРЕБОВАНИЯ К СОДЕРЖАНИЮ ДОКУМЕНТОВ" вроде бы там только описание ПО есть, в который текст программы не входит.

Собственно сейчас вижу оптимальный вариант написать ТЗ на доработку ПО и вложить в комплект документации.

Подскажите как быть, кто прав кто виноват, и вообще:)

[Alexander]

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

[Alexander]

Гы. Я тоже не институт, и всю жизнь разрабатываю. Правда, я делаю все, от первой линии на схеме. И не дай бог чтобы мне кто-то нарисовал картинки, где с одной стороны торчит хвост от Профибаса, а с другой от Модбаса.

[Trkoff]

Скользкий

[Trkoff]

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

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

Мое мнение. Проектировщик ДОЛЖЕН делать проет АСУТП включая ППО.

[Trkoff]

Вот эта тема:
Список форумов‹ АСУТП в промышленности ‹ Общие вопросы ‹ Авторский надзор и промышленная безопасность

[Trkoff]

Вот и попляши при этом раскладе на ПНР, полностью переделывая проект на коленке (как правило, такие подлянки только там выясняются).

А если ППО писать на стадии проекта (нормально писать, а не только требоваия ГОСТа обеспечивать!), а не на коленки в ПНР, то такие подлянки на ПНР-е не появятся!
По-моему, факт! :-)

[Trkoff]

Борис, все бы хорошо, но проектные институт от слов разработка ППО шарахаются как черт от ладана :) Ну и ты не так давно слышал мнения про "полигоны" блин, даже забыл то слово которым их обозвали... :) и кто будет себе подрядчика выбирать- институты? Они таких выберут..ты знаешь :)
Про подлянки. Да появляются. Потому что о них генпроектировщик не знает, его подрядчик не знает и на бумаге все правильно. А по факту привозят другое железо уже на площадку. В последний момент привозят.
ХЗ. Я хочу чтобы все по-правльному было, очень хочу. Но жизнь ставит свои коррективы. Идеальных фирм не бывает. Ну, это про крупные проекты.

Да уж... С тобой не поспоришь. Тем более, что так и есть. Но ведь можно, требуя от проектировщика ППО, предлагать ему на подряд фирму, которая может это сделать, например - победитель тендера на ПНР.
Ну это так, к слову. Мол какое небо голубое... :-)

[Никита]

вопрос из двух частей - непосредственно продукт и алгоритмы. Второе - однозначно за проектными институтами. Равно как и все уставки, настройки (ну кроме тех, которые непосредственно в компетенции наладчика, типа коэффициентов в регуляторах). Реализация - как в ТЗ прописать, но у нас на полуострове все крупные заказчики торгуют услуги по готовым проектам, ПО включается в услуги и остается подрядчику.
А листать надо договор вместе со сметой - если проектный институт за ПО, МО и прочее деньги взял - пусть веселятся.

[Trkoff]

Борис, это ж не по процедуре :) А чтут у нас только процедуру эту дебильную а не здравый смысл. Недавно вот тендер проводили. Заявилось несколько фирм. Из них 80%- шелуха, вообще без опыта подобных работ. Мало того, они и участвуют ради участия. Потому разброс цен- колоссальный. Аж пятикратный. А прикинь, если совсем запроцедуриться и отдать выбор нашим чинушам...выберут любого по наименьшей цене- им пофигу результат, там процедура ж!

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

Но вопрос то про ППО...
Мое убеждение: ППО должно разрабатываться на стадии проектирования. Кто и как - другой разговор...
ПНР - это время для его отладки на объекте.

[Alexander]

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

[Raiken]

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

[Никита]

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

Alexander, а я не видел чтоб нормально работало ПО, разработанное вдали от объекта. 60% ПО разрабатывается на объекте и в гостиницах :)
Я писал про формальный признак - алгоритмы, кроссировка, уставки и пр. - все равно в ведении проектных контор. Уставки ПАЗ за подписью ГИПа - вообще идеальный вариант. В любом случае окончательно вылизывать будет наладчик, тут никуда не деться. Но алгоритмы в проекте быть обязяны, и согласованные со службами Заказчика на предмет соответствия регламентам работы оборудования. Плюс хотя бы наброски, без привязок, "веселых картинок".
Исключение - вариант с работами "под ключ", когда алгоритмы придумывает и реализовывает и отлаживает одна и та же контора, а часто и один и тот же человек - тогда и глаза закрывают на алгоритмы в виде FBD-шек, и параметры согласовываются в процессе работы и корректировки по ходу возможны, но это уже совсем другая история.
В общем мое мнение - проектному институту денег за фактическую разработку ПО не платить, только необходимый минимум за который отвечает проектировщик. А институту соответственно ПО не делать, потому как в отрыве от жизни ничего хорошего из этого не выйдет.
Проектную смету разбить на две - очень грубо - ТО и ПО. Первая - проектировщику, вторая - наладчику.

[Trkoff]

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

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

[Trkoff]

Что? От лишних знаний лишние печали?
Это точно....
Вот, например, http://promavtomatika.com/show/1538/event31052011.pdf
Не понимал бы что это и не печалился бы...

[Никита]

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

[Барий]

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

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

[Никита]

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

Не соглашусь. Как раз сложные алгоритмы, особливо регуляторы с кучей корректирующих импульсов, не говоря уже о нечетких, адаптивных и т.п. ни один теоретик нормально не распишет. Да и технологи толком динамику объекта редко себе представляют. А уж про особенности работы конкретных блоков конкретного софта - так вообще разговора нет. Вот и появляется уникальный кадр, полупрограммист-полуналадчик-полутехнолог-полуасушник-полуКИПовец (итого 2,5 человека обязанностей на одно лицо).

[Trkoff]

Еще раз прочитал эту тему. Странная какая-то получается ситуация.
С точки зрения автоматизатора проектировщик не в состоянии ни написать ПО, ни проработать алгоритмы управления.
Но ведь говорим про проект в части автоматизации объекта строительства!
Значит проектный институт не в состоянии разработать эту часть проект?
А теперь с точки зрения технолога. Ну откуда проетировщик (т.е. теоретик с точки зрения технолога!) может знать все тонкости технологического процесса?
А еще есть энергетики и т.д.
Бедные ГИПРы...
А с другой стороны, отчего же бедные? За проектную работу платят же! :-)

[Никита]

Еще раз прочитал эту тему. Странная какая-то получается ситуация.
С точки зрения автоматизатора проектировщик не в состоянии ни написать ПО, ни проработать алгоритмы управления.
Но ведь говорим про проект в части автоматизации объекта строительства!
Значит проектный институт не в состоянии разработать эту часть проект?

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