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

Ученый сказал(а):
Дефект и есть недостаток, только по русски В общем, синонимы они
Нажмите, чтобы раскрыть...
Синонимы? Ну не знаю... Вот определение дефекта из ГОСТ Р ИСО 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) . Шаг вправо, шаг влево -
Ученый сказал(а):
- как практически его оценивать на соответствие тем требованиям?
Нажмите, чтобы раскрыть...
Если речь идет о соответствии структуры модуля данных схеме XSD, то это осуществляется обычной проверкой валидности, реализованной в любом XML-редакторе, для этого в XML-модуле прописывается путь к месту размещения "эталонной" схемы, например: http://www.s1000d.org/S1000D_4-0/xml_schema_flat/proced.xsd
как видно из ссылки, просто так подделать источник эталона для проверки весьма затруднительно...

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

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


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


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

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

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