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

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

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

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

Если у вас в ТЗ есть требования делать по тем гостам, то заказчик прав.
На какие госты заказчик ссылается? Возможно они уже отменены

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

Мы сами для себя, от имени Заказчика составляем техническое задание на программирование. что б не было потом вопросов что чтото работает не так. Заказчик это все подписывает и дает нам а мы программируем якобы по его тех заданию. Это как пояснительная записка - описание логики и работы системы в целом. А кто каким оборудованием и как это будет программировать никого не интересует, главное что б система работала так как написано в тех задании...

Дык пропишите просто алгоритм работы (блок-схемой или хотя бы графами)

Что-то непонятно..
Программы вы будите писать или заказчик?
Если не вы, то обязаны привести алгоритмы и циклограммы работы, а то потом замучаетесь искать крайнего верблюда..
Я например зака не понимаю, или совсем осел, или хитрый барыга который потом на вас с претензиями будет наезжать

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

А он прав, заказчик. За программирование бабло срубили, теперь предоставьте документацию, согласно правилам.
Можно отлично поиздеваться и получить удовольствие, если владеешь темой.

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

Топикстартер, а может этот норматив с пунктиком испросить у заказчика? Есть шанс, что заказчик смотрит либо в устаревший, либо в не имеющий отношения к теме гост.

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

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

В нашем родном ГОСТ 21.408-93 "ПРАВИЛА ВЫПОЛНЕНИЯ РАБОЧЕЙ ДОКУМЕНТАЦИИ АВТОМАТИЗАЦИИ ТЕХНОЛОГИЧЕСКИХ ПРОЦЕССОВ" никаких алгоритмов программ нет, но это так - для приватной беседы с Заказчиком.
А Заказчик может хотеть что-то только на основании договора или ТЗ к договору.
Соответственно, делаете большой титульник со словами "Указание рабочих алгоритмов" - и вставляете туда вашу поясниловку из проекта. Але - оп, так сказать.
А вообще вам юриста надо, сейчас без юриста можно много бессмысленно работать, все умные стали.

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

Есть "умельцы"...
Часть листа из проекта(РД) на ИТП, на титульном листе штамп - "К производству работ", без поясниловки, как догадаться как работают МЕ1 и М1,2 ?

А функциональная схема есть?

Функциональной схемы нет.
РД из 7 листов А3 большими буквами. Вместе с титулом.

И почему монтажник-наладчик должен догадываться о чём-то?

Итог - МЕ1 - регулятор температуры, управляется ШИМ(в схемке написано "открыто-закрыто"), М1,2 - электромагнитные запорные клапана, закрываются то ли при превышении давления, то ли при понижении(протечка)-ещё не догадался....

Хотел бы согласится.
Как минимум Вам нужно знать технологию, Заказчику на данном этапе не обязательно.
И учтите одна и та жа заточенная программа на каждом объекте ведет себя по разному.

Зависит от того, что Вы должны выдать заказчику по договору.
Если речь идет о РД (рабочей документации), то в неё описание алгоритмов не входит. Однако "ГОСТ 34.201-89 ВИДЫ, КОМПЛЕКТНОСТЬ И ОБОЗНАЧЕНИЕ ДОКУМЕНТОВ ПРИ СОЗДАНИИ АВТОМАТИЗИРОВАННЫХ СИСТЕМ" предусматривает создание технического проекта (ТП) куда входит описание алгоритмов, комплекса технических средств и применяемого ПО. Состав можно посмотреть тут

Ага, а вот алгоритм работы, ежели коллеги не могут (читаем - не хотят) предоставлять программу, можно и описать блок-схемой или графами

А вот интересно, согласно "ГОСТ 34.201-89 для конфигурируемых контроллеров (типа REGIN Corigo) также необходимо выписывать алгоритм? Даже при том, что он задан на заводе-производителе ПЛК?

Если Вас "сдало" ваше начальство, то лично Вы уже ничего Заку "доходчиво объяснить" не сможите. Просто уровень не тот. Да и борзеть не надо...Это Зак борзеть может - он деньги заплаптил. А наше с Вами дело телячье - хотите карту - получите.
Лично я просто распечатал бы какую-нибудь "толстую" программу из прошлого проекта, да и всё...
Сами ж понимаете - стадия "П". Это ж наполовину комиксы.

У ПО CARE (Хоневелла), например, есть функция print out программы - после выделения нужных разделов она формирует данные по программе для контроллера в печатном виде, может и у вашего ПО есть такая же функция? или как вариант пришлите нам функционалку мы подберем чтото похожеее, я уверен что Заказчик в этом не разбирается, ему главное абы було. если он вас выганит через месяц. то чтоб его фирме были предоставлены все данные для доделки и ТО системы. а как эти данные должны выглядить он и понятия не имеет.

Коллега ошибся в стадии - не П, а рабочка.
Данная Рабочка включает и функционалки, и структурную схему объекта, и полные схемы шкафов (не схемы внешних подключений, а полные принципиальные схемы) и описательную часть на СУДИО.
Денег за программинг никто не брал.
"Темноты" нет нигде. Выдать порядок работы системы в виде графов - то есть представить установку в виде конечного автомата? Какого? Машины Тьюринга, или скорее автомата Мили, задав пятимерный вектор - кортеж состояний, воходов, выходов и пр.? Делать таблицу условий перехода для графа? Но кроме конечных состояний (включен, выключен, прогрев, авария итд) на выходах контроллера есть еще и аналоговые сигналы регулирования. Прописывать передаточные функции регуляторов?
Тут упоминалось, что стандартная программа не факт, что отработает на конкретном объекте - верно. И если честно - за последние лет 5 ни разу не видел рабочку по автоматике, которая содержала бы чтото хотя бы отдаленно на это похожее. Не говоря о таблицах по закладным устройствам, данных по подбору клапанаов и дифманометров согласно ГОСТ 21.408-93 -обычно все это по типам и размерностям сложено в спеке на систему.
Мы, как правило, прикладывали таблицы сигналов на входах и выходах контроллера. Для программиста HVAC этого в принципе всегда было достаточно, потому тут ситуация как со спортом - здоровому он не нужен, а больному только во вред.
А то, что мы "не хотят" отдавать исходники - так на рабочке это и не делают (ну или отпишитесь те, кто делает - посмотрим процент от общего числа). Да и зак отказался иметь листинги для стандартных программных модулей - мы бы дали, жалко чтоли...
В общем - если есть, чем действительно помочь даже на уровне совета - будем весьма благодарны.
Не_программист.
PS: В аттаче вариант буржуинской версии инжиниринга приточно-вытяжной устновки - типа минипроект (ни в коймере не реклама брэнда).

У ПО CARE (Хоневелла), например, есть функция print out программы - после выделения нужных разделов она формирует данные по программе для контроллера в печатном виде, может и у вашего ПО есть такая же функция? или как вариант пришлите нам функционалку мы подберем чтото похожеее, я уверен что Заказчик в этом не разбирается, ему главное абы було. если он вас выганит через месяц. то чтоб его фирме были предоставлены все данные для доделки и ТО системы. а как эти данные должны выглядить он и понятия не имеет.

Здравствуйте.
Я уже писал что листинг программы сдаю обязательно и ни когда ни каких паролей, если только посредники не требуют. В принципе я за полностью открытые системы. Мне попадалась документация где в пункте прницип действия установки были описания программных модулей и сами модули отрисовывались приметивными алгоритмами ввиде блоков. Что Вам мешает зделать также . Например - по сиглалу пуск на вход Х0 происходит запуск какойто там установки с поддержанием давления, далее принцип действия ПИДа или что то в этом духе. На сколько я понял это им надо для полного представления работы установки, но вот то что листинг не нежен. Извините если что не правильно понял.

Если в Вашем проекте содержатся конфигурируемые приборы, которым при пуско-наладке нужно задать один из нескольких режимов работы, выбрав определённые пункты меню или установив определённые джамперы, то для каждого из них должна быть карта программирования, где расписано по пунктам меню что нужно выбрать пусконаладчику. Шпаргалка своего рода. Без неё он, например, скорость обмена по линии RS485 и адрес прибора сам не родит. И могут быть другие пункты, для каждого типа приборов.
Наверное это имел в виду Ваш заказчик.

Ясам сдаю шкаф автоматики( вентеляция чистых помешений). Принципиальная схема шкафа. И пароль 1 уровня Kieback&peter. И на этом все. Отдельно паспарта от датчиков что мы используем. Ни какаго софта или прошивки. Эта наша интелектуальная собственность . Мы и сервис ведем .

Если в ТЗ указан какой то гост или подобное, не имеет никакого значения действует ли он, или нет, придётся выполнять его требования. Найдите этот гост и посмотрите что от вас требуют. Это вполне может оказаться какой нибудь мелочью вроде списка настроек вашей системы. Если гост не указан, под этой "картой" Вы вправе понимать что угодно. ведь этот термин никак не определён в договоре и ТЗ.

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

Есть такая профессия, технописы, и к ним нужно относиться с опаской. Всем известной фразой в ТЗ "интуитивно понятный интерфейс", подрядчика можно нагнуть по полной.

Лично мы вот так делаем.
Как только закончили пусконаладку. У нас все работает. Мы говорим заказчику нам нужны ваши спецы на обучение. Показываем где что стоит.кто чем управляет . И кто и что измеряет. И это все под запись. Потом отдельно лекция про "мозги" .говорим сразу что все закрыто паролем. Вам пароль 1 уровня такой-то. Вы можете сделать только это( поменять уставку температуры) и на этом все. Они сами при нас пробуют. Пишем акт о проведение обучения и все. И те конспекты что они сами писали это и есть инструкия для них. Дальше они не лезут. Мне только сообщают номер если где то какая то авария. Я по телефону говорю что сделать.

Сразу оговорите, если изготавливаете лифты.

Климат чистых помещений.

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

Если программа делалась специально для вас и под ваши требования и вы за это заплатили денег - это да. Полностью согласен.

А если вам поставили ИТП, работающий по типовым алгоритмам, за которые с вас никто денег на самом деле и не брал (брали за ПНР/настройку), то вы не правы.

Покупая Windows никто вам исходников от неё не даст. Так и с типовыми алгоритмами - они потому и типовые, что кто-то потратил туеву хучу денег и времени, а теперь потихоньку их отбивает, имея окупаемость 10-20-100-200 объектов.

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

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

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

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

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

Буратин везде хватает! И количество заповедников, где они плодятся, постоянно увеличивается.

+100 500 !!! Трижды !
они, видите ли, за разработку ПО платить не хотят, а исходники им подавай... купите ЧП и запросите у производителя код программы - вас пошлют дальше, чем вы видите

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

на какие "древние ГОСТы" он может сослаться, если понятие "программирование контроллера" ни в одном ГОСТе не определено за "древностью" последних... И уж тем более - как в ГОСТАх 70-ых годов рождения буде быть написано :"чтобы любой .... программист ....мог ...всё это потом запрограммировать".... .... Тогда и слов таких то никто и не знал!!... а "автоматчиские" ГОСТы только переиздаются с теми же картинками и ошибками... Новых - выпускать некому... Короче - развёл Вас Заказчик как лохов... По старой схеме -"однабабасказала"! ... что в прочем и не удивительно - раз у Вас такие "специалисты", что собственной нормативки не знают - что там реально написано, а что в-принципе написано быть не может...

Покупая Винду, ЧП, или ещё какой "телевизер" - Вы покупаете готовое изделие... имеющее сертификат соответствия и внесённое в реестр РФ... точно также - если покупаете модульную насосную установку, или например - модульную котельную...Поэтому производитель данной продукции меет полное право продавать изделие "как есть"... без дополнительной про него информации...Как очевидный пример - Вы в проекте не разрабатываете рабочие чертежи, например - насоса... Вы просто марку его указываете и "монтируете" по тех.документации... а вот шкафы автоматики - Вы разрабатываете в составе проекта!! А не вносите - как покупное изделие!!
Однако - это ещё не основание для того, чтобы требовать программный продукт любого вида! Ибо ничего в ГОСТ 21.408-93 СПДС про подобное - нет! Ента библия четко прописывает в Главе 3 и Главе 4 - что конкретно входит в состав проекта. Ни слова про программирование контроллеров - там нет. Ни в виде языка формальной логики (графы, блок-схемы), ни в каком другом виде. Что понятно для любого нормального проектировщика, хотя бы формально знакомого с действующей системой проектной документации. Потому как логика - проста и очевидна: в нормативах не просто прописывают - что "писать", а ещё и обязательно - "как" писать! Т.е. если есть требование выполнить, например, принципиальную схему, то есть, соответственно и ГОСТ - как именно енту принципиальную схему выполнять... Никаких "правил" выполнения каких-то там "прошивок" и "программ" - данный ГОСТ не содержит. Соответственно - выполнить то йх, наверное и можно - если сильно захочется - а вот как оформить и как внести енти "художества" в действующий проект автоматики? Который выполняется ТОЛЬКО по ГОСТ 21.408-93 СПДС, а не как комиксы - чтоб "красиво" было... ГОСТом не предусматривается красиво "разрисовывать" проект какой-то посторонней информацией в произвольной форме... эта вам документация, а не комиксы, или рекламные буклеты...А если, для удовлетворения требований Заказчика, придётся дополнительно к "стандартному" тому автоматики ещё какие-то комиксы" выпускать - ну так не проблема!... Платите бабки! Если заплатили за разработку проекта автоматики - получите томик автоматики по ГОСТ 21.408...а если хаказывете разработку програмного обеспечения - то и получите томик программного обеспечения... в конкретном составе и оформленном по "своим" ГОСТам... причем здесь автоматика то?... а завтра Заказчик захочет часть электрики в томе автоматики увидеть... и что?... у электрики - свой томик, у автоматики свой... у програмного обеспечения - свой... что непонятного то?

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

Я могу ошибаться, но не все изделия подлежат "профильной" сертификации ... но сертификат соответствия - как на любой товар - они иметь обязаны... иначе ето либо контрафакт, подделка
(если у нас производится), либо контрабанда (если из-за рубежа ввозится)... т.е. если товар не включен в реестр РФ - как товар, то ето либо заказное изделие, изготавливаемое штучное (а не серийно по ТУ - а соответственно и не может выпускаться партиями), либо контрафакт...

Вы таки удивитесь, но первые программисты появились еще для МЭСМ, БЭСМ-6. ЕС ЭВМ как бы в 60-х. Почитайте Стругацких "Понедельник..."




Если вы посмотрите начало упомянутого ГОСТ 21.408-93 СПДС, то в перечне нормативных ссылок увидите "ГОСТ 34.201-89 Информационная технология. Комплекс стандартов на автоматизированные системы. Виды, комплектность и обозначение документов при создании автоматизированных систем" в котором в перечне документов Технического Проекта указаны:
- Описание автоматизируемых функций;
- Описание информационного обеспечения системы;
- Описание организации информационной базы;
- Описание программного обеспечения;
- Описание алгоритма (проектной процедуры);

а в перечне РД:
- Описание технологического процесса обработки данных (включая телеобработку);
- Программа и методика испытаний (компонентов, комплексов средств автоматизации, подсистемы, систем)

и это не учитывая документы ГОСТ 19101-77 Виды программ и программных документов по которому текст программы является обязательным документом Рабочего Проекта.

Ну - давайте посмотрим в "начала документа":
1 ОБЛАСТЬ ПРИМЕНЕНИЯ
Настоящий стандарт устанавливает состав и правила оформления рабочей документации систем автоматизации технологических процессов и инженерных систем (далее - систем автоматизации) проектируемых объектов строительства различного назначения.
Требования настоящего стандарта распространяются на рабочую документацию технического обеспечения АСУ ТП, разрабатываемую по ГОСТ 34.201.
Стандарт не распространяется на рабочую документацию систем автоматизации централизованного управления энергоснабжением."
т.е. как бы намекают - проект автоматики - он по ГОСТ 21.408.... а проект АСУ ТП - не только по ГОСТ 34.201, а ещё и по ГОСТ 21.408.... Из чего следует, что при выполнении отдельного проекта по автоматики выполняем требования только ГОСТ 21.408... а вот при выполнении проекта АСУ ТП - и по ГОСТ21.408 и по ГОСТ 34.201...
Но - ето как бэ намекают... а что же пишут "черным по-белому" спесиально для нехрамотных?
"3.2 В состав рабочей документации систем автоматизации включают:
- рабочие чертежи, предназначенные для производства работ по монтажу технических средств автоматизации* (основные комплекты рабочих чертежей систем автоматизации марок А..., приведенные в приложении А);
- эскизные чертежи общих видов нетиповых средств автоматизации;
- спецификацию оборудования, изделий и материалов (далее - спецификация оборудования)."

ф-с-ё!... ничего другого в проекте автоматизации нед... для отсебятины - есть другие томики проектной документации....
при этом, правда, ИСКЛЮЧИТЕЛЬНО по писменному требованию Заказчика, ещё выполняют:
"3.3 Одновременно с рабочей документацией систем автоматизации разрабатывают техническую документацию на изготовление и поставку на объект строительства технических средств автоматизации, в том числе:
- опросные листы на приборы;
- карты заказа на электроаппараты;
- таблицы соединений и подключения проводок в щитах и пультах*;
- документацию для заказа комплексов средств централизованного контроля и регулирования, телемеханики, вычислительной техники, программно-технических комплексов, микропроцессорных средств и контроллеров, систем и установок пневмоавтоматики и др. (далее - комплексы технических средств**). "
т.е. - как видите - никакого "чебурашки" тут нет...

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




А кроме Стругацких в каком-нибудь ГОСТе 70-80-х годов есть определение - что такое биопол..тьфу, ты- Хосподи - что такое "программирование контроллера".... я, конечно, понимаю, что ето уже тохда было настолько всем "понятно", что рассуждать о етом (а собственно - а о чем?) мог любой, даже писатель... осталось только получить четкое определение - чем "программирование контроллера" фантастов Стругацких отличается от конкретных выполняемых действий... в частности - если я "программирую контроллер", то значит ли ето, что я обязан выпускать какой-то проект про то, что я напрограммировал... или я должен просто забить программу из проекта?... тогда кто из нас проектирует - тот кто проект выпускает, или тот, кто готовую программу вбивает... тогда почему первый - проектировщик и он за проектирование деньги получает, а второй - пусконаладчик и он за программирование контроллера деньги получает? Кто из них кто?...

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

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

Это вопрос не ГОСТов - это вопрос договора между исполнителем и заказчиком.
Если кто-то промахнулся - где-то что-то не учел и т.д. - то надо исполнять согласно договору.

Из личного опыта - фирма заключила договор на поставку систему автоматизации. В договоре был учтен частотник, насос и шкаф. Ни командировок, пусконаладок. В итоге был гигантский финансовый минус.
Вот к чему приводит заключение договора в ресторане под водочку.

2 DC-RU

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

ИМХО Это проблема даже не исполнителей (их желания понятны), а Заказчика, у которого даже нет понимания, что и в каком виде из тех документации необходимо иметь. Иначе бы все прописывалось в контракте на поставку оборудования. Кто из исполнителей не согласен - тот свободен...найдется другой.

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

Фирмы, выпускающие контроллеры (например Овен и МЗТА), делают их в 2-х исполнениях.
1-е: Контроллеры с предустановленной программой под различные типовые функциональные задачи. К ПЛК идёт руководство по применению, общее описание алгоритма работы, не более.
2-е: Свободно программируемый контроллер (ПО для программирования раздаётся даром).
Если я ставлю в шкаф 1-й ПЛК, то передаю в комплекте шкафа его руководство по применению. А если я считаю, что заданная в тамошнем алгоритме, например, фиксированная пауза в 5 секунд при пересменке насосов слишком велика? Я покупаю свободнопрограммируемый контроллер, пишу полностью аналогичный алгоритм, но с паузой 2 секунды. Что я должен передать заказчику? Если больше, чем в 1-м случае, то в какой момент у заказчика, при исполнении той же задачи, возникает право требовать какие-либо дополнительные документы (по сравнению с первым случаем).

Был момент работал на заводе по производству кирпича. Стаяло больше 10 PLC от мицубиси. Модель не помню. Так у нас был ноут в котором был софт и прошивки на контроллеры. Сначало это были дискетки на3,5 потом это переписали на диск. При этом ноут старый 486 был в работе еще. Кагда один из PLC сгорел поменяли на новую версию купили новый софт. Сами переписали программу и все.
Это я к тому что если под вас пишут софт то вам и отдадут. А если у вас овен трм... то максимум это листочек где написано в какам пункте меню что забито и все . А вот как этими данными трм работает вам некто не обязан рассказывать и показывать:-)

Такой вопрос возник околотемный. Если проектанты не закладывают в проект программирование, и стоимость ПО для программирования, а всё это скрывается под туманной формулировкой пуско-наладка, за которую естественно никто не даёт денег которых эта работа и стоимость ПО стоит. Что делать? Где искать концы? На каком этапе этот вопрос должен решаться и с кем? Просто 9 контроллеров tac xenta + 27 модулей I/O, всё это должно работать в комплексе взаимосвязано, они сами по себе стоят кучу денег, ПО для программирования стоит столько, что хочется промолчать плюс нужно заплотить специалисту который сможет это всё заставить работать как надо, не хилый такой труд. Сколько такая работа вместе с ПО должна стоить?
Начинаю задумываться не топик стартер ли проект делал))))))) xD