Нельзя ли как нибудь более понятно? Как это "включить спецификацию в ПЭ3?


Вы можете объяснить, как обойтись без извещений при изменении прошивки ПЛИС?

Например создаете документ АБВГ.123456.123 СП с названием типа "Комплект установочный на плату печатную с программируемой логикой"
в нее включаете:

микросхему ПЛИС
Файл прошивки
архив проекта (если надо)

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

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

Согласен, но мне кажется по другому нельзя.
Инструкция по программированию, файл прошивки, архив проекта - не решает все вопросы.
На мой взгляд здесь нужно дополнительно к основным:
ГОСТ 2.102-68 ЕСКД. Виды и комплектность конструкторских документов;
ГОСТ 2.114-95 ЕСКД. Технические условии;
ГОСТ 15.101-98 Система разработки и постановки продукции на производство. Порядок выполнения научно – исследовательских работ;
ГОСТ Р 15.201-2000 Система разработки и постановки продукции на производство. Продукция про-изводственно-технического назначения. Порядок разработки и постановки продукции на производство.

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

Что такое техническая поддержка и кто должен ее обеспечивать?
Сейчас это только сам разработчик

Хотелось бы еще услышать предложения и замечания...

если мы говорим о АЭС, то органы которые занимаются верификацией, и валидацией и вообще там много нахлебников которые не дают дышать разработчику, проверяют качество жизненного цикла. Так вот процессы жизненного цикла по всем современным веениям и стандартам, должны включать не только разработку и установку оборудования, но и сопровождение, причем для обеспечения качества и диверсификации, необходимо чтобы сопровождением занимались независимые от разработчика организации (отдел, подразделение .....).
Под сопровождением понимается процесс внесения изменений, адаптация существующего оборудования к конкретному объекту, даже тестирование, и там много еще всякого почитайте ГОСТ Р 51904-2002.

но в жизненном цикле есть еще и снятие с эксплуатации, а от поставки до снятия с эксплуатации необходимо обеспечить в поставленный продукт вносить изменение, а это не много не мало 30 лет, так если не создать кучу документов по которым условно говоря отдел сопровождения сможет самостоятельно разобраться с оборудованием и самостоятельно вносить изменения и коррекцию, то это означает что к примеру через лет 10 какой-нибудь "студент" за какое-то время сможет также самостоятельно разобраться и повторить, даже на других технических средствах, данное оборудование. Это есть показатель качественной разработки, а если кто-то разработал оборудование и только он сам может его изготовить(хотя бы знает чем прошить) установить, наладить и внести изменения, то это не разработка, а кустарщина (я не хочу никого этим обидеть, если кто-то расценит это как обиду, то это означает что ничего не понято из вышесказанного. прошу таких людей просто проигнорировать данный пост) и не допустима для АЭС.

Простите, не могли бы Вы поподробнее объяснить, как в ПЭ3 (перечень элементов) в качестве элемента забить спецификацию?

Что же касается остального, то как раз никакой проблемы нет - в архиве хранятся ВСЕ изменения. При этом на производстве всегда выпускают изделие с пометками о проведенных изменениях по извещениям. Другое дело, что когда оборудование устанавливают на нескольких объектах, то может возникнуть ситуация, что для одного объекта оборудование выпущено с ПО изм.№2, а на другом объекте - с изм№5, например. Тут только держать на предприятии-разработчике "банк данных", в котором будет собираться подобная информация. Съездил, к примеру, в командировку на 1-й объект, перезалил ПО новой версии (пусть той же №5) - по возвращении внес запись в "банк" о проведенной работе. Только так.

"Микросхема АБВГ.123456.789"

на мой взгляд очень хорошие слова - особенно понравилось про студента

поз. обоз._______________Наименование ____________________________________________________________количество ________ примечание
D11 ____________Комплект установочный на плату печатную с программируемой логикой АБВГ.123456.123 _______ 1



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

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

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

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

Я так понимаю, это годится в том случае, если ПЛИС вначале прошивается, а потом уже устанавливается в узел или модуль. А что прикажете делать, если она исходно запаивается в узел, и прошивка осуществляется в составе узла?



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

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

ну вообще прошивается не сама ПЛИС а флешка возле, хотя вы говорили про макс который с флешкой на кристалле. Решается это так, в спецификацию можно включить инструкцию по программированию комплекта, в которой указать что после установки микросхемы, запрограммировать ее прошивкой из комплекта, либо на поле схемы указать тех. требования, прошивать после установки в соответствии с инструкцией или если ее нет, то просто программировать тем что есть в комплекте.


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



Еще раз, Мы говорим о атомной энергетики и требования там к разработке сложнее чем к сотовым телефонам. сопровождение в процессе эксплуатации это значит, что если заказчик (АЭС) обнаружила дефицит безопасности, его нужно устранять, так как безопасность ядерно опасного объекта не имеет цены. Сопровождение этого оборудования очень ответственное и внесение изменений для минимизации такого дефицита, также сложны как и разработка. И я вас уверяю этот процесс у нас непрерывный, так как это может быть не только ошибка в поставляемом оборудовании но и технологические изменения свойств оборудования которые(свойства) отличаются от первоначально заданных. И я вас уверяю через 10 лет активной разработки ни один разработчик не будет в состоянии самостоятельно сопроводить в течении 30 лет разработанное оборудование, и самое интересно что документирование должно быть организовано таким образом чтобы даже при похищении разработчика инопланетянами, процесс сопровождения не остановился, так по требованиям стандартам качества ИСО, не должно быть не заменяемых людей, но до нас это очень туго доходит, потому и делаем кустарщину(опять же это не принимать как обиду, да вы и сами понимаете о чем я)

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

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

Для текущего сопровождения и небольших доработок - это актуально, конечно. А для повторной разработки, как правило, - нет. Тем более, через 15-30 лет. Например, когда переводишь устаревшие изделия на современные МК, то совсем не интересно, как это было сделано когда-то на дискретной логике. Интересуют только конечные технические характеристики изделия...

Тут я с Вами не согласен, так как проектные решения при реконструкции очень важны. процентов 60-80, той документации которая будет разработана будет востребована через 10-15 лет при реконструкции, поверьте опыту, довелось реконструировать не одну систему, и схемы принципиальные 70-х годов идут вход, и чертежи, и записки и описания и свидетельства очевидцев и сторожил все идет для выяснения истины. При переходе на новую элементную базу (если МК это микроконтроллер, то это очень малая часть) необходимо получить и временных характеристики и понять суть новых решений, тем более если сегодня коды написаны на HDL, то я думаю их актуальность будет и через 10-15 лет еще актуальна и переносима на более новые ПЛИС.

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

Вся эта информация актуальна, когда она представлена в виде ТЗ для разработки - формализована в виде технических требований, условий эксплуатации, обкатанных алгоритмов управления и так далее. Проектные решения 30-летней давности разработчику не нужны. Не так давно занимались переводом аппаратуры управления (примерно в вашей области) на современную элементную базу. Бредовая мысль разбираться в электрической схеме двух шкафов, сделанных в 70-е годы - никому даже не приходила в голову. От сопровождающих требовалось только четко сформулировать ТЗ. Несмотря на то, что аппаратуру они знали "вдоль и поперек" на ряд ключевых вопросов так и не смогли ответить - просто никогда не интересовались этим. Пришлось заниматься исследованиями.
Когда все выяснилось - задача оказалась более чем стандартной. Два шкафа, в итоге, заменили на пару небольших плат. Уже несколько лет прошло - претензий нет, все работает.

Эээхх.. Вы даже представить не можете, как я с Вами согласен!!

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

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

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

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

Ну, как формируется ТЗ мне не нужно рассказывать.

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

@Ark я именно и хочу сказать что немного о разных вещах говорим, тут по форуму пошли вопросы о документировании ПЛИС да и вообще о документировании, и вопросы были по документации на АЭС, так вот для ответственных систем по очень высокому классу безопасности, есть принцип консервативного подхода, который говорит повторяй тем более если нет ответа, значит должно быть так как было, а не как на экспериментировали. И вам очень повезло что эксплуатирующая сторона хорошо знала свое дело, порой приходится видеть картину, когда нет понимающих, и тогда все идет в ход даже схемы и старые языки, потому что просто нет другого выхода. Это я к тому что на этапе разработки в явном виде не ясно пригодится через 30 лет для реконструкции, поэтому есть необходимость делать с избытком, тем более есть вероятность что VHDL коды будут актуальны и через 30 лет.
Резюмируя, скажу, что мы просто немного о немного разных подходах говорим, как ваш так и мой опыт возможно пригодятся, ну хотя бы мне Ваш, а Вам мой.
Но для качественной разработки очень важно достаточный объем документации и избыток здесь не помеха, ну только время разработчика