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

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

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

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

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

А некоторые ПЛИС вообще не шьются и каждый раз как с чистого листа

Нельзя ли как нибудь более понятно? Как это "включить спецификацию в ПЭ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



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

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

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

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

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