Утверждение ЭД

Дефект и есть недостаток, только по русски :) В общем, синонимы они
Синонимы? Ну не знаю... Вот определение дефекта из ГОСТ Р ИСО 9000-2008:
***
3.6.3 дефект (defect): Невыполнение требования (3.1.2),
связанного с предполагаемым или установленным
использованием.
П р и м е ч а н и я
1 Различие между понятиями дефект и несоответствие (3.6.2)
является важным, так как имеет подтекст юридического
характера, особенно связанный с вопросами ответственности за
качество продукции. Следовательно, термин «дефект» следует
использовать чрезвычайно осторожно.
2 Использование, предполагаемое потребителем (3.3.5), может
зависеть от характера информации, такой как инструкции по
использованию и техническому обслуживанию, предоставляемые
поставщиком (3.3.6).
***
Как видим, тут дается намек на некий "юридический подтекст". Очевидно, речь идет о договорах покупатель-изготовитель и изготовитель-разработчик. Пока мы не научимся юридически грамотно составлять такие договора, эксплуатант будет платить за устранение косяков изготовителя и разработчика... А у нас даже в госсекторе в этом деле - кто в лес, кто - по дрова. Нужны какие-то стандарты деловой практики что-ли в этой области.
ЗЫ:
Ключевой признак здесь - если нет требования, то нет и дефекта. А что есть, если косяк - налицо? ИМХО - недостаток.
 
Последнее редактирование:
Реклама
В этом определении ИСО черт ногу сломит :) Многозначительность ни о чем... AFAIK вся теория и практика product liability https://www.google.ru/search?q=зкщв...r_pw.r_qf.&fp=45ef85029423c78&biw=981&bih=665 связана с понятием дефект и именно как синоним недостатка, я бы не стал тут ничего усложнять
 
В этом определении ИСО черт ногу сломит :) Многозначительность ни о чем...
Дык, наоборот - вполне четкое определение, из которого вытекает простое правило: если есть требование, которое невыполнено - дефект. Нет требования - нет дефекта. Разумеется речь тут не о всяком требовании, а только о таком, которое оговаривает предполагаемое или предписанное использование изделия.
 
Вот еще предмет размышления. Мы привыкли отождествлять ЭД с комплектом неких руководств (толстых книжек, иногда сканируемых). Книжки содержат правила летной и технической эксплуатации (в частности, указания по поддержанию летной годности). Эти правила и подлежат утверждению при сертификации типа ВС, а потом и его (ВС) эксплуатанта.
Пока рассматриваются "книжки" все привычно и более-менее понятно. Однако теперь мы имеем дело уже с наборами электронных модулей данных, которые (наборы) могут меняться в зависимости от поставленных целей (для чего набираем).
Возникают вопросы:
- что является физическим объектом сертификации,
- как этот объект правильнее идентифицировать,
- как задать к нему требования (в стилистике электронных данных) и
- как практически его оценивать на соответствие тем требованиям?
 
Возникают вопросы:
- что является физическим объектом сертификации,
Минимальная единица измерения - модуль данных. Первоначальный "объект" сертификации - информационный набор из содержательных модулей данных, представляемый в процессе сертификации типовой конструкции. Далее, после получения сертификата, это уже отдельные модули или пакеты модулей, подвергнутые изменениям или полностью новые модули. Аналог с бумажными страницами документов: новых, измененных, аннулированных.
- как этот объект правильнее идентифицировать,
Уникальный идентификатор модуля данных - это его код, размещаемый непосредственно в его структуре. Аналог - это номер чертежа.
- как задать к нему требования (в стилистике электронных данных) и
При использовании какой-либо стандартизованной спецификации, например спецификации ASD S1000D, это описывается в формате языка XML. Структура модуля данных того или иного типа строго описывается схемой формата XSD (а их существует по крайней мере 27 в версии 4.0.1 S1000D) . Шаг вправо, шаг влево - :confused:
- как практически его оценивать на соответствие тем требованиям?
Если речь идет о соответствии структуры модуля данных схеме XSD, то это осуществляется обычной проверкой валидности, реализованной в любом XML-редакторе, для этого в XML-модуле прописывается путь к месту размещения "эталонной" схемы, например: http://www.s1000d.org/S1000D_4-0/xml_schema_flat/proced.xsd
как видно из ссылки, просто так подделать источник эталона для проверки весьма затруднительно...

Если говорить непосредственно о контентной части модулей данных, то здесь ничего принципиально нового нет. Все традиционные требования по содержанию и изложению контента тех или иных эксплуатационных документов здесь вполне приемлемы. Исключение составляют требования по оформлению текста и иллюстраций, т.е. здесь привычные требования ГОСТ 2.105-95 и ГОСТ 18675-79 придется забыть.
 
Последнее редактирование:
Однако теперь мы имеем дело уже с наборами электронных модулей данных, которые (наборы) могут меняться в зависимости от поставленных целей (для чего набираем).
Собственно, здесь есть пока недорешенный вопрос.
Публикация (аналог - руководство, книга/часть руководства) состоит из информационного набора (или наборов) содержательных модулей данных и т.н. служебных модулей данных: титульного листа, шмуцтитулов, перечня модулей данных, содержания.
Если модули данных информационных наборов прошли процедуру одобрения/принятия, и в "идеале" могут иметь ЭЦП АР МАК, выбирай из них то, что установлено по контракту и вперед, то т.н. служебные модули данных, особенно такие как перечень модулей данных и содержание, для каждого выпуска публикации меняются. Если их тоже подписывать у АР МАК, то тогда надо заводить постоянное представительство в АР МАКе, чтобы одобрять каждый выпуск публикаций серийного производства. Получается, что не надо бы подписывать в АР МАКе эти самые служебные модули данных. Как к этому отнесётся АР МАК? Тайна, покрытая мраком неизвестности...
 
Вот и я о том. Либо утверждать при сертификации все "содержательные" модули данных, либо как-то идентифицировать их наборы...
 
Вот и я о том. Либо утверждать при сертификации все "содержательные" модули данных, либо как-то идентифицировать их наборы...
Да, при сертификации следует одобрять/согласовывать модули данных по всей типовой конструкции заявленной на получение сертификата, что может сразу включать в себя и варианты конструктивного исполнения и опционное оборудование. Под "содержательными" модулями подразумеваются те, что содержат контент по направлению документа. "Служебные" - это перечни действующих модулей данных, содержание, титулы публикаций. Они всегда "слетают" при формировании публикации на конкретный экземпляр ВС, хотя при этом могут использоваться уже одобренные/согласованные "содержательные" модули данных, без каких-либо изменений.
А собственно информационные наборы - это понятие весьма условное. Выкинуть из публикации служебные модули данных, вот и набор получается. Все-таки очевидно следует идентифицировать типовой состав одобряемых/согласовываемых модулей данных по публикациям (которые также имеют свой уникальный код - нечто типа децимального номера) - как аналогам руководств, книг/частей руководств, оно так ближе и понятней. Однако, вот служебные модули данных для таких публикаций (условно говоря - публикаций нулевого выпуска) подписывать ЭЦП при сертификации не следует.
 
Последнее редактирование:
Однако, вот служебные модули данных для таких публикаций (условно говоря - публикаций нулевого выпуска) подписывать ЭЦП при сертификации не следует.
Есть и второй вариант решения.
Служебные модули данных, входящие в состав публикаций представляемых при сертификации, подписываются АР МАКом, тем самым как бы закрепляется процедура сертификации применительно к представленной публикации. Подписываются перечни действующих модулей данных, содержания, перечни внесенных изменений (т.н. highlights). Таким образом, поддерживается в "одобренном" состоянии полноценная контрольная публикация нулевого выпуска. Такая публикация никогда не будет поставляться ни с одним из экземпляров ВС, поскольку содержит все версии всех модулей данных, по всем вариантам исполнения и составу опционного оборудования, говоря бухгалтерским языком - "нарастающим итогом". Разумеется нет и не может быть такого экземпляра ВС, который соответствовал бы по конфигурации нулевому выпуску публикации. Как например не может быть на одном экземпляре ВС установлено три типа метеолокатора, четыре типа УКВ-радиостанций, пять типов ответчика УВД и т.п. Реально с экземпляром ВС будут поставляться публикации, имеющие содержательные модули данных в соответствии с фактическим исполнением и составом оборудования, имеющие ЭЦП АР МАК, а служебные модули данных в таких публикациях будут подписаны только ЭЦП изготовителя ВС.
 
Реклама
Пусть будет ссылка "до кучи" (там кое-какая фактура есть, хотя выводы с точностью до наоборот :)) http://www.ato.ru/content/predlozhe...a-ekspluatacionnoy-dokumentacii-i-byulleteney
М-да... Ну, что тут скажешь...
Дремучий, ретроградный подход к решению непростой задачки ГА РФ 21 века :confused2:
Можно еще покомментировать, но не хочется что-то :ass1:
 
Пока рассматриваются "книжки" все привычно и более-менее понятно. Однако теперь мы имеем дело уже с наборами электронных модулей данных, которые (наборы) могут меняться в зависимости от поставленных целей (для чего набираем).
Возникают вопросы:
- что является физическим объектом сертификации,
- как этот объект правильнее идентифицировать,
- как задать к нему требования (в стилистике электронных данных) и
- как практически его оценивать на соответствие тем требованиям?
Возникает и ещё один немаловажный вопрос:
- как подписывать (согласование, утверждение, одобрение) наборы электронных данных?

В этой области просматриваются 2 серьезные проблемы:
1) Средства ЭЦП должны быть не только у промышленности, но и у власть придержащих. Каждый разработчик ВС будет приходить ко власти со своими средствами ЭЦП? (т.е. типа со своей чернильницей и пером)
А может средства ЭЦП должны быть едиными для всех? Ну, хотя бы на уровне авиационной промышленности.
Ответа пока нет.
2) Предположим, что вопрос 1 решен. Появляется проблема последовательности подписания документа, которая привычна для бумажной документации, т.е. когда с листом утверждения последовательно объезжают инстанции и получают чернильные подписи.
Для ЭЦП это не годится. Допустим, представили документ в первую инстанцию, получили замечания, устранили замечания, текст исправлен, документ надо переутверждать, ведь хэш (контрольная сумма) поменялся! Предыдущие подписи стали недействительны!
Далее - едем во вторую, третью и т.д. инстанцию, история повторяется: замечания-исправление-переподписание, причем переподписывать придется уже у всех предыдущих инстанций... и т.д.
Получается, что ЭЦП надо проставлять всем сразу, одновременно, собравшись всем в кабинете у последней инстанции. Как это можно сорганизовать? Пока не очень представляется.
Либо нужно по-старинке собирать чернильные подписи на бумажном листе утверждения, а ЭЦП получать уже после получения последней чернильной подписи. Что удвояет продолжительность процедуры...
Даже если вместо ЭЦП применять информационно-удостоверяющие листы по ГОСТ 2.051-2006, то все равно контрольные суммы всякий раз слетают при прохождении очередной инстанции (замечания-исправление-переподписание), листы надо перепечатывать и всем переподписывать. А без указания контрольных сумм информационно-удостоверяющие листы это филькина грамота.
Или может быть ещё каким способом выходить из положения? Следует серьезно обмыслить эту проблему с учетом положений ГОСТ 2.051-2006.
 
Последнее редактирование:
Следует серьезно обмыслить эту проблему
И правда, "надо что-то делать ..." (с) :)
А если серьезно, то вопросы правильные. Можно пойти "оригинальным путем" - посмотреть как оно за рубежом :) Может кто в курсе - поделится?
 
Каждый разработчик ВС будет приходить ко власти со своими средствами ЭЦП? (т.е. типа со своей чернильницей и пером)
ещё раз по поводу своей чернильницы с пером...
Все имеющиеся сертифицированные и допущенные Гостехкомиссией программные средства ЭЦП и услуги соответствующих Удостоверяющих центров - коммерческие, т.е. платные. Для крупных разработчиков и производителей авиатехники это не столь обременительно. А вот как быть с авиавласть придержащими и иже с ними... Ну, конечно разработчик ВС может и "раздать" в заинтересованные инстанции купленные на свои кровные USB-eToken'ы с аппаратными "секретными" ключами зарегистрированных ЭЦП, и при этом даже не обеднеет, не сильно много этих самых инстанций.
Вопросы в том: а) возьмут ли их власть придержащие? б) не нарушит ли это лицензионное соглашение поставщика средств ЭЦП? в) не возникнет ли сомнения в "легитимности" подписей государством уполномоченных инстанций с помощью таких "давальческих" ключей с ЭЦП? г) не сложится ли в этих инстанциях букет из этих самых USB-eToken'ов с ЭЦП от каждого из разработчиков ВС?
Вопросы есть, ответов нет... :confused:
 
MsKos,
1. Проблема с необходимостью переподписывать документ после правок у тех, кто его подписал до того, от ЭЦП никак не зависит и тоже имеет место в случае чернильницы с пером. Решение здесь простое - весь процесс делиться на фазы РАССМОТРЕНИЕ И СБОР ЗАМЕЧАНИЙ> ПРАВКА>ПОВТОРНОЕ РАССМОТРЕНИЕ> ПОДПИСАНИЕ. Если к документу приделываются ноги, голова и кое-что еще, зацикливания на фазах правки и повторного рассмотрения мона избежать. Тут важно иметь ввиду: подписанты должны сформулировать, задокументировать и выставить автору духумента свои замечания. А автор, после внесения правок, должон отписать по каждому пункту замечаний, что сделал. И новую редакцию духумента засылать на повторное рассмотрение с протоколом отписок по каждому замечанию. Ну и договариваться, договариваться, договариваться. И токо получив согласие всех участников - засылать на подписание.
2. Касательно коммерческих удостоверяющих центров. Дык надо создавать некоммерческий. Действующий в масштабах всего авиапрома. А разработчик ВС не может раздавать ключи. Он может токо проплатить выдачу ключа, а ключ должен получать сам подписант. И никак иначе. Иба удостоверяющий центр должен как-то пасти легитимность ЭЦП конкретной персоны, работающей на конкретной должности в конкретной организации. Ежли конкретная персона вдруг уволилась из данной организации, то с этого момента она уже не должна иметь возможность прикладывать старую ЭЦП к новым документам. Удостоверяющий центр должон этот вопрос отслеживать.
 
Yuha, спасибо за ответ. Честно признаюсь - приятно осознавать, что не одинок во вселенной... :p
подписанты должны сформулировать, задокументировать и выставить автору духумента свои замечания
Это голубая мечта собирателя подписей-иконостаса на листе утверждения докУмента. К сожалению (это мягко, черт подери!), подписанты-инстанции считают это для себя унизительно-зазорным (типа западло!), и присвоили право менять свое мнение в процессе разговора... Ну, не просто это всё в текущей реальности лабиринтов авиационной власти...
И токо получив согласие всех участников - засылать на подписание
Это и называется полный консенсус 8-) Мечты, мечты ... :rolleyes:
Касательно коммерческих удостоверяющих центров. Дык надо создавать некоммерческий. Действующий в масштабах всего авиапрома
Дык, и я про тож... Ясное дело, что надо, и не столько на уровне авиапрома (с этим можно устроить), как на уровне авиапром-авиавласть (с чем несколько сложнее). По ГОСТ 2.051-2006 сия трудная миссия возлагается на разработчика... И, похоже здесь без некоего "сговора" никак не обойтись. Но, пока эта тема никого всерьез не интересует. Только бумага, бумага, бумага... и чернильные подписи...
 
MsKos,
Голубая мечта - чек-лист для кажного подписанта, указующий, на предмет чего данный конкретный член иконостаса должон смотреть данный духумент. И шоп - не шо на ум взбрело, а строго по контрольной карте шел... :)
Но это уже - фантастика второго уровня сложности... Увы. :)


---------- Добавлено в 18:54 ----------


Но, пока эта тема никого всерьез не интересует. Только бумага, бумага, бумага... и чернильные подписи...
Дык к ЭЦП ноги не приделаешь. А когда к тебе приходют получить физическую собственноручную подпись, всегда можно спросить "А - поговорить?" Душевно о том о сем. За рюмкой чая... :) Немаловажно. Им же ж скучно сидеть и в окно глядеть. Им хочется чтоб кто-нить пришел. Ну хоть кто-нить... :)
 
...на предмет чего данный конкретный член иконостаса должон смотреть данный духумент. И шоп - не шо на ум взбрело, а строго по контрольной карте шел...
Ну, а как жеж, и не проявить глубокие знания русского языка и корректорско-редакторский талант :D
Ведь столько ошибок и очепяток находят :rolleyes: ни дать, ни взять - институты русского языка :confused2: если конечно читают, то что подписывают :lol:
 
Ну, а как жеж, и не проявить глубокие знания русского языка и корректорско-редакторский талант
Ведь столько ошибок и очепяток находят ни дать, ни взять - институты русского языка если конечно читают, то что подписывают
Дык после третьего стакана это проходит. Появляется тяга к устному народному творчеству. Ну а дальше сил остается только на тупо подписать и расцеловаться! :)
 
Реклама
Пардон, только сейчас заметил, что пропустил вопрос:
Тогда позвольте еще один вопрос - Ми-8 в эксплуатации в ГА с 1968 года, аттестат выдан в 1982 году.
До 1982 года каким образом происходил допуск? Интересно для общего развития.
Думаю, что на основании акта госиспытаний. НЛГВ приняли в 1971 г., ну и потом внедряли, осмысляли :) к 1982 раскачались оформить аттестат о годности к эксплуатации, а до этого обходились, наверное, приказом о допуске к эксплуатации .....

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

В проекте изготовитель свой ПН желал устранять за счет эксплуатанта, в подписанном бюллетене - уже за свой
Повторюсь, это все никого ни к чему не обязывает, пока бюллетень не вошел в состав AD государства регистрации ВС, либо - не стал предметом договора двух сторон (поставщика АТ и эксплуатанта/владельца)
 
Назад