Устранение неисправностей в коде во время ПНР

[alldendy]

Здравствуйте, коллеги!
Возник спор с подрядной организацией на этапе ПНР САУ:
Производится автономные (индивидуальные) испытания шкафа САУ, согласно программы и методики испытаний. Во время проведения проверки, в алгоритме работы выявилась неисправность. Программист подрядчика, "перезалил" контроллер. Предлагается проводить дальнейшую проверку с того места, где закончили, когда была выявлена неисправность (то есть, когда "прошли" 70% ПМИ).
Мнение заказчика такое: "перезалили ПО контроллера - начинаем проверку алгоритма заново".

Вопрос: какой нормативной документацией подтвердить мнение заказчика?

[keysansa]

Оффтоп, не против удаления.

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

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

ЗЫ. ГОСТ 24.104-85 действует ли он?

3. ВИДЫ И ПОРЯДОК ПРОВЕДЕНИЕ ИСПЫТАНИЙ ПРИ ВВОДЕ АСУ В ДЕЙСТВИЕ

Почитал, там разработчик вообще как раб )
Сам всю жизнь исполнитель в частных структурах.

[alex-tec]

Вопрос: какой нормативной документацией подтвердить мнение заказчика?

Так-то этот момент должен быть в ПМИ прописан, а вообще - тесты заново

[keysansa]

а вообще - тесты заново

А по поводу НПА по этому вопросу?

[Jackson]

Вопрос: какой нормативной документацией подтвердить мнение заказчика?

Ответ: этим документом является счёт на оплату договора поставки/ПНР. Кто платит, тот и заказывает музыку.

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

А теперь, смотрим:

Не неисправность выявили (в алгоритмах не бывает неисправностей), а несоответствие техзаданию. Это и есть цель испытаний, вообще-то.

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

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

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

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

а вообще - тесты заново

А по поводу НПА по этому вопросу?

Что такое «НПА»?

Отправлено спустя 11 минут 10 секунд:
Не подменяйте понятия. Не в процессе ПНР, а во время ПСИ, которые проводятся только после окончания ПНР. ПНР уже закончены, и, как показали ПСИ, выполнены ПНР недостаточно качественно. После этого любой нормальный заказчик проводит ПСИ с ужесточением, это нормально.

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

[keysansa]

Ответ: этим документом является счёт на оплату договора поставки/ПНР. Кто платит, тот и заказывает музыку.

Если в этом моменте забыть хотя бы про ТЗ...

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

Что такое «НПА»?

Нормативно правовые акты. Стоящие выше, чем счет на оплату.
Тот же ГОСТ, ПУЭ, ПТЭЭП.

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

Не подменяйте понятия.

Когда приемка оборудования на 200 млн, это не

недокрученный ниппель,

если вы ответственный.

[Jackson]

Если в этом моменте забыть хотя бы про ТЗ...

А в ТЗ что-то сказано про ПНР кроме того что они должны быть проведены?

Тем более, раз цена вопроса равна 200 мультам, странно что софт не был вылизан в процессе ПНР.

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

Посмотрите группу стандартов 611131, может там что-то есть про это, но вряд ли.

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

Дело Ваше, Вам сдавать. Убеждайте если сможете. Но прикрыться Вам объективно нечем. И будь я Вашим заказчиком ~ не согласился бы, а за излишне настойчивые объяснения закатил бы полную проверку с пристрастием.

НПА - понял, спасибо. Я привык к аббревиатуре «НТД».

[Михайло]

Вам не кажется, что ПНР и ПМИ нужно разделить? При ПНР должна пройти "генеральная репетиция" сдачи по ПМИ, чтобы внести все корректировки и при ПМИ уже не отвлекаться на них.

[Jackson]

Конечно! Именно об этом я и говорю. ПНР обычно заканчивается проведением ПСИ по утверждённой программе для себя, чтобы не облажаться перед комиссией. В это время ПМ корректируется под реалии и отлавливаются ошибки, иногда участвует заказчик в роли стороннего наблюдателя (чтобы понять как это всё работает).
Потом проводятся нормальные ПСИ с комиссией.

Видимо, комиссию позвали слишком рано, но уже поздно, инцидент произошёл и придётся выкручиваться.

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

Отправлено спустя 4 минуты 36 секунд:
Ввиду технической сложности объекта и/или ввиду дороговизны проведения ПСИ, иногда, предварительные ПСИ частично или полностью зачитывают, если в них принимали участие уполномоченные представители заказчика. Ключевое слово - иногда, это не общая практика.

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

[Jackson]

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

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

[alex-tec]

А по поводу НПА по этому вопросу?

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

Отправлено спустя 7 минут 33 секунды:
Что касается НТД, обратите внимание на "ГОСТ 15.309-98. Система разработки и постановки продукции на производство. Испытания и приемка выпускаемой продукции. Основные положения", в частности на п.6.10.

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

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

[Jackson]

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

Вот очень верная формулировка - "в технически обоснованных случаях". Осталось только доказать заказчику, что проверка только части программного кода технически обоснована (если заказчик хоть немного понимает, что такое ПЛК - доказать нереально).

[alex-tec]

Вот очень верная формулировка - "в технически обоснованных случаях". Осталось только доказать заказчику, что проверка только части программного кода технически обоснована (если заказчик хоть немного понимает, что такое ПЛК - доказать нереально).

Технически обосновать - это тот ещё фокус.

[Михайло]

Технически обосновать можно только тем, что тестированные и нетестированные функциональные блоки программы ПОЛНОСТЬЮ изолированы друг от друга (независимы). Других обоснований не может быть.

[Jackson]

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


Не стОит преувеличивать глупость других людей.

[keysansa]

А в ТЗ что-то сказано про ПНР кроме того что они должны быть проведены?

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

ПУЭ и ПТЭ никакого отношения

ГОСТ вы просто пропустили? Но в любом случае система должна соответствовать ПУЭ. Хотя и согласен, слышал, что чек решает больше.

Windows все знают? Чему они нас учат? Тому что количество ошибок в коде стремится к нулю, но никогда нуля не достигает

Я сейчас не найду, лет 6-7 назад читал на сайте препринтов исследований статью, где обосновывалось, что выпускать ПО, даже в авионике, с 90% готовностью - экономически не выгодно. С 80% до 95% закроется при испытаниях и ПНР. Иначе конкуренты съедят.
OpenBSD - отличный пример, раз в сторону OS смотрим.

Посмотрите группу стандартов 611131, может там что-то есть про это, но вряд ли.

Ок.

Дело Ваше, Вам сдавать. Убеждайте если сможете. Но прикрыться Вам объективно нечем. И будь я Вашим заказчиком ~ не согласился бы, а за излишне настойчивые объяснения закатил бы полную проверку с пристрастием.

Вы в какой-то момент меня с ТС спутали.

[Jackson]

А в ТЗ что-то сказано про ПНР кроме того что они должны быть проведены?

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

Как думаете, много смысла в беседе с человеком, который не отвечает на задаваемые вопросы, а вместо этого говорит о чём-то своём?

Я своё мнение высказал. Это Ваша система, Вам её сдавать, и не мне тут на форуме а заказчику. Удачи.

[olexsa]

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

Отправлено спустя 4 минуты 39 секунд:
И еще. Но это уже наверное больше личное мнение. Никого не хочется обидеть, но все же .........
Наверное, программист еще не очень часто встречался с проблемами в пределах гарантийного срока. И с ответственностью, в том числе и материальной, которая несет его организация, в случае проблем и аварийных ситуация во время эксплуатации. А то бы сам настаивал на повторной проверке

[keysansa]

а "ГОСТ 15.309-98. Система разработки и постановки продукции на производство. Испытания и приемка выпускаемой продукции. Основные положения"

Данный ГОСТ - немного не то, как мне кажется:

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

А системы с АСУТП это мелкосерийное, максимум, производство. Чаще всего штучное, под конкретного заказчика.

Отправлено спустя 1 минуту 55 секунд:

Я своё мнение высказал. Это Ваша система, Вам её сдавать, и не мне тут на форуме а заказчику. Удачи.

Повторюсь, вы меня с ТС спутали.

Отправлено спустя 18 минут :

Данный ГОСТ - немного не то, как мне кажется:

Прошу прощения, был не прав. Этот ГОСТ может быть использован в данном случае.