richie

Снова, прости за вмешательство. В "европах" видно, что специалисты прорабатывают документы. Сейчас уже того же вельмека 7точка2 версия 4 от 2009 года. 1. В нём, кстати, на странице 17 исключено требования предоставления при необходимости ИСПОНЯЕМОГО кода "(plus the executable code if necessary)". Заметьте - ИСПОЛНЯЕМОГО кода, а не как в переведённом на "великий и могучий" кусочке части 4, предоставленного, если не ошибаюсь, Даниловым Александром Александровичем ИСХОДНОМ коде "(плюс исходный код, если необходимо)". Что, в прочем, уже не важно, т.к. это требование из вельмека уже исключили. 2. Для идентификации написано: "Пример приемлемого решения: Идентификация юридически значимого программного обеспечения содержит две части. В первой части (А) происходит изменение идентификации, если измененное программное обеспечение требует нового утверждения. Часть (В) показывает только незначительные изменения в программном обеспечении, например, исправление промахов (bug fixes), которые не требуют нового утверждения." Заметьте, двойная версия юридически значимого ПО! Что для встроенного ПО вполне разумно и чаще всего так и реализовано производителями. Далее, для моего вида приборов, квалифицированного по "Risk Class B" в вельмеке написано, что: "1. Изменения юридически значимого программного обеспечения требует информирования об этом уполномоченного органа. Уполномоченный орган решает, необходима ли идентификация нового программного обеспечения, или нет. Новая идентификация программного обеспечения требуется только тогда, когда изменения программного обеспечения приводят к изменению уже утвержденных функций или характеристик." Это вполне разумно. Изменил версию описал что добавилось в функциональности (какие ошибки исправлены) и где, т.е. описал изменения. И почему-то возникает уверенность, что отношение будет не предвзятое. В условиях наших реалий такой уверенности нет. В приемлемых решениях по идентификации написано, что идентификация состоит из двух частей (A и B), где часть A - версия юридически значимого программного обеспечения, часть B - незначительные изменения в программном обеспечении, например, исправление промахов (bug fixes) "Часть (А) идентификации состоит из номера версии или номера ТАС (Type Approval Certificate – Сертификат утверждения типа)." И никакого упоминания контрольных сумм нет и в помине для моего класса Би. 3. Требования для моего оборудования в вельмеке сводятся к наличию ватч-дог таймера и хранению параметров в EEPROM.

Абсолютно согласен! И несанкционированной производителем заменой прошивки должны заниматься правоохранительные органы, а не метрологические службы. Кстати, об этом-то и говорилось в этой теме и теме "Госреестр". Для выявления таких фактов должен привлекаться производитель оборудования как эксперт.

Владимир Алексеевич и Алексей Вячеславович, заранее извините, что влезаю в ваш разговор. Практически все протоколы обмена имеют "Двунаправленные интерфейсы" в одну сторону запрос, в другую сторону ответ. Часто по протоколу обмена можно только запрашивать данные у прибора, реже - задавать значения, и крайне редко - обновлять встроенное ПО. Для меня до сих пор является загадкой КАК будут выявляться недокументированные команды. Как разработчик могу со 100% уверенностью сказать, что если мне нужно будет "спрятать" такие команды, то их могу спрятать так, что никто и никогда не сможет обнаружить, без доступа к коду прошивки. P.S. Сделал в своём приборе расчёт контрольной суммы прошивки. Время расчёта занимает почти 8 секунд, даже при условии табличного вычисления CRC. Это не в какие рамки не лезет для использования в моём приборе. Пришёл к выводу, что указанные рекомендации созданы крайне неподготовленными в техническом плане "писателями". Как говорится в анекдоте: "... и эти люди мне запрещают в носу ковыряться." Начинаю думать, что может ну его нафиг этот наш госреестр, проще пройти заново европейскую сертификацию и продавать приборы только за бугор. Прошу прощения, не сдержался.

Спасибо, прочитать успел. После прочтения уничтожил.

Владимир Алексеевич! Спасибо за развёрнутый и скорый ответ. Но хочется немного уточнить некоторые детали для однозначности понимая. 1. Т.е. нашей внутренней идентификации в рамках КД будет вполне достаточно? 2. Про контрольную сумму прошивки понял что без неё никак. Сделаем, пусть будет. 3. Т.е. проведение испытаний заранее обречено на два этапа? Первой итерацией подаём первоначальный комплект документов с необходимым кол-вом приборов, в ОТ пишем выявленный нами уровень защиты ПО. Второй - после анализа документов Испытателем, в процессе испытаний или после них, по заключению Испытателя, производится коррекция ОТ, в том числе в части уровня защиты ПО. 4. Журнал поверок на бумажном носителе именно так и заполняется поверителем. Контрольная сумма значений параметров проверяется при включении прибора и индицируется на экране сразу после теста индикации. В приборе, в силу его простоты, отсутствуют часы реального времени, а также не ведётся журнал изменений контрольной суммы, так же в силу ограниченности ресурсов. Напомню, что любое изменение значений МЗ параметров влечёт изменение их контрольной суммы. Для доступа в режим калибровки необходимо при включении удерживать одну из кнопок прибора и ввести пароль в соответствующем диалоге (значение пароля одинаково для всех приборов и написано в РЭ в разделе "калибровка", пароль не может быть изменен пользователем). В обновленной несколько лет назад версии прибора для входа в диалог ввода пароля режима калибровки необходимо нажать специальную кнопку конструктивно защищённую пломбой поверителя. Не очень понял суть предлагаеемого Вами решения со второй таблицей для параметров EEPROM.

Здравствуйте! У меня, как производителя СИ, имеется несколько вопросов по указанным рекомендациям. Вопросы предметно связаны с процитированным мною текстом автора темы: В моём оборудовании ПО встроенное, оно записывается один раз при производстве. Порядок прошивки выполняется согласно внутренней КД согласно Текстового Документа, в котором указывается: - наименование ПО включающее в себя наименование прибора, модификацию прибора и версию ПО, - описание эталонного файла прошивки: - полный путь с именем файла в системе контроля версий, - номер метки в системе контроля версий - дата-время метки в системе контроля версий. - другая технологическая информация по осуществлению прошивки. Вопрос 1: Можно ли в ОТ в табличке идентификации ПО приведённой на стр.16-17 МИ 3290-2010 указывать именно эту, внутреннюю, идентификацию? Понятием контрольной суммы прошивки не оперируем. Вопрос 2: Можно ли в ОТ в той же таблице что и в вопросе 1 в столбцах про контрольную сумму и алгоритм поставить прочерки? В МИ 3290-2010 написано что нужно указать оценку уровня защиты ПО согласно МИ 3286-2010: A, B или C. Изучив МИ 3286-2010, пришёл к выводу, что для моих приборов подходит уровень А (не требуется специальных средств защиты). Вопрос 3: Могу ли в ОТ написать значение уровня, оцененного лично мною? Или нужно обязательная добровольная аттестация ПО? И крайний вопрос 4: Достоверность калибровочных параметров, хранимых в EEPROM прибора, проверяется контрольной суммой (КС), так же хранимой в EEPROM. Контрольная сумма изменяется при проведении калибровки прибора и записи параметров в EEPROM, и согласно РЭ должна заноситься в журнал поверок. При каждом включении прибора производится проверка КС при чтении значений этих параметров из EEPROM и индицируется на экране прибора. При ежегодной поверке возможно проведение калибровки, проведение которой однозначно изменяет КС. Калибровочные параметры являются частью метрологически значимой части, и их значения в процессе эксплуатации прибора могут меняться. Но согласно МИ 3290-2010 метрологически значимая часть прибора "столбится" раз и навсегда. Как нам быть в такой ситуации?