[ixodid 0]

поз. обоз._______________Наименование ____________________________________________________________количество ________ примечание

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

 

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

 

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

 

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

[Гость @Ark]

а сопровождение будет всю жизнь доводить до совершенства кем-то разработанную продукцию

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

[DW0 0]

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

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

 

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

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

 

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

 

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

[Гость @Ark]

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

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

 

[DW0 0]

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

 

В данном случае речь идет не о квалификации, а главный акцент на качество документирования.

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

Компания которая работает в этой отрасли рано или поздно сама придет к этому и найдет ресурсы на кадры, или сгинет.

[Гость @Ark]

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

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

 

[DW0 0]

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

 

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

 

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

[Гость @Ark]

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

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

Когда все выяснилось - задача оказалась более чем стандартной. Два шкафа, в итоге, заменили на пару небольших плат. Уже несколько лет прошло - претензий нет, все работает.

 

[ixodid 0]

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

 

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

[DW0 0]

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

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

 

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

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

Когда все выяснилось - задача оказалась более чем стандартной. Два шкафа, в итоге, заменили на пару небольших плат. Уже несколько лет прошло - претензий нет, все работает.

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

 

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

 

 

[Гость @Ark]

для того чтобы написать качественное ТЗ необходимо иметь нормальные исходные данные...

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

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

В приведенном мною примере, установку эксплуатировали совсем не рядовые операторы, а большие спецы в своей области. И делали это с полным пониманием процессов и досканальным знанием аппаратуры. Но их знания от том, как это было реализовано 30 лет назад, а также документация на установку (которая имелась в полном объеме),

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

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

 

[DW0 0]

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

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

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