|
|
  |
требования к документации |
|
|
|
Aug 5 2010, 16:32
|
Участник

Группа: Участник
Сообщений: 21
Регистрация: 3-02-07
Пользователь №: 25 005

|
Цитата(sazh @ Aug 5 2010, 19:25)  Тогда уж и квартус используемой версии документируйте. В другой может ведь и не заработать. Заказчику ваши файлы не нужны. Им нужен комплект документации. А Вам - минимальный. Все равно эти файлы кроме специалистов никому не нужны. Следовательно для вас - простая архивация вне документации. Насчет версии Quartus - само собой разумеющееся. В частности, дистрибутив используемой версии и его резервная копия хранятся в техническом архиве предприятия (есть у нас обычный архив на выпускаемую документацию, и есть технических - для хранения к примеру ТЗ, пояснительных записок, техпредложений итд. И в том числе используемых в работе программных пакетов). А насчет минимальности - тут ситуация вот какая. Фирма разрабатывает, производит и поставляет оборудование для АЭС. Поэтому требования по по документации определяются не только непосредственным заказчиком в лице конкретной АЭС. Им-то как раз никакие файлы не нужны, - им подавай оборудование и ЗИП, в состав которого входят эти самые пресловутые узлы с ПЛИСинами, а из всей документации их интересует только схемы и перечни элементов, РЭ, методики поверки или калибровки, инструкции по ТО и прочее в том же духе. При этом, возвращаясь к узлам, им нужно ЗАКОНЧЕННОЕ изделие, прошедшее функциональную проверку и циклы различных испытаний (климатических, ЭМС итд.), которым в случае возникновения неисправности в оборудовании в период работы энергоблока заменят неисправный узел и проведут после этого проверку работоспособности оборудования за отведенное на эту процедуру строго ограниченное время. То есть, несмотря на то, что на узлы поставляются схемы электрические и перечни элементов, ни то ни другое особо заказчику не требуется (что на мой взгляд абсолютно правильно). В случае, если часть оборудования отдавали на изготовление внешнему предприятию, то для них всегда хватало той документации, которую выпускали по старой системе, которую я описал в предыдущих постах. Другое дело - работа с контрольными службами (к примеру с теперь уже называющимся по другому ГосАтомНадзором). Они требуют выпускать объем документации на уровне, который бы достаточным для проведения верификации и валидации (слов-то понапридумывали!) оборудования от момента на всех этапах жизненного цикла оборудования (и начинают, естественно, в первую очередь с нас, разработчиков). И идут регулярные наезды - как верифицируются прошивки ПЛИС, как документируются в архиве, "почему так, нужно не так, а как нужно не скажем сами должны знать". Вот в чем проблема.
|
|
|
|
|
Aug 8 2010, 07:40
|
не указал(а) ничего о себе.
     
Группа: Свой
Сообщений: 3 325
Регистрация: 6-04-06
Пользователь №: 15 887

|
Цитата(клещ @ Aug 5 2010, 18:43)  Это отчего же? Если в КД указывать, что сама "болванка" ПЛИС (или ПЗУшки - на них так же делается документация) входит в комплект выпускаемой микросхемы в виде детали - то почему бы и нет? Очевидно, нужно определиться с термином "микросхема". В моем понимании чистая и не прошитая ПЛИС - такая же микросхема, как и прошитая, поэтому я и говорю, что Вы ее не можете оформить за своим номером. Кроме того, Вы нигде не сказали, что Вы на нее выпускаете спецификацию, которая должна быть (ведь это не деталь, в протоивном случае - где чертеж?). Если Вы пойдете по этому пути, то это, имхо, лишний геморрой с выпуском доп. документов. Плюс, еще можно нарваться на особенности нашего КоАП в части защиты авторских прав на топологию интегральныъ схем. Я же предагаю простой вариант с выпуском одного документа, который при желании вообще можно исключить из спецификации изделия для сокрытия Вашей интеллектуальной собственности, как теперь это модно. Мы используем давно, и даже с вп проблем нет. Также эта система хорошо ложится в модель с электронным архивом предприятия (на будущее).
|
|
|
|
|
Aug 9 2010, 15:50
|
Участник

Группа: Свой
Сообщений: 73
Регистрация: 9-08-10
Из: Украина
Пользователь №: 58 828

|
Если в спецификацию включить прошивку и ПЛИСину, то эту спецификацию можно включить в ПЭ3 как свое изделие. Но работая с документированием проектов на ПЛИС для тех же АЭС, пришли к выводу что электронный проект на ПЛИС должен быть независим от технических средств на которых он будет "испоняться". В ЕСПД есть фраза что ПО определяет техническое средство на котором оно будет исполняться, поэтому разработав техническое средство, в нем остается микросхема микросхемой, а прошивка это отдельное изделие, более того еслс на одну ПЛИСину есть ни одна прошивка(проект) а много, то вводя их в КД на плату(техническое средство) при каждой модификации проекта вам будет необходимо выполнять коррекцию КД, а это ведет за собой выпуск извещений и коррекция всех изделий куда входит такое изделие.
Конструкторская документация (КД) на плату должна не зависеть от программного обеспечения (ПО). Совмещать плату и ПО на нее необходимо на более высоком уровне уровне документирования. Слова верификация и валидация не придуманы, а содраны с буржуйских стандартов.
|
|
|
|
|
Aug 9 2010, 19:52
|
не указал(а) ничего о себе.
     
Группа: Свой
Сообщений: 3 325
Регистрация: 6-04-06
Пользователь №: 15 887

|
Цитата(DW0 @ Aug 9 2010, 19:50)  Если в спецификацию включить прошивку и ПЛИСину, то эту спецификацию можно включить в ПЭ3 как свое изделие. Нельзя ли как нибудь более понятно? Как это "включить спецификацию в ПЭ3? Цитата(DW0 @ Aug 9 2010, 19:50)  это ведет за собой выпуск извещений и коррекция всех изделий куда входит такое изделие. Вы можете объяснить, как обойтись без извещений при изменении прошивки ПЛИС?
|
|
|
|
|
Aug 10 2010, 08:14
|
Участник

Группа: Свой
Сообщений: 73
Регистрация: 9-08-10
Из: Украина
Пользователь №: 58 828

|
Цитата(vitan @ Aug 9 2010, 22:52)  Нельзя ли как нибудь более понятно? Как это "включить спецификацию в ПЭ3?
Вы можете объяснить, как обойтись без извещений при изменении прошивки ПЛИС? Например создаете документ АБВГ.123456.123 СП с названием типа "Комплект установочный на плату печатную с программируемой логикой" в нее включаете: микросхему ПЛИС Файл прошивки архив проекта (если надо) далее эту спецификацию включаете в перечень элементов к схеме электрической принципиальной. и вуаля, но если вы хотите провести коррекцию, то могут быть проблемы если у вас этот комплект используется еще на других объектах. возможна ситуация когда вы провели изменения по прошивке, внесли ее в эту спецификацию, но те изделия которые уже эксплуатируются должны тоже быть перепрошитыми в течении какого-то времени, если вы не планируете изменения на какое-то изделие, то получится что у вас нет документации на это конкретное изделие которое не подверглось перепрошивке. Предлагается делать отдельно КД на аппаратные средства, и отдельно на программные средства с схемой по ЕСПД "схема взаимодействия программных средств" к которой так же создавать перечень элементов с перечислениями всех сущностей входящих в программное обеспечение с описанием всех протоколов и состыковочных компонентов. И еще Вам понадобится инструкция по интеграции которая укажет как ПО имплементировать с аппаратными средствами. процесс документирования для таких сущностей как ПО совместно с аппаратными средствами гораздо сложнее чем кажется, и необходимость такого документирования начинает понимать после того, как начинаются проблемы с обновлениями ПО после 5-8 изменений и их все нужно перенести на корректируемый объект, или еще хуже если вышел из строя какое нибудь изделие, пришло на ремонт и его нужно прошить тем чем оно было прошито. так что оставлять и систематизировать нужно все версии которые находятся в эксплуатации. и без достаточного документирование не возможно отдать сопровождение в другие руки. Получается ситуация когда разработчик плавно погружается в сопроводителя разработанного оборудования, а процесс разработки и сопровождения это совершенно разные процессы жизненного цикла.
|
|
|
|
|
Aug 10 2010, 09:58
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(DW0 @ Aug 10 2010, 11:14)  Получается ситуация когда разработчик плавно погружается в сопроводителя разработанного оборудования, а процесс разработки и сопровождения это совершенно разные процессы жизненного цикла. Согласен, но мне кажется по другому нельзя. Инструкция по программированию, файл прошивки, архив проекта - не решает все вопросы. На мой взгляд здесь нужно дополнительно к основным: ГОСТ 2.102-68 ЕСКД. Виды и комплектность конструкторских документов; ГОСТ 2.114-95 ЕСКД. Технические условии; ГОСТ 15.101-98 Система разработки и постановки продукции на производство. Порядок выполнения научно – исследовательских работ; ГОСТ Р 15.201-2000 Система разработки и постановки продукции на производство. Продукция про-изводственно-технического назначения. Порядок разработки и постановки продукции на производство. ввести дополнительно документацию - например сопроводительную документацию, где дать техническое описание своей разработки и там сделать типа раздела введенные изменения. Но минус этого - это должен делать разработчик. Что такое техническая поддержка и кто должен ее обеспечивать? Сейчас это только сам разработчик Хотелось бы еще услышать предложения и замечания...
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Aug 10 2010, 13:03
|
Участник

Группа: Свой
Сообщений: 73
Регистрация: 9-08-10
Из: Украина
Пользователь №: 58 828

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

Группа: Участник
Сообщений: 21
Регистрация: 3-02-07
Пользователь №: 25 005

|
Цитата(DW0 @ Aug 10 2010, 12:14)  Например создаете документ АБВГ.123456.123 СП с названием типа "Комплект установочный на плату печатную с программируемой логикой" в нее включаете:
микросхему ПЛИС Файл прошивки архив проекта (если надо)
далее эту спецификацию включаете в перечень элементов к схеме электрической принципиальной. и вуаля, но если вы хотите провести коррекцию, то могут быть проблемы если у вас этот комплект используется еще на других объектах. возможна ситуация когда вы провели изменения по прошивке, внесли ее в эту спецификацию, но те изделия которые уже эксплуатируются должны тоже быть перепрошитыми в течении какого-то времени, если вы не планируете изменения на какое-то изделие, то получится что у вас нет документации на это конкретное изделие которое не подверглось перепрошивке. Простите, не могли бы Вы поподробнее объяснить, как в ПЭ3 (перечень элементов) в качестве элемента забить спецификацию? Что же касается остального, то как раз никакой проблемы нет - в архиве хранятся ВСЕ изменения. При этом на производстве всегда выпускают изделие с пометками о проведенных изменениях по извещениям. Другое дело, что когда оборудование устанавливают на нескольких объектах, то может возникнуть ситуация, что для одного объекта оборудование выпущено с ПО изм.№2, а на другом объекте - с изм№5, например. Тут только держать на предприятии-разработчике "банк данных", в котором будет собираться подобная информация. Съездил, к примеру, в командировку на 1-й объект, перезалил ПО новой версии (пусть той же №5) - по возвращении внес запись в "банк" о проведенной работе. Только так.
|
|
|
|
|
Aug 10 2010, 14:18
|

я только учусь...
     
Группа: Модераторы
Сообщений: 3 447
Регистрация: 29-01-07
Из: Украина
Пользователь №: 24 839

|
Цитата(DW0 @ Aug 10 2010, 16:03)  но в жизненном цикле есть еще и снятие с эксплуатации, а от поставки до снятия с эксплуатации необходимо обеспечить в поставленный продукт вносить изменение, а это не много не мало 30 лет, так если не создать кучу документов по которым условно говоря отдел сопровождения сможет самостоятельно разобраться с оборудованием и самостоятельно вносить изменения и коррекцию, то это означает что к примеру через лет 10 какой-нибудь "студент" за какое-то время сможет также самостоятельно разобраться и повторить, даже на других технических средствах, данное оборудование. Это есть показатель качественной разработки, а если кто-то разработал оборудование и только он сам может его изготовить(хотя бы знает чем прошить) установить, наладить и внести изменения, то это не разработка, а кустарщина (я не хочу никого этим обидеть, если кто-то расценит это как обиду, то это означает что ничего не понято из вышесказанного. прошу таких людей просто проигнорировать данный пост) и не допустима для АЭС. на мой взгляд очень хорошие слова - особенно понравилось про студента
--------------------
If it doesn't work in simulation, it won't work on the board.
"Ты живешь в своих поступках, а не в теле. Ты — это твои действия, и нет другого тебя" Антуан де Сент-Экзюпери повесть "Маленький принц"
|
|
|
|
|
Aug 10 2010, 14:27
|
Участник

Группа: Свой
Сообщений: 73
Регистрация: 9-08-10
Из: Украина
Пользователь №: 58 828

|
Цитата(клещ @ Aug 10 2010, 16:39)  Простите, не могли бы Вы поподробнее объяснить, как в ПЭ3 (перечень элементов) в качестве элемента забить спецификацию? поз. обоз._______________ Наименование ____________________________________________________________ количество ________ примечаниеD11 ____________Комплект установочный на плату печатную с программируемой логикой АБВГ.123456.123 _______ 1 Цитата(клещ @ Aug 10 2010, 16:39)  Съездил, к примеру, в командировку на 1-й объект, перезалил ПО новой версии (пусть той же №5) - по возвращении внес запись в "банк" о проведенной работе. Только так. для АЭС не катит, сначала выпускают бюллетень, где описывают что нужно заменить (в нашем случае пусть будет перепрограммировать), что после этого нужно проверить, ну и там отчеты о верификации на новое ПО, и только после этого модифицируется. Изменения в "банк" должны делаться до перепрограммирования, хотя я понимаю что с нашими отечественными АЭС это не всегда (почти никогда  ) не удается. Но по букве закона только так.
Сообщение отредактировал DW0 - Aug 10 2010, 14:36
|
|
|
|
Guest_@Ark_*
|
Aug 10 2010, 15:09
|
Guests

|
Цитата ... жизненном цикле есть еще и снятие с эксплуатации, а от поставки до снятия с эксплуатации необходимо обеспечить в поставленный продукт вносить изменение, а это не много не мало 30 лет, так если не создать кучу документов по которым условно говоря отдел сопровождения сможет самостоятельно разобраться с оборудованием и самостоятельно вносить изменения и коррекцию, то это означает что к примеру через лет 10 какой-нибудь "студент" за какое-то время сможет также самостоятельно разобраться и повторить, даже на других технических средствах, данное оборудование. Это есть показатель качественной разработки, а если кто-то разработал оборудование и только он сам может его изготовить(хотя бы знает чем прошить) установить, наладить и внести изменения, то это не разработка, а кустарщина (я не хочу никого этим обидеть, если кто-то расценит это как обиду, то это означает что ничего не понято из вышесказанного. прошу таких людей просто проигнорировать данный пост) и не допустима для АЭС. Замечательно! Разработчик выполняет разработку изделия, тестирует, испытывает, сертифицирует. Затем, фактически, подписывается под гарантией... Потом какой-то отдел сопровождения "вносит необходимые изменения и коррекцию", либо какой-нибудь студент "дописывает Модбас"... Интересно, кто, в этом случае, будет отвечать за работу оборудования?
|
|
|
|
|
Aug 10 2010, 15:19
|
Участник

Группа: Свой
Сообщений: 73
Регистрация: 9-08-10
Из: Украина
Пользователь №: 58 828

|
Цитата(@Ark @ Aug 10 2010, 18:09)  Интересно, кто, в этом случае, будет отвечать за работу оборудования? Мы говорим о серьезном оборудовании, разработчик разработал, значит выполнил документирование в полном объеме, провел все испытания, не без помощи сопровождения, и отдал, дальнейшая ответственность лежит на сопровождении. а задача разработчиков разрабатывать новое, а не сопровождать всю жизнь то что успели разработать вначале. Тут получается двойная проверка, с одной стороны разработчик говорит что я все сделал, а сопроводитель говорит что мне для полного счастья не хватает того и того документа в соответствии с тем и тем. разработали Пылесос, разрабатывайте что-то новое или новую технологию пылесоса, а сопровождение будет всю жизнь доводить до совершенства кем-то разработанную продукцию
|
|
|
|
|
  |
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|