Форум: Выбор оборудования

Нас обрадовало, что Свидетельство об утверждении типа средства измерения на крейтовую систему LTR продлено до 2017 года.
http://lcard.ru/sites/default/files/SERTIFIC/sv_LTR.jpg

Но  в ходе сертификации прикладной измерительной системы на базе крейтов LTR неизбежно возникнет вопрос о сертификации ПО измерительной системы.

А в ПО мы начинаем использовать программный продукт ltr-сервер и программы API-интерфейса модулей.

Можно ли считать, что данные программные продукты являются сертифицированными на основании Свидетельства?

Если нет, то каким образом сертифицировать ПО?

По идее, из LTR-модулей мы вычитываем с помощью ltr-сервера и API-интерфейса значения физических величин электрических сигналов. Как удалось получить Свидетельство на аппаратную часть без "узаконивания" неотъемлемой программной части?

Спасибо.

Леонид, я так понял, Вы делаете комплекс, состоящий из LTR и сторонних  датчиков,  кабелей, оригинального способа их подключения к LTR с использованием резисторов ( http://www.lcard.ru/forums/viewtopic.ph … 165#p57165 ), стороннего прикладного  ПО для измерения известной Вам физической величины. В этих условиях данный измерительный комплекс требует сертификации целиком.

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

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

В методике поверки написано:
загрузить в компьютер программу «LTR22» ( или к-либо другую в соответствии с поверяемым модулем ).

Пож. поясните: какая это программа "LTR22".

И как быть, если в работе при чтении из LTR напряжения, мы используем ltr-сервер и API-интерфейс к-либо модуля, представленный в виде исходных текстов на вашем сайте?

Программа "LTR22" используется для поверки этого измерительного модуля. Дистрибутив можно скачать: ftp://ftp.lcard.ru/pub/ltr/.
Файл: ltr_metr_setup.exe.

- Рассуждаю как инженер (не метролог). Если в методике поверки вашего комплекса возникает методологическая проблема (как доказать, что с использованием конкретного программного интерфейса с Установкой измерительной LTR получаемые от неё данные не содержат погрешности, связанной с ошибкой передачи данных через программный интерфейс?),  тогда примените сличение показаний методом непосредственных измерений, широко применяемый в метрологии: сличите показания ПО "LTR22" c показаниями, получаемыми от Установки измерительной LTR через программный интерфейс со стороны вашего комплекса.
Замечу, что в программный интерфейс , в данном случае, входит не только  ltr-сервер и API-интерфейс LTR, но и программная часть вашего комплекса.

А можно в МП сличить и с внешним эталонным вольтметром... - всё это методологические вопросы построения вашей МП. Я полагаю, что эти вопросы уже не относятся к вопросам техподдержки по изделиям L-Card.

Еще не посмотрел программу "LTR22", но подход с сравнением показаний понятен.

Если бы программа "LTR22" использовала тот же ltr-сервер и LTR22 API интерфейс, тогда можно было бы подумать, что автоматически ltr-сервер и API-интерфейс являются сертифицированным ПО, т.к. используются программой ""LTR22"  ( и др. подобными программами) из методики поверки...

Еще бы лучше, если бы ltr-сервер и API интерфейс так же были перечислены в "Методике поверки"!

Мне интересен опыт других потребителей продукции L-Card: каким образом решался вопрос с сертификацией ПО при внедрении систем автоматизации измерений?
Спасибо.

Убедился, что "метрологические" программы работают в Windows через LTR-сервер.

Если бы были утверждающие документы ООО Л-Кард, что LTR-сервер в Windows и LTR-cервер в Linux-QNX работают эдентично и "метрологические" программы используют тот же API-интерфейс, который предоставляется разработчику прикладного ПО, то ,возможно, вопросы по сертификации ПО прикладных систем сильно бы упростились...

Программу ltr-сервер м.б. обязательно надо было бы упомянуть в п. 5.2.1 ""Методики поверки" хотя бы потому, что без ltr-сервера "метрологические" программы LTR11, LTR27, LTR22 просто не работают.

Опять же, как не метролог, скажу, что, по-моему, метрология должна заниматься теми вопросами, которые влияют на метрологию (иначе мы метрологов заставим заниматься, например, конфликтом драйверов или влиянием очередного обновления ОС или BIOS на показание прибора, или вирусов, принятых по интерфейсу Ethernet). И в любой МП всегда присутствует концепция (модель) тех факторов, которые могут влиять на метрологию, и в этой модели всегда отбрасываются незначимые факторы. Так, интерфейс API входит в ПО "LTR22".  А LTR-сервер, присутствующий в РЭ, в данной модели считается ПО, не влияющим на метрологию. Ну, примерно, как драйвер сетевой карты материнской платы от производителя компьютера, или любая другая интерфейсная программа, без которой нельзя собирать данные удалённо ...
Кстати, новые версии LTR-сервера уже могут работать как служба Windows, запускаемая при включении компьютера.

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

Не вполне согласен с Александром. Прикладное ПО может вносить  в результат измерения.

Например при освоении LTR22 я столкнулся с тем, что при вызове ф-ции LTR22_ProcessData() коды АЦП в мВ электрического сигнала преобразовывались не правильно. И только после обновления версии API-интерфейса ( с сайта L-Card) проблема исчезла.

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

Спасибо Владиславу за предложение: мы подумаем  и ответим.

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

@Владиславу: почему передачу исходных кодов ПО Вы считаете "невыполнимой" процедурой? Исходные тексты ltr-сервера и API-интерфейса модулей лежат в открытом доступе...

Другой пример: сертификация ОС QNX ( занимается СВД www.kpda.ru ) для военных применений требует обязательного наличия исходных текстов ядра ОС.

"Метод сличения" сводит "на нет" преимущество сертифицированного измерительного LTR-крейта.

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

В каком объеме проводить сличение: по каждому ИК системы?

Сколько раз выполнять измерения на прямом и обратном ходе ( обычно не менее 200 раз на одном ИК для получения оценки погрешности с достоверностью 0.95 )?

Нам хотелось бы от всех этих работ отказаться на законных основаниях...

Прибор Метран-970  (http://docs.cntd.ru/document/673967956) позволяет получить по цифровому каналу связи готовый результат измерения в единицах давления или температуры. Цифровой канал связи ведет обмен по протоколу, предусматривающему получение данных с проверкой контрольной суммы. Для нашего "сертифицирующего органа" этого достаточно для сертификации прикладной системы измерения на базе Метран-970 без к-либо дополнительной процедуры первичной поверки.

Если бы в API LTR-модулей были дополнительные функции вычисления давления по характеристике датчика 4-20мА или вычисления температуры по ГОСТ-овским характеристикам термопар и термосопротивлений, то для "сертифицирующего органа" процесс получения результата измерения замыкался бы в пределах аппаратно-программной части сертифицированного LTR-контроллера.

Трудоемкие процедуры первичной поверки каждого ИК прикладной системы измерения не потребовались бы!

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

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

Для этого нужно посмотреть на LTR-крейт не только как на измеритель величин электрических сигналов, но и как на измеритель физических значений давления, температуры, или других "абстрактных" физических величин с известной градуировочной характеристикой в виде полинома n-й степени.

Предложения:
- В документе "Методика поверки" отдельным абзацем записать, что перед запуском "метрологических программ" требуется запустить программу ltr-сервер. Сделать ссылку не документ с описанием ПО LTR-системы "КРАТКОЕ РУКОВОДСТВО ПО ИСПОЛЬЗОВАНИЮ
ПРОГРАММЫ LTRSERVER версии 1.5.2.x" (ltrserver.pdf).

- В документе "Методика поверки" отдельным абзацем записать, что "метрологические программы" разработаны с использованием функций из API-интерфейса. Сделать ссылку на документ "Базовая библиотека работы с крейтом LTR" (ltrapi.pdf).

- Для вычисления значение давления предусмотреть новую функцию в API-интерфейсе, в которой для каждого канала можно задать диапазон измерения давдения ( 0...Pmax) и соответсвующий диапазон мА ( 4...20 или 0...20 ).

- Для вычисления значения температуры предусмотреть новые функции в API-интерфейсе, в которых для каждого канала задать тип ГОСТовских термопар и термосопротивлений. Соответственно вести пересчет измеренных мВ или Ом.

- Для "абстрактной" физической величины предусмотреть новую функцию в API-интерфейсе, в которой для каждого канала задать полином пересчета n-й степени.

Леонид, а Вы можете привести ссылку на МП и описание типа СИ любого российского СИ, где подобная идея была бы воплощена. Честно, я не встречал ещё такой прогрессивной и продвинутой МП. Мне кажется, метролог должен застрелится прежде, чем согласится на абстрактную  физическую величину на входе прибора . А назвать-то как такой прибор? - "Измеритель абстрактных физических величин"?

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

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

Их всех я попытался объединить словом "абстрактные", готов согласиться на замену любым другим словом.

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

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

"Метрологически значимое" ПО  в этом случае будет "защищено" сертификатом LTR.

Ccылку дать пока не могу. Пытаюсь найти например здесь:
http://forum.nppmera.ru/index.php/topic,211.0.html

Леонид. На сколько я понял, Вы хотите видеть (и предлагаете "Л Кард" сделать) измерительную систему, как сертифицированный билдер из кубиков, где на каждый кубик нормированы (и подтверждены при сертификации) все его метрологические показатели. Если соединено последовательно 2 или более кубиков, то, на сколько я понимаю, с точки зрения метрологии,  - это есть измерительная система с косвенными измерениями (см. http://www.lcard.ru/lexicon/meas_accuracy ), где совокупная относительная и абсолютная погрешности вычисляются сложной функцией даже при простых функциональных зависимостях при соединении кубиков. А при полиномиальной зависимости от входной физической величины  - здесь вообще-то  большая математика начнётся, чтобы вычислить совокупные погрешности. Т.е., вместо того, чтобы поверять свой измерительный комплекс прямыми измерениями (со сквозной калибровкой и сквозным промером всего измерительного тракта), Вы хотите при поверке промерять только часть комплекса, а совокупные погрешности вычислять теоретически c использованием большой математики, а также с глубоким чувством веры в используемый сертифицированный программный кубик? То есть, по сути, хотите круто усложнить методику поверки на свой измерительный комплекс в части обоснования метрологической части этой методики?

На сколько я понимаю, косвенные измерения закладывают в МП только в особых случаях, когда прямые измерения сделать нельзя по каким-то физическим причинам, т.е билдер  нужен только для особых случаев, и закладывать такой билдер как универсальную концепцию для "Установки измерительной LTR" - мне кажется неразумно.

Уточняю по терминологии:
Если модель измерений построена по схеме:
физ. величина 1 -> датчик -> преобразователь с нормировкой -> физ.величина 2 -> "Установка измерительная LTR", то это в метрологии называют совместными измерениями физических величин 1 и 2. Но от этого суть вышеизложенной проблемы не меняется - по сути, измерение входной физической величины 1 - косвенное.

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

У нас разделяют комплектную или поэлементную поверку ИК.

При поэлементной поверке ( датчик отдельно, измерительный контроллер отдельно ), суммарная погрешность есть среднее квадратичное погрешности отдельных элементов, умноженное на к-т вероятности ( примерно 1.3, при гипотезе нормального распределения погрешности с вероятностью 0.95).

Методику поверки LTR-крейта я предложил не менять, а дополнить упоминанием необходимых для ее выполнения компонентов ПО:
- ltr-сервер,
- API-интерфейс.

В API-интерфейс я предложил ввести доп. функции пересчета величины измеренного электрического сигнала в величину измеренного физического параметра.

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

Попробуем проработать заданные Александром вопросы, изучив Методики поверки контроллеров, где вычисление физической величины внедрено в контроллер.

Посмотрел РЭ (в которое включена Методика поверки МП) на прибор Метран-970
http://www.metran.net/3-%C8%E7%EC%E5%F0 … %D0%DD.doc
Данный прибор позволяет получать по протоколу Modbus как измеренные значения электрических сигналов (аналог LTR), так и вычисленные из них значения  физических величин: давлений, температур и т.д.

В МП в разделе 3.4.3 описаны действия для поверки измерения значения электрических сигналов (аналог LTR).

В МП в разделе 3.4.4 описаны действия для поверки зимерения значений температур. С учетом того, что измерение мВ и Ом уже поверено в 3.4.3, делаю вывод что в разделе 3.4.4 поверяется правильность вычисления температур из ГОСТ-овских полиномов или формул.

В данной МП расчет велчины далений по линейной характеристике из измеренных мА вообще не поверяется.

Т.о. мне кажется, что объем и способы поверок лежат на откупе разработчика МП и согласующего МП органа.

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

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

На странице 41 МП указано:

Здесь в качестве результата измерения - электрическая величина.

Сами каналы прибора "Метран-970" конфигурируются. Можно в качестве результата измерения считывать величину электрического сигнала ( мА, мВ, В, Ом ), а можно задать линейную, квадратичную или пользовательскую характеристику, по которой будет расчитана из электрической и выдана  в качестве результата физическая величина...

Вроде бы мы с Александром многое подробно обсудили.

А какое мнение у @Метролога и @Владислава?