Оплата разработки ПО

Сообщение **hell_boy** » 08 июн 2018, 18:34

Никита писал(а): ↑08 июн 2018, 09:25разработка алгоритмов и ПО ни ГЭСНами ни ТЕРами ни ФЕРами не учитывается и сидит в проектном ценнике. В ПНР только допиливание по месту и привязка.

Логично это так, но 99% проектантов не учитывают разработку алгоритмов и ПО до этапа ПНР. Транснефть, вернее Гипротрубопровод, только с 2015 года начало в проектные сметы включать пункт "Разработка МО и ПО", причем до этапа ПНР разработчик ПО должен сдать разработанное ПО и эксплуатационную документацию "на электронном и бумажном носителях (3 экземпляра)", включая "Формуляр на ПО" (указыватся размер, время изменения, контрольные суммы каждого файла) и "Документированные тексты программ". На этапе ПНР возникает дилемма: менять или не менять ПО? Поменяешь - придется выпускать изменения к документации (формуляр и документированные тексты менять полностью), не поменяешь - работать не будет (спрашивается: зачем сдавать нерабочее ПО до ПНР?).

hell_boy писал(а): ↑08 июн 2018, 18:34 99% проектантов не учитывают разработку алгоритмов и ПО до этапа ПНР

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

Сообщение **Jackson** » 08 июн 2018, 19:50

hell_boy писал(а): ↑08 июн 2018, 18:34 спрашивается: зачем сдавать нерабочее ПО до ПНР

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

А что страшного в том что документацию и ПО придется править? Обычно так не делается?

Сообщение **hell_boy** » 09 июн 2018, 22:50

TEB писал(а): ↑08 июн 2018, 19:52 ПНР - это не создание алгоритмов управления, а только их отладка.

На больших объектах может всякое быть. Например, был случай, когда блочную канализационную насосную станцию (БКНС) поставили без локальной системы автоматики (ЛСА). В ТЗ на АСУ ТП всего объекта было сказано, что с этой ЛСА требуется обмен по протоколу Modbus. Заказчик сам был удивлен, просто умолял автоматизировать БКНС и обещал в будущем отблагодарить. Решили пойти навстречу, делали эту ЛСА из ЗИПа и остатков от предыдущих проектов. Самое интересное, через несколько месяцев шкаф ЛСА БКНС нашелся на другом объекте, логисты перепутали и поставили 2 шкафа ЛСА на другую БКНС. Потом еще несколько месяцев бодались 2 заказчика, так как получивший 2 одинаковых шкафа ЛСА, успел их оприходовать, как ЛСА из 2-х шкафов (основной и резервный). В итоге, через год приехал родной шкаф ЛСА. Заказчик вместо благодарности написал претензию, что ПНР выполнена не в полном объеме, и вызвал на повторные ПНР.

TEB писал(а): ↑08 июн 2018, 19:52 А что страшного в том что документацию и ПО придется править? Обычно так не делается?

Продолжение истории выше. Объем документации на ЛСА БКНС были в районе 200 страниц + 50 страниц основной АСУ ТП. Она была выпущена в 3-х экземплярах, утверждена, сдана заказчику и в архив. Пришлось выпускать извещение об аннулировании всего объема документации на ЛСА БКНС и изменении 50 страниц.

Сообщение **Jackson** » 10 июн 2018, 13:00

hell_boy писал(а): ↑09 июн 2018, 22:50 На больших объектах может всякое быть.

Согласен. Так это определяется договорами и планами. Куда включить создание алгоритмов и программирование - в ПНР или в РКД - определяется ещё на этапе проекта. Я говорил только про случай, придуманный совсем не мной, когда эта работа была включена в стадию РКД, и речь только об этом.
А история неудивительная и типичная. Лишний раз учит тому что "слова к делу не пришьёшь" и что "хороший человек - это не профессия".
Там где люди работают строго в рамках договорных отношений (оформленных договорами с приложениями в виде ТТ) такого не происходит.

hell_boy писал(а): ↑09 июн 2018, 22:50 Продолжение истории выше. Объем документации на ЛСА БКНС были в районе 200 страниц + 50 страниц основной АСУ ТП. Она была выпущена в 3-х экземплярах, утверждена, сдана заказчику и в архив. Пришлось выпускать извещение об аннулировании всего объема документации на ЛСА БКНС и изменении 50 страниц.

Нормальная документация на программную часть только одной АСУ может занимать в несколько раз бОльший объём. Я сам выпускал документацию по несложной системе на 1 ГРЩ на 300 листах. Ничего страшного в этом нет. Были изменения. комплект документации разбивается на разные документы по содержанию и заменяться может не целиком, а единичными документами.

Сообщение **izhidkov** » 10 июн 2018, 13:39

hell_boy писал(а): ↑08 июн 2018, 18:34 разработчик ПО должен сдать разработанное ПО и эксплуатационную документацию "на электронном и бумажном носителя

Сдавать разработанные программы на бумажном носителе это то еще извращение.
Актуальность данного требования стремится к 0

izhidkov писал(а): ↑10 июн 2018, 13:39 Сдавать разработанные программы на бумажном носителе это то еще извращение.
Актуальность данного требования стремится к 0

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

Сообщение **Serex** » 10 июн 2018, 14:45

Никита писал(а): ↑10 июн 2018, 14:02 Программы - соглашусь. А вот алгоритмы - иначе никак. Те же блокировки в энергетике проходят несколько согласований и никто в электронные исходники не полезет.

Зачем электронные исходники. Pdf - отличный формат для передачи документации. Там даже и шифрование с электронной подписью есть, т.е. подделка исключена. Главное чтобы в pdf не растровая графика была, а векторная, как если сразу печатаешь из Autocad. И лично я всему предпочитаю именно этот формат документа, так как для поиска нужной информации есть(возможность) быстрой навигации и поиска. Работа с таким документом в разы быстрее.
Единственный минус - нужен ноутбук или какой-то гаджет.
Если уж так сильно хочется ставить подписи, то сделайте отдельный бумажный лист согласования и пускайте его по круг - сколько елок сэкономите!

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

[+] Чуть оффтоп на тему: Эта привязка к бумаге и подписи, которую весьма легко подделать очень напрягает. Вот сегодня через госуслуги хотел подать заявление на предоставление услуги. Авторизовался в системе, минут 20-30 заполнял кучу полей - адреса, номера паспорта, фамилии, явки...В конце система мне выдает ссылку на скачивание документа ворд, где содержаться все введенные мною данные и обязательным требованием все это распечатать на 10 листах, подписать, отсканировать и приложить к электронному заявлению, затем привезти эту бумагу в МФЦ, когда буду получать результат - вот зачем это нужно? Хорошо хоть хранить в течение 20 лет бумажный экземпляр не требуют )).

Сообщение **ASUTP_PLC** » 10 июн 2018, 15:47

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

Сообщение **izhidkov** » 10 июн 2018, 18:02

Никита писал(а): ↑10 июн 2018, 14:02 А вот алгоритмы - иначе никак.

Алгоритмы это текст программы. Только самый тривиальный алгоритм можно переложить в блок-схему. Все равно что 100 старничный проект Э3 переложить в 1 страничную функциональную или структурную схему Э1,Э2. Вот в ескд обычно прикладывается схема осциллографа фугкциональная - да вот ничего из нее непонятно, как этот осциллограф работает ) Так и с алгоритмами - текст программы это и есть алгоритм.

izhidkov писал(а): ↑10 июн 2018, 18:02Алгоритмы это текст программы.

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

Сообщение **ASUTP_PLC** » 11 июн 2018, 05:35

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

Отправлено спустя 10 минут 32 секунды:

izhidkov писал(а): ↑10 июн 2018, 18:02
Никита писал(а): ↑10 июн 2018, 14:02 А вот алгоритмы - иначе никак.
Алгоритмы это текст программы. Только самый тривиальный алгоритм можно переложить в блок-схему. Все равно что 100 старничный проект Э3 переложить в 1 страничную функциональную или структурную схему Э1,Э2. Вот в ескд обычно прикладывается схема осциллографа фугкциональная - да вот ничего из нее непонятно, как этот осциллограф работает ) Так и с алгоритмами - текст программы это и есть алгоритм.

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

У меня самый быстрая реализация проекта была как-то 45 минут.
Одна картинка, аппаратно связывается контроллер датчик давления, все в ПИД и поехали... с уставками и алармами.
Реально как-то непосебе было... думаю может блокировки какие-то требуются... чего еще там быть должно?
Только нельзя полагать что любой проект бери и эти моменты всегда в такое количество времени решатся.
Чаще всего наоборот. И вообще, платить надо не за копирование решений, а именно за проработку вопросов.
А это никто не любит... Всем надо сразу шашечки и ехать.

Сообщение **Serex** » 11 июн 2018, 08:20

Никита рассуждает о каких-то весьма крупных объектах, где действительно разработку алгоритма и написание программы в силу достаточной загрузки людей выполняю разные люди или даже разные отделы. Но в жизни такое редко бывает - все стремятся все разбить на множество независимых этапов, так удобнее видимо деньги платить/получать. Если технологическая линия, то сделать ее из нескольких независимых установок. Если вентиляция, то несколько отдельных вентустановок взаимосвязанных максимум дискретными сигналами. И так везде. И в каждой отдельно взятой небольшой задаче ну никак не помещается одновременно целый проектировщик, целый программист, целый схемотехник, целый наладчик, целый еще там кто... 1-2 универсальных человека, которые выполняют задачу целиком, только рутинные задачи перепоручают подрядчикам/монтажникам. Качество конечно хуже, чем если организация с кучей людей, разделенных по специализации, ведет проект, но для бизнеса такой подход весьма востребован.
С другой стороны часто имеет место быть подход, когда бумажный проект выполняет один, а работы другой исполнитель, независимый от первого - такой подход крайне нежелательный. Оба будут друг друга обвинять в низкой компетенции на фоне криво-получившегося результата. Но почему-то такое все равно имеет место быть и тем чаще, чем больше задача. Видимо желание разбить на независимые этапы вступает в противоречие с целостностью одной большой задачи.

Сколько денег нужно?
Да относительно немного. Просто есть элементарные вещи, пожрать поспать, и именно там они дорогие.

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

Serex писал(а): ↑11 июн 2018, 08:20 Никита рассуждает о каких-то весьма крупных объектах, где действительно разработку алгоритма и написание программы в силу достаточной загрузки людей выполняю разные люди или даже разные отделы.

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

Serex писал(а): ↑11 июн 2018, 08:20 Оба будут друг друга обвинять в низкой компетенции на фоне криво-получившегося результата. Но почему-то такое все равно имеет место быть и тем чаще, чем больше задача.

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

Ни разу не сталкивались, и что с ним делать не знают.

Сообщение **ASUTP_PLC** » 11 июн 2018, 13:25

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

ASUTP_PLC писал(а): ↑11 июн 2018, 13:25 А что сможете сбацать расчет рекуператора? Вент установки в реале вещь неблагодарная, когда все по расчетам а не с потолка, и все должно биться.

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

ASUTP_PLC писал(а): ↑11 июн 2018, 13:25Технологов грамотных реально исчезающе мало. Когда больше всего знает о технологии один какой-то программист, приглашенный извне, и на предприятии неработал, а технологи кругами ходят, и не видно их вовсе - вот это прескорбно.

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

ASUTP_PLC писал(а): ↑11 июн 2018, 13:25 Правда никогда не видел чтоб проектировщик программеру задачу ставил. Как он это сделает?

А кто еще может задачу поставить, если объекта физически нет, а вся информация о том, как он должен работать только у проектировщика в голове?

Сообщение **ASUTP_PLC** » 11 июн 2018, 14:29

Это опять же... оно так должно быть.
А как раньше было, вот я с чем работал, подходит ко мне проектировщик, и спрашивает. Какое устройство, какой интерфейс,
обо всем расспрашивает, до разъемов. Потом на все дает спеки. И я даю уточнение какой еще модуль заказать.
Потому что вся пусконаладка моя, а не проектировщика. Вот вам и объекта физически еще нет...

Отправлено спустя 3 минуты 12 секунд:
Хотя с такими кадрами намного лучше срабатываемся, чем те кто самые умные, вот дают проект.
Чего-нибудь надо уточнить - иди читай документацию. Сам я тебе фиг чего скажу. И не важно, сопливого проводка вопрос,
или дополнительный выход с каким интерфейсом.

Сообщение **petr2off** » 11 июн 2018, 14:53

izhidkov писал(а): ↑10 июн 2018, 18:02
Никита писал(а): ↑10 июн 2018, 14:02 А вот алгоритмы - иначе никак.
Алгоритмы это текст программы. Только самый тривиальный алгоритм можно переложить в блок-схему. Все равно что 100 старничный проект Э3 переложить в 1 страничную функциональную или структурную схему Э1,Э2. Вот в ескд обычно прикладывается схема осциллографа фугкциональная - да вот ничего из нее непонятно, как этот осциллограф работает ) Так и с алгоритмами - текст программы это и есть алгоритм.

izhidkov писал(а): ↑10 июн 2018, 18:02 Алгоритмы это текст программы. Только самый тривиальный алгоритм можно переложить в блок-схему. Все равно что 100 старничный проект Э3 переложить в 1 страничную функциональную или структурную схему Э1,Э2. Вот в ескд обычно прикладывается схема осциллографа фугкциональная - да вот ничего из нее непонятно, как этот осциллограф работает ) Так и с алгоритмами - текст программы это и есть алгоритм.

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

Сообщение **Jackson** » 12 июн 2018, 07:01

izhidkov писал(а): ↑10 июн 2018, 13:39
hell_boy писал(а): ↑08 июн 2018, 18:34 разработчик ПО должен сдать разработанное ПО и эксплуатационную документацию "на электронном и бумажном носителя
Сдавать разработанные программы на бумажном носителе это то еще извращение.
Актуальность данного требования стремится к 0

Ничего подобного. Вы просто не были в ситуации когда работоспособность убитой системы восстанавливается с нуля именно с бумаги в кратчайшие сроки при минимальных затратах. Причём необязательно сдавать в архив тома документации - достаточно PDF. Совсем-то не надо до идиотизма доводить, не бумагу надо тратить, а описательную часть делать нормально и складывать в доступные места.
У меня был случай (и не один) когда я на объекте в составе ЭД нашёл листинги на бумаге, что сэкономило мне уйму времени при ремонте полностью убитой системы.

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

Сообщение **ASUTP_PLC** » 12 июн 2018, 12:11

Интересно, параметрирование модулей к чему относится. Или коэффициенты когда к примеру аналоговый модуль от 0..20мА обрабатывает сигнал 0...5мА. К разработке ПО, или к функциональной схеме?

Сообщение **Serex** » 12 июн 2018, 22:50

TEB писал(а): ↑12 июн 2018, 07:01 Вы просто не были в ситуации когда работоспособность убитой системы восстанавливается с нуля именно с бумаги в кратчайшие сроки при минимальных затратах.

Ужас! У всякой приличной программной вещи должен быть бэкап! Варианты бэкапа варьируются в зависимости от системы. В руководствах (нормальных) всегда предусмотрена глава - создание бэкапов/восстановление из бэкапа.
А для нынешней автоматизации, когда все лежит внутри проектов, место листингов следует использовать именно проекты. В архив их и серверное хранилище с RAID массивами.
Мне даже представить сложно, как можно в листинг положить проект от какого-нибудь сименса S7-300.

Serex писал(а): ↑12 июн 2018, 22:50Мне даже представить сложно, как можно в листинг положить проект от какого-нибудь сименса S7-300.

Вот лежат у меня на диске архивы проектов в TraceMode 5.12. И периодически думаю, не удалить ли. Чтобы понять, как работает система, надо найти LPT-порт, драйвер ключа, совместимую ОС, поставить ТМ, только тогда посмотреть.
С сименсом та же история.

Сообщение **Jackson** » 13 июн 2018, 00:02

Serex писал(а): ↑12 июн 2018, 22:50 Ужас! У всякой приличной программной вещи должен быть бэкап!

Чего-чего?

Это Вы про идеальный мир рассказываете, в реальности всё несколько иначе.

Вот конкретно моя история, на производстве стоит станок с ПЛК. Станок купили N лет назад подержанным далеко не из первых рук. Всё это время он нормально работал, и вот сдох ПЛК.
Какие бэкапы? Вы о чём? Кто их делать будет? Из станка всё это время выжимали производительность разные владельцы.
Пока подняли все концы, добрались до производителя (станка) и он давно уже закрылся. И какие варианты? Либо покупать новый шкаф автоматики за баснословные деньги, либо станок целиком. Но только благодаря твёрдым копиям на бумаге. был куплен только ПЛК и код вбит вручную с бумаги - времени ушло всего сутки. Все другие варианты сводились бы к свертыванию производства, потому что новый станок просто не потянуть по деньгам.

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

Отправлено спустя 30 секунд:

Никита писал(а): ↑12 июн 2018, 23:54 Вот лежат у меня на диске архивы проектов в TraceMode 5.12. И периодически думаю, не удалить ли.

Основное правило ремонта: "никогда ничего не выбрасывай".

Сообщение **Serex** » 13 июн 2018, 06:47

TEB писал(а): ↑13 июн 2018, 00:02 Какие бэкапы? Вы о чём? Кто их делать будет? Из станка всё это время выжимали производительность разные владельцы.

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

Отправлено спустя 7 минут 37 секунд:
Но так да - согласен, что бывают гораздо худшие условия эксплуатации и тогда ремонт происходит из того что есть под рукой, а не как надо.

Отправлено спустя 4 минуты 39 секунд:

TEB писал(а): ↑13 июн 2018, 00:02 Основное правило ремонта: "никогда ничего не выбрасывай".

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

Сообщение **Jackson** » 13 июн 2018, 22:36

Логично же что однажды поставленное оборудование рано или поздно придётся обслуживать или ремонтировать, или ещё что-нибудь. И в этот момент всё может упереться в отсутствие оснастки, то есть хитрых кабелей, документации, копий, листингов. Или не это оборудование а очень похожее и в другом месте.
Слыть старьевщиком никто не хочет, лучше конечно просто взять и купить новое, оно и солиднее и приятнее. Что интереснее: новую лучшую квартиру купить или имеющуюся ремонтировать - понятно же.
Однако «нехватка материальных средств ведёт к дисциплине мышления» - складываешь, упорядочиваешь, ждёшь когда пригодится. Как опыт показывает, ломается все в самый неудобный для этого момент, и в этот момент абсолютно любая ерунда которая есть под рукой (или нет) может решить судьбу целой фирмы, а какая именно ерундовина станет решающей - предугадать не получается.