требования к документации Опции

[Maverick]

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

P.S. Это как я попытался сформулировать:

Требования к написанию программ и документации для ПЛИС

• Файл/документ, содержащий описание всех констант, переменных, сигналов.
• TEST BENCH файл/документ с описанием для возможности моделирования работы.
• Описание работы функциональной модели (схема, конечный автомат состояний (диаграмма состояний конечного автомата), и временная диаграмма работы (скриншоты с ModelSim).
• В исходном коде программы должны присутствовать комментарии, облегчающие понимание программы.
• Подробное описание всех входных и выходных сигналов с предъявляемыми к ним требованиями (например потенциальная или импульсная команда(ее длительность)).
• По возможности большую программу/схему разбивать на подпрограммы/подсхемы.
• На начальном уровне соединение всех функциональных блоков производить в Schematic Editor (например, Синхрогенератор <=> Модуль связи УПСОС-ПК) (может заменить функциональную/структурную схему).
• При использовании ядер из CoreGenerator описать процесс создания.
• При написании исходного кода программы максимально использовать механизм настраиваемых параметров Generic (например, для разрядности данных, адресов и т. д.).

Но мое начальство говорит, что лучше руководствоваться ГОСТами. Соответственно вопрос есть ли какой то ГОСТ на оформление документации (для программ для ПЛИС).

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

[DW0]

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

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

[vitan]

Если в спецификацию включить прошивку и ПЛИСину, то эту спецификацию можно включить в ПЭ3 как свое изделие.

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

это ведет за собой выпуск извещений и коррекция всех изделий куда входит такое изделие.

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

[DW0]

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


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

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

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

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

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

[клещ]

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

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

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

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

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

[DW0]

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

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

Съездил, к примеру, в командировку на 1-й объект, перезалил ПО новой версии (пусть той же №5) - по возвращении внес запись в "банк" о проведенной работе. Только так.

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

Сообщение отредактировал DW0 - Aug 10 2010, 14:36

[клещ]

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

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

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

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

[DW0]

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

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

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

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

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

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