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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Провёл тесты с использованием ЦАП примерно так как предлагалось выше.

Результаты и исходный текст теста здесь: https://yadi.sk/d/mTNtr6K3PvPEW

На LTR27 в первом слоте запускается опрос 16 каналов с частотой 1000 Гц для создания потока данных из крейта в LTR-сервер. ( имитация 10-ти АЦП с частотой опроса 100 Гц).

Тест запускается на LTR-27 во втором слоте. Сигнал с ЦАПа подается на 1-й канал LTR-27.

-Настраивается частота опроса 16-ти каналов (10, 50, 100, 200 Гц)

- запускается циклический опрос и пересчет кодов АЦП в мВ;

-при каждом 5, 15, 25  и т.д... опросе сигнал с ЦАПа cбрасывается в 0 мВ;

-при каждом 10, 20, 30 и т.д.. опросе сигнал с ЦАПа устанавливается в 69.9 мВ
и начинается отсчет  времени;

- данные с 16-ти  выводятся на экран (перенаправляются в файл )с отражением текущего времени (5 столбик);

- как только приходят данные по 1-му каналу с уровнем > 1мВ  - оценивается время от момента установки сигнала ЦАП в мс ( 4 столбик).

На всех представленных частотах опроса я не наблюдаю к-либо задержки от буферизации данных в крейте, в сервере или из-за Ethernet-TCP:
на каждом 11, 21, 31 и т.д. отсчете по 1-му каналу видно влияние установленного сигнала от ЦАП.

Буду рад критике и предложениям по доп. тестированию.

Александр,

Ваши разъяснения по эффекту "Межканальное прохождение" важны и ( как оказалось) актуальны.

Нашли оценку данного параметра для применяемого у нас АЦП PCI-1713
http://yadi.sk/d/o_Q_wauhRTsZe.

Интересно услышать Вашу оценку по сравнению с LTR11

Прошу уточнит: эффект "Межканальное прохождение" это дополнительная погрешность в момент переключения с одного канала на другой, или же эффект проявляется и в том случае, если ведется опрос только одного канала АЦП без переключения на другие каналы?

Если все же МП происходит при переключении каналов , то как долго в микросекундах длится негативное проявление от МП?

Cпасибо.

величины: Омы, Вольты, мАмперы, Герцы.

В обсуждаемом случае из LTR11 мы прочитаем Вольты, а нужно получить мАмперы. По какой формуле это можно сделать "законно", или опытным путем - выполнив градуировку?

Очень часто вопросы "внутренней кухни" определяют выбор нового оборудования.

Общение в Вашей техподдержке (уровень которой считаю очень высоким) повышает мой инженерный уровень "программиста" и помогает в обосновании выбора новых решений.

Спасибо.

Спасибо за консультацию.

Дело в том, что PCI-1713 не внесен в Госреестр, как не внесены в Госреестр другие составляющие каналов измерения наших измерительных систем. (именно поэтому применение LTR-решения мне кажется более предпочтительным).

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

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

Какой "инженерный" вывод можно сделать?

Правильно ли я понимаю, что -70дБ это в 10 миллионов раз подавление,
т.е. очень хорошее подавление, пренебрежимо малое?

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

Далее делается еще несколько преобразований с последующим осреднением. Это "рабочий опрос".

Ознакомившись с документом LTR11api.pdf я вижу, что точно такую же логику можно организовать и с LTR11, задавая последовательно 4 логических канала на 1-й физический аналоговый канал, 4 логических канала на 2-й физический канал и 4 логических канала на 3-й физический канал

И в дальнейшем использовать только преобразования 2, 3, 4 логических канала для каждого физического канала.

LChQNT=12;
LchTbl={0,0,0,0,1,1,1,1,2,2,2,2};

Частота опроса 12-ти логических каналов 600Гц,
частота опроса физических каналов 50Гц.

Если я что-то не так понимаю, прошу поправить. Спасибо.