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

[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

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

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

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