Проблема идентификации ПО при утверждении типа

[Zorinav 2]

Здравствуйте, уважаемые коллеги!

В соответствии с МИ3286-10 и Р50.2.077-2011 ПО СИ должно иметь идентификационные данные, которые фиксируются (вносятся в банк данных) при испытаниях в целях утверждения типа. В соответствии с методикой, которая должна быть изложена в инструкции по поверке, каждый экземпляр СИ при первичной и периодической поверках должен будет проходить проверку соответствия идентификационных данных ПО тому экземпляру ПО, который был представлен при утверждении типа.

Применительно к ПО генераторов газовых смесей (в общем случае – комбинированный тип, т.е. наличие термодиффузионных и смесительных каналов), с этим возникает проблема.

ПО в базовом варианте (для ПЭВМ) реализует расчет значений концентраций компонентов газовой смеси на выходе генератора и их погрешностей по заданным значениям расходов газов (газовых смесей) из баллонов и температуры термостатов, в которых установлены диффузионные источники микропотоков (ИМП) паров. Это ПО ориентировано на максимально возможную конфигурацию генератора (в нашем случае, это 6 каналов расхода и 4 термостата). Метрологически значимы здесь база данных компонентов исходных смесей (наименования и физические характеристики) и модули, выполняющие расчет значений концентраций компонентов в выходной смеси и их погрешностей.

Каждый выпускаемый генератор комплектуется «частью» базового ПО, соответствующего его модели. Например, модификации могут содержать только 2 канала расхода, или только 1 канал расхода и 1 термостат. База компонентов также усеченная – только заявленные компоненты. Понятно, что контрольные суммы или другие идентификаторы ПО изменятся. Потому в наименование поставляемого ПО мы вносим реквизиты поставляемой модели генератора и заводской номер.

Более того, для ПО конкретной модели становятся метрологически значимыми количество термостатов и каналов расхода, диапазоны регулирования (измерения) расходов и их погрешности. Эти данные зашиты в ПЗУ каждого выпускаемого генератора и возможности взять оттуда контрольную сумму или иной идентификатор просто нет.

Сталкивался ли кто-нибудь с такой ситуацией? Или просто поделитесь соображениями.

Мне кажется, такая проблема характерна для многих, например, для производителей хроматографов, масспектрометров и т.п

С уважением, Алексей

[Данилов А.А. 1 943]

В Вашем варианте ПО проблем не так уж и много.

Пишете ПО в максимальной конфигурации. Именно его и включаете в описание типа для ГРСИ.

Потребителю стаётся только выбирать из предложенных Вами вариантов: по аналогии с Microsoft Word: хотите шрифт Arial, хотите Times New Roman, размер 12 пт или 14 пт и т.д.

[Zorinav 2]

В Вашем варианте ПО проблем не так уж и много.

Пишете ПО в максимальной конфигурации. Именно его и включаете в описание типа для ГРСИ.

Потребителю стаётся только выбирать из предложенных Вами вариантов: по аналогии с Microsoft Word: хотите шрифт Arial, хотите Times New Roman, размер 12 пт или 14 пт и т.д.

Спасибо, Александр Александрович! Только как с идентификацией?

Р50.2.077-2011

«6.2 Методика подтверждения соответствия ПО СИ содержит методы проверки соответствия ПО СИ, которое было зафиксировано (внесено в банк данных) при испытаниях в целях утверждения типа СИ…»

«6.3 Подтверждению соответствия ПО СИ подвергают каждый экземпляр СИ с ПО, подлежащий поверке.»

МИ2955-2010:

3.3. идентификационные данные (признаки) программного обеспечения: Однозначно связанная с конкретным программным обеспечением последовательность символов (букв, цифр и т.п.), например, контрольная сумма.

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

6.3.7. К идентификационным данным (признакам) относятся:

наименование ПО СИ;

номер версии метрологически значимой части ПО СИ;

контрольная сумма метрологически значимой части ПО СИ.

[Данилов А.А. 1 943]

Разве Вам сложно указать следующие данные:

наименование ПО СИ;

номер версии метрологически значимой части ПО СИ;

контрольная сумма метрологически значимой части ПО СИ.

для ПО в максимальной конфигурации?

[Zorinav 2]

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

[Виктор 413]

Значит, составляйте идентификационные данные для каждой из модификаций отдельно.

[Данилов А.А. 1 943]

Значит, составляйте идентификационные данные для каждой из модификаций отдельно.

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

[Маслов В.А. 100]

Здравствуйте, уважаемые коллеги!

В соответствии с МИ3286-10 и Р50.2.077-2011 ПО СИ должно иметь идентификационные данные, которые фиксируются (вносятся в банк данных) при испытаниях в целях утверждения типа. В соответствии с методикой, которая должна быть изложена в инструкции по поверке, каждый экземпляр СИ при первичной и периодической поверках должен будет проходить проверку соответствия идентификационных данных ПО тому экземпляру ПО, который был представлен при утверждении типа.

Применительно к ПО генераторов газовых смесей (в общем случае – комбинированный тип, т.е. наличие термодиффузионных и смесительных каналов), с этим возникает проблема.

ПО в базовом варианте (для ПЭВМ) реализует расчет значений концентраций компонентов газовой смеси на выходе генератора и их погрешностей по заданным значениям расходов газов (газовых смесей) из баллонов и температуры термостатов, в которых установлены диффузионные источники микропотоков (ИМП) паров. Это ПО ориентировано на максимально возможную конфигурацию генератора (в нашем случае, это 6 каналов расхода и 4 термостата). Метрологически значимы здесь база данных компонентов исходных смесей (наименования и физические характеристики) и модули, выполняющие расчет значений концентраций компонентов в выходной смеси и их погрешностей.

Каждый выпускаемый генератор комплектуется «частью» базового ПО, соответствующего его модели. Например, модификации могут содержать только 2 канала расхода, или только 1 канал расхода и 1 термостат. База компонентов также усеченная – только заявленные компоненты. Понятно, что контрольные суммы или другие идентификаторы ПО изменятся. Потому в наименование поставляемого ПО мы вносим реквизиты поставляемой модели генератора и заводской номер.

Более того, для ПО конкретной модели становятся метрологически значимыми количество термостатов и каналов расхода, диапазоны регулирования (измерения) расходов и их погрешности. Эти данные зашиты в ПЗУ каждого выпускаемого генератора и возможности взять оттуда контрольную сумму или иной идентификатор просто нет.

Сталкивался ли кто-нибудь с такой ситуацией? Или просто поделитесь соображениями.

Мне кажется, такая проблема характерна для многих, например, для производителей хроматографов, масспектрометров и т.п

С уважением, Алексей

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

[Zorinav 2]

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

К сожалению, предусмотреть все возможные варианты модификаций генераторов просто невозможно - это как вместо установочного пакета Офиса с цифровым сертификатом продавать его, заранее просчитанные, инсталлированные версии на все случаи жизни, каждая со своим сертификатом . Если до нас никто не успеет поиметь "сложившуюся практику", придется "пионерить".... Например, аналогичные затруднения будут пл хроматографу "Varian", застряло продление утверждения типа пакета обработки хроматографической информации "Юнихром" и др. Хотелось бы услышать тех, кто уже сейчас столкнулся с этой проблемой.

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

Вижу пока только вариант установления идентификационных параметров поставляемых версий ПО (метрологически значимых частей)изготовителем при выпуске из производства с фиксацией их в свидетельстве о поверке. Поверитель, в конце концов, тоже Государственный человек. А уж при последующих поверках - пожалуйста, проверяйте неизменность.

И еще проблема светит - информация в ПЗУ процессора. Как-то не получается выделить там метрологически значимую часть и получить идентификационные признаки. Ну, это уже другой вопрос.

Может найдутся другие идеи?

[Маслов В.А. 100]

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

К сожалению, предусмотреть все возможные варианты модификаций генераторов просто невозможно - это как вместо установочного пакета Офиса с цифровым сертификатом продавать его, заранее просчитанные, инсталлированные версии на все случаи жизни, каждая со своим сертификатом . Если до нас никто не успеет поиметь "сложившуюся практику", придется "пионерить".... Например, аналогичные затруднения будут пл хроматографу "Varian", застряло продление утверждения типа пакета обработки хроматографической информации "Юнихром" и др. Хотелось бы услышать тех, кто уже сейчас столкнулся с этой проблемой.

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

Вижу пока только вариант установления идентификационных параметров поставляемых версий ПО (метрологически значимых частей)изготовителем при выпуске из производства с фиксацией их в свидетельстве о поверке. Поверитель, в конце концов, тоже Государственный человек. А уж при последующих поверках - пожалуйста, проверяйте неизменность.

И еще проблема светит - информация в ПЗУ процессора. Как-то не получается выделить там метрологически значимую часть и получить идентификационные признаки. Ну, это уже другой вопрос.

Может найдутся другие идеи?

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

Не совсем понятен вопрос - информация в ПЗУ процессора. Во-первых процессор чего - генератора? Во вторых какая информация - программа, некие индивидуальные коэффициенты или что-то еще?

[Данилов А.А. 1 943]

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

Так и делают. Пример - "Пирамида". Выбор первичных преобразователей - полная аналогия с выбором типа или размера шрифта в Office...

[Zorinav 2]

1 Действительно, первое, что приходит на ум - поставлять (допустим, на съемном диске)полную версию ПО с последующей инсталляцией нужного варианта пользователем, пусть в автоматическом режиме, с получением данных о генераторе с его микропроцессора через интерфейс. Идентификационные данные какого ПО будет сверять поверитель с зафиксированными при утверждении типа - ПО на диске или инсталлированную версию? Очевидно, должно быть последнее. Но контрольные суммы, которые появятся после инсталляции непредсказуемы...

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

Ради чего это - чтобы выполнить требования НД, в которой просто не учли вариант ПО, типовой для установившейся практики, мировой и отечественной?

3. (Для Владимира Алексеевича) ПЗУ процессора генератора.

Для примера возьмем коэффициенты фильтров каналов и коэффициенты линеаризации перед визуализацией данных на табло генератора. Для повышения точности они настраиваются индивидуально и, соответственно, разные для каждого генератора. А это метрологически значимая информация (значения расходов каналов регулирования расхода и значения температур термостатов), и как быть?

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

А если вмешательство со стороны пользователя и случилось - то либо СИ будет забраковано при периодической поверке, если же успешно пройдет ее - то кому от этого хуже?

[Данилов А.А. 1 943]

разработчикам запретили улучшать ПО СИ - даже изменение одной команды или константы влечет за собой повторение процедуры утверждения типа?! Вот вам и прогресс, к которому призывают и президент и правительство.

Вам предложили 2 варианта решения проблемы в рамках действующих документов - они Вас не устроили.

Есть третий вариант (но его не имеет смысла обсуждать здесь) - кардинальный - отменить/изменить требования действующих документов... А до отмены подождать... Вот только сколько ждать будете?!...

[Виктор 413]

1 Действительно, первое, что приходит на ум - поставлять (допустим, на съемном диске)полную версию ПО с последующей инсталляцией нужного варианта пользователем, пусть в автоматическом режиме, с получением данных о генераторе с его микропроцессора через интерфейс. Идентификационные данные какого ПО будет сверять поверитель с зафиксированными при утверждении типа - ПО на диске или инсталлированную версию? Очевидно, должно быть последнее. Но контрольные суммы, которые появятся после инсталляции непредсказуемы...

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

Ради чего это - чтобы выполнить требования НД, в которой просто не учли вариант ПО, типовой для установившейся практики, мировой и отечественной?

3. (Для Владимира Алексеевича) ПЗУ процессора генератора.

Для примера возьмем коэффициенты фильтров каналов и коэффициенты линеаризации перед визуализацией данных на табло генератора. Для повышения точности они настраиваются индивидуально и, соответственно, разные для каждого генератора. А это метрологически значимая информация (значения расходов каналов регулирования расхода и значения температур термостатов), и как быть?

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

А если вмешательство со стороны пользователя и случилось - то либо СИ будет забраковано при периодической поверке, если же успешно пройдет ее - то кому от этого хуже?

Трудно, что-либо возразить.

Выводы: Требование данного НД не соответствуют современному развитию СИ и в некоторых случаях их можно выполнить только за счёт ухудшения метрологических и технических характеристик СИ. И это учитывая тенденцию нарастания количества СИ с ПО.

А если бы данный документ пустили на обсуждение, может, он бы и не вышел. Хотя и это не факт.

[Zorinav 2]

Вам предложили 2 варианта решения проблемы в рамках действующих документов - они Вас не устроили.

Есть третий варианат (но его не имеет смысла обсуждать здесь) - кардинальный - отменить/изменить требования действующих документов... А до отмены подождать... Вот только сколько ждать будете?!...

Предложенные варианты не годятся, вроде я достаточно подробно это пояснил.

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

Обсуждение в форуме помогает в поиске вариантов, позволяет избежать необдуманных шагов, а также другим полезен, у кого аналогичные проблемы светят.

Касательно же несовершенства новых НД на ПО СИ - это факт. Или докажите иное. Подзаконными актами ужесточают свободомыслие нового Закона ОЕИ Думаю, в метрологических журналах развернется острая дискуссия на эту тему, и скандалы будут, и жалобы в правительство и судебные иски. Новые указы, к сожанению, никогда не блещут совершенством, это тоже факт. Нам известно множество солидных фирм, в т.ч. иностранных представительств, которые уже застряли из-за ПО с продлением утвержденных типов и несут убытки. Имея при этом ПО, которому можно только завидовать.

Увы, в нашем случае, пока кроме варианта исключения из правил, иного не просвечивает.

[Данилов А.А. 1 943]

пока кроме варианта исключения из правил, иного не просвечивает.

Чем обосновывать будете "исключение из правил"? Отсутствие метрологически значимого ПО? Отсутствие заинтересованности кого-либо в его изменении? Есть другие варианты? Сколько это займёт времени? Скольких клиентов потеряете?

Не проще ли сделать несколько модификаций?

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

[Zorinav 2]

пока кроме варианта исключения из правил, иного не просвечивает.

Чем обосновывать будете "исключение из правил"? Отсутствие метрологически значимого ПО? Отсутствие заинтересованности кого-либо в его изменении? Есть другие варианты? Сколько это займёт времени? Скольких клиентов потеряете?

Не проще ли сделать несколько модификаций?

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

Наши генераторы, Александр Александрович, давно в Госреестре, содержат 12 базовых модификаций + возможность выпускать заказные законные модели. Тем и живем, в отличие от "Фордов". Были, конечно, проблемы с утверждением типа при таком многообразии, но их успешно преодолели с помощью специалистов ВНИИМС. Они, кстати, и сами сейчас испытывают проблемы с проверкой защищенности (до этого - с аттестацией) ПО СИ и не чураются обсуждений.

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

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

Мы завершаем модернизацию генераторов и хотим заранее всё учесть, не ухудшая новых качеств ради галочки и не тратя пустых усилий на доработку. Один из более-менее корректных вариантов "исключения из правил" я вверху коротко изложил. Времени до истечения срока действия сертификата еще много, но лучше быть заранее готовым, чем и занимаюсь.

[allar 90]

Предложение по обсуждению данного документа в журнале считаю в некотором смысле здравым, но скорее всего обсуждать будем с пустотой. Ощущение такое, что цель федералов не столько написать нормальный ГОСТ (МИ, РД и т.п.), сколько написать его таким, чтобы в конечном счете срубить побольше денег, тем самым в конечном счете окончательно добить отечественного производителя.

[Виктор 413]

Обсуждаемый вопрос в равной степени касается и зарубежного производителя.

[Маслов В.А. 100]

1 Действительно, первое, что приходит на ум - поставлять (допустим, на съемном диске)полную версию ПО с последующей инсталляцией нужного варианта пользователем, пусть в автоматическом режиме, с получением данных о генераторе с его микропроцессора через интерфейс. Идентификационные данные какого ПО будет сверять поверитель с зафиксированными при утверждении типа - ПО на диске или инсталлированную версию? Очевидно, должно быть последнее. Но контрольные суммы, которые появятся после инсталляции непредсказуемы...

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

Ради чего это - чтобы выполнить требования НД, в которой просто не учли вариант ПО, типовой для установившейся практики, мировой и отечественной?

3. (Для Владимира Алексеевича) ПЗУ процессора генератора.

Для примера возьмем коэффициенты фильтров каналов и коэффициенты линеаризации перед визуализацией данных на табло генератора. Для повышения точности они настраиваются индивидуально и, соответственно, разные для каждого генератора. А это метрологически значимая информация (значения расходов каналов регулирования расхода и значения температур термостатов), и как быть?

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

А если вмешательство со стороны пользователя и случилось - то либо СИ будет забраковано при периодической поверке, если же успешно пройдет ее - то кому от этого хуже?

Трудно делать предложения не зная стркутуры и функций ПО, но попробую продолжить.

1. Можно предложить реализацию ПО в виде модулей (ехе, dll и т.п.), которые реализуют функции для конкретной части генератора (термостата, смесителя и т.д.) и общего модуля, осуществляющего объединение выбранных специализированных модулей конкретного исполнения. При данной реализации большим (избыточным) будет только объединяющий модуль, поскольку он должен обеспечить реализацию (настройку) от минимальной до максимальной конфигурации генератора.

3. Для ПЗУ в Вашем, да и большинстве случаев, когда для изменения ПО необходимо физическое извлечение контроллера (ПЗУ) и замена или перепрограммирование на специальном оборудовании, класс защиты ПО по МИ 3286 - А, т.е. защита не требуется. Поэтому идентификационная информация о ПО предоставляется, но при поверке в эксплуатации не проверяется непосредственно, а только косвенно по погрешности. Как вариант может быть выполнена проверка идентификационных данных ПО в ПЗУ при первичной поверке у изготовителя.

Каким образом для конкретной реализации СИ (ПЗУ) при изготовлении обеспечить постоянную контрольную сумму при изменяющемся составе ПО, думаю Вы, как изготовитель, знаете лучше, чем я.

[Zorinav 2]

1 Действительно, первое, что приходит на ум - поставлять (допустим, на съемном диске)полную версию ПО с последующей инсталляцией нужного варианта пользователем, пусть в автоматическом режиме, с получением данных о генераторе с его микропроцессора через интерфейс. Идентификационные данные какого ПО будет сверять поверитель с зафиксированными при утверждении типа - ПО на диске или инсталлированную версию? Очевидно, должно быть последнее. Но контрольные суммы, которые появятся после инсталляции непредсказуемы...

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

Ради чего это - чтобы выполнить требования НД, в которой просто не учли вариант ПО, типовой для установившейся практики, мировой и отечественной?

3. (Для Владимира Алексеевича) ПЗУ процессора генератора.

Для примера возьмем коэффициенты фильтров каналов и коэффициенты линеаризации перед визуализацией данных на табло генератора. Для повышения точности они настраиваются индивидуально и, соответственно, разные для каждого генератора. А это метрологически значимая информация (значения расходов каналов регулирования расхода и значения температур термостатов), и как быть?

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

А если вмешательство со стороны пользователя и случилось - то либо СИ будет забраковано при периодической поверке, если же успешно пройдет ее - то кому от этого хуже?

Трудно делать предложения не зная стркутуры и функций ПО, но попробую продолжить.

1. Можно предложить реализацию ПО в виде модулей (ехе, dll и т.п.), которые реализуют функции для конкретной части генератора (термостата, смесителя и т.д.) и общего модуля, осуществляющего объединение выбранных специализированных модулей конкретного исполнения. При данной реализации большим (избыточным) будет только объединяющий модуль, поскольку он должен обеспечить реализацию (настройку) от минимальной до максимальной конфигурации генератора.

3. Для ПЗУ в Вашем, да и большинстве случаев, когда для изменения ПО необходимо физическое извлечение контроллера (ПЗУ) и замена или перепрограммирование на специальном оборудовании, класс защиты ПО по МИ 3286 - А, т.е. защита не требуется. Поэтому идентификационная информация о ПО предоставляется, но при поверке в эксплуатации не проверяется непосредственно, а только косвенно по погрешности. Как вариант может быть выполнена проверка идентификационных данных ПО в ПЗУ при первичной поверке у изготовителя.

Каким образом для конкретной реализации СИ (ПЗУ) при изготовлении обеспечить постоянную контрольную сумму при изменяющемся составе ПО, думаю Вы, как изготовитель, знаете лучше, чем я.

Спасибо, Владимир Алексеевич!

Дельные советы, надо переварить.

Класс защиты "А" мы, похоже, не поняли, изучая МИ 3286. Единственное, что вызывает опасения - отсутствие сформулированных в НД критериев отнесения к этому классу. Судя по всему - решение Испытателя на основании нашей, должным образом оформленной писанины. Да, собственно, и по "С" - решение волюнтаристское...

Мысль по идентификации тоже красивая. Еще раз спасибо!

[Maiverik 16]

Каким образом для конкретной реализации СИ (ПЗУ) при изготовлении обеспечить постоянную контрольную сумму при изменяющемся составе ПО, думаю Вы, как изготовитель, знаете лучше, чем я.

Я понимаю что на данный момент поменять что-то сложно, но ИМХО вариант с фиксированной контрольной суммой метрологического ПО вляется тупиковым.

Система должна быть гибче.

Как вы смотрите на такую общую схему для приборов со "сложным" ПО:

1. При испытаниях определяется метрологически значимая часть, влияющая непосредственно на результаты измерений.

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

3. МОК описывается в методике поверки СИ.

3. При поверке сумма, полученная по МОК, обязательно заносится поверителем в свидетельство. Это станет неким аналогом "пломбы".

Что мы получаем?

1. Производитель волен обновлять свое ПО в рамках сохранения МОК неизменным, это снимет с производителей кучу проблем и упростит им жизнь.

2. Поверитель или контролирующий орган всегда сможет определить вносились ли изменения в ПО с момента последней поверки. Ведь мы именно этого добиваемся?

3. Любое изменение калибровочных таблиц будет вызывать изменение контрольной суммы, а не как сейчас делается в большинстве случаев - считают контрольноую сумму исполняемого файла, а файлы конфигурации, влияющие на результаты меняй как хочешь - сумма остается неизменной. (Да и по другомы не сделаешь, т.к. многие приборы нужно калибровать коэффициентами).

В результате получаем "филькину грамоту" на выходе, которая ниочем не говорит.

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

[Маслов В.А. 100]

Каким образом для конкретной реализации СИ (ПЗУ) при изготовлении обеспечить постоянную контрольную сумму при изменяющемся составе ПО, думаю Вы, как изготовитель, знаете лучше, чем я.

Я понимаю что на данный момент поменять что-то сложно, но ИМХО вариант с фиксированной контрольной суммой метрологического ПО вляется тупиковым.

Система должна быть гибче.

Как вы смотрите на такую общую схему для приборов со "сложным" ПО:

1. При испытаниях определяется метрологически значимая часть, влияющая непосредственно на результаты измерений.

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

3. МОК описывается в методике поверки СИ.

3. При поверке сумма, полученная по МОК, обязательно заносится поверителем в свидетельство. Это станет неким аналогом "пломбы".

Что мы получаем?

1. Производитель волен обновлять свое ПО в рамках сохранения МОК неизменным, это снимет с производителей кучу проблем и упростит им жизнь.

2. Поверитель или контролирующий орган всегда сможет определить вносились ли изменения в ПО с момента последней поверки. Ведь мы именно этого добиваемся?

3. Любое изменение калибровочных таблиц будет вызывать изменение контрольной суммы, а не как сейчас делается в большинстве случаев - считают контрольноую сумму исполняемого файла, а файлы конфигурации, влияющие на результаты меняй как хочешь - сумма остается неизменной. (Да и по другомы не сделаешь, т.к. многие приборы нужно калибровать коэффициентами).

В результате получаем "филькину грамоту" на выходе, которая ниочем не говорит.

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

Разделение при необходимости ПО средств измерений на метрологически значимую и метрологически незначимую части предусматривается основным НД по этому вопросу - ГОСТ Р 8.654-2009. Только делается это не при испытаниях СИ, а при разработке ПО изготовителем. В описание типа вносится идентификационная информация (наименование, обозначение, версия, контрольная сумма) только о метрологически значимой части ПО. Метрологически незначимая часть ПО может изменяться изготовителем без проведения новых испытаний. В случае разделения ПО при испытаниях СИ в соответствии с МИ 3286-2010 (п. 3.6.4) предусматривается проверка правильности взаимодействия этих частей ПО.

Записывать в свидетельство о поверке идентификационные данные ПО не имеет смысла, т.к. они или соответствуют или не соотвествуют, указанным в описании типа. В первом случае СИ поверяется, во втором - нет.

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

[Zorinav 2]

Здравствуйте, уважаемые коллеги!

Спасибо за участие в обсуждении. Кое что прояснилось.

Во-первых, по обязательности наличия идентификационных данных и проверки их соответствия данным, зафиксированным при утверждении типа, есть соответствующий приказ - во вложении. Там же - и соответствующая Рекомендация.

Во-вторых, по встроенному ПО. У нас используется 8-битный контроллер (микросхема) на базе однокристальной ЭВМ с набором встроенных в микросхему устройств ввода-вывода. Контроллеры имеют свою систему команд и среду функционирования. Для разработки, отладки и загрузки в контроллеры ПО необходимо иметь соответствующий набор аппаратно- программных средств )ПТК).Подключение ПТК невозможно без вскрытия корпуса СИ и вскрытия пломб. В контроллере имеется ФЛЭШ-память, память данных и оперативная. Запись в ФЛЭШ память производится в режиме «Future Programming and Verification Disabled». При этом недоступны не только изменение отдельных ячеек памяти, но и чтение их содержимого, в т.ч. – даже из среды разработки. Возможна только полная перезапись памяти из исходного текстового файла программы. В памяти данных хранятся режимы, создаваемые пользователем. Даже записанные в нее цифровые коды команд не принимаются процессором к исполнению и трактуются как данные. Оперативная память обслуживает вызванный (текущий) режим. Без встроенного ПО функционирование СИ (поверка в частности) невозможно.

Соответственно, составляющие погрешности, вносимые встроенным ПО, отдельно не нормируются и не проверяются, только уровень защиты. По МИ 3286-2010 это вроде бы должен быть уровень А, но у всех аналогов в описаниях типа почему-то прописан уровень С. Только в таблице кода идентификации - пустое место, и записано, что этот код недоступен для чтения. Ну и бог с ним, лишь бы прошло.

Отдельный вопрос - внешний интерфейс. например, RS-232. На него нужна соответствующая документация, включая описание протоколов обмена - для проверки защищенности встроенного ПО от воздействия извне.

Теперь о сервисном ПО. Если его включать в состав СИ, то все каноны при утверждении типа придется выполнять. Т.е. выделять метрологически значимую часть и доказывать наличие у нее идентификационных данных и уровень защиты С.

Но вроде как есть альтернативный подход - сервисное ПО, как самостоятельный продукт. В таком случае его возможно аттестовать по МИ 2174-91 "Рекомендация. ГСИ. Аттестация алгоритмов и программ обработки данных при измерениях. Основные положения". Например, это делается в УНИИМ. Там по идентификации и защите иные понятия (приблизительные -). Будем, наверное, пробовать

Приказ_пров_защиты_ПО_СИ.rar

Рекомендация Р_50_2_077_2011.rar

[Маслов В.А. 100]

Здравствуйте, уважаемые коллеги!

Спасибо за участие в обсуждении. Кое что прояснилось.

Во-первых, по обязательности наличия идентификационных данных и проверки их соответствия данным, зафиксированным при утверждении типа, есть соответствующий приказ - во вложении. Там же - и соответствующая Рекомендация.

Во-вторых, по встроенному ПО. У нас используется 8-битный контроллер (микросхема) на базе однокристальной ЭВМ с набором встроенных в микросхему устройств ввода-вывода. Контроллеры имеют свою систему команд и среду функционирования. Для разработки, отладки и загрузки в контроллеры ПО необходимо иметь соответствующий набор аппаратно- программных средств )ПТК).Подключение ПТК невозможно без вскрытия корпуса СИ и вскрытия пломб. В контроллере имеется ФЛЭШ-память, память данных и оперативная. Запись в ФЛЭШ память производится в режиме «Future Programming and Verification Disabled». При этом недоступны не только изменение отдельных ячеек памяти, но и чтение их содержимого, в т.ч. – даже из среды разработки. Возможна только полная перезапись памяти из исходного текстового файла программы. В памяти данных хранятся режимы, создаваемые пользователем. Даже записанные в нее цифровые коды команд не принимаются процессором к исполнению и трактуются как данные. Оперативная память обслуживает вызванный (текущий) режим. Без встроенного ПО функционирование СИ (поверка в частности) невозможно.

Соответственно, составляющие погрешности, вносимые встроенным ПО, отдельно не нормируются и не проверяются, только уровень защиты. По МИ 3286-2010 это вроде бы должен быть уровень А, но у всех аналогов в описаниях типа почему-то прописан уровень С. Только в таблице кода идентификации - пустое место, и записано, что этот код недоступен для чтения. Ну и бог с ним, лишь бы прошло.

Отдельный вопрос - внешний интерфейс. например, RS-232. На него нужна соответствующая документация, включая описание протоколов обмена - для проверки защищенности встроенного ПО от воздействия извне.

Теперь о сервисном ПО. Если его включать в состав СИ, то все каноны при утверждении типа придется выполнять. Т.е. выделять метрологически значимую часть и доказывать наличие у нее идентификационных данных и уровень защиты С.

Но вроде как есть альтернативный подход - сервисное ПО, как самостоятельный продукт. В таком случае его возможно аттестовать по МИ 2174-91 "Рекомендация. ГСИ. Аттестация алгоритмов и программ обработки данных при измерениях. Основные положения". Например, это делается в УНИИМ. Там по идентификации и защите иные понятия (приблизительные -). Будем, наверное, пробовать

По встроенному в контроллер ПО: уровень защиты А, все идентификационные данные указываются в описании типа, но при поверке не проверяются, контролируется отсутствие вскрытия пломб и само ПО косвенно по результатам поверки.

По внешнему интерфейсу: Если он однонаправленный (только выдача данных), то проблем нет, т.к. через него невозможно воздействие на ПО и результаты измерений. Если - двунаправленный, то необходимо проверять отсутствие команд (документированных и не документированных), которые могут изменить ПО во встроенном контроллере (при наличии аппаратной защиты от записи во ФЛЕШ-память это проверять не надо) или результаты измерений.

По сервисному ПО: Если оно входит в комплект поставки и имеет метрологически значимую часть, то его необходимо испытывать в полном объеме (с идентификационными характеристиками и уровнем защиты С). Если оно является метрологически незначимым (результаты измерений из него не используются в областях ГРОЕИ), то его можно испытать как дополнительную функцию СИ.

В любом случае при аттестации ПО, как самостоятельного продукта (особенно в областях ГРОЕИ), используются ГОСТ Р 8.654-2009 и МИ 3286-2010 (МИ 2955-2010). При использовании автономного ПО вне областей ГРОЕИ аттестуемые характеристики ПО определяются (выбираются) Заказчиком, но идентификационные характеристики ПО все равно устанавливаются (иначе не возможно идентифицировать аттестованное ПО).