Maiverik

Нет

Дату обновления эталонов можно брать отсюда https://fgis.gost.ru/fundmetrology/api/registry/11

а что делать

К надстройке samradDatePicker2019 нет доступа без пароля, соответсвенно не известно какие там трояны сидят

А какую проблему вы решили? обрабатывать данные за день стали?

Никак, эталоны должны быть указаны согласно реестру.

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

У меня 1.1 ФГИС2. Руководство пользователя. Публичный портал (1.1).pdf

Есть же обновленная инструкция

У вас до этого тоже проблема в АРШИНе была

значит не правильно кодируете.

в инструкции другого не было

пробел после : не нужен мы отправляем по адресу https://fgis.gost.ru/fundmetrology/pov/submit

Давайте здесь, пусть все знают

Наши отчеты уходят, получают статус "Received" и в дальнейшем этот статус обновляется, правда ждать приходится 2-3 недели... Например, последний отчет всисит в этом статусе еще с 13/03, до сих пор не обработан, сидим на иголках пройдет проверку или нет.

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

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

Извините, что поднимаю динозавра, но не нужна данная дружба для указанного пункта.

Вот смотрите, Вы согласны со мной, что коэффициенты прямо влияют на результаты. Теперь берем текст из ГОСТ Р 8.654-2009 нужное выделено жирным. По ГОСТу Вы не можете отнести калибровочные коэффициент к метрологически не значимой части, и соответсвенно ваше решение не осуществимо при текущем положении вещей . Я не знаю что здесь можно придумать, кроме того как снова и снова править ГОСТ, расписывать его положения более подробно. Например более подробно расписать определение метрологически значимой части, выделить калибровочные коэффициенты в отдельную категорию, и расписать правила их обновления и защиты.

Как тогда устранить коллизию связанную с тем, что часть программы, содержащая калибровочные таблицы непосредственно влияет на метрологические характеристики, выдаваемые прибором, и по определению должна быть включена в метрологически значимую часть ПО?

Я понимаю что на данный момент поменять что-то сложно, но ИМХО вариант с фиксированной контрольной суммой метрологического ПО вляется тупиковым. Система должна быть гибче. Как вы смотрите на такую общую схему для приборов со "сложным" ПО: 1. При испытаниях определяется метрологически значимая часть, влияющая непосредственно на результаты измерений. 2. К данной части определяется однозначный, неизменный, защищенный метод определения ее контрольной суммы (МОК) - именно его нужно защищать от какого либо изменения, фиксировать его суммы и т.п. а не само ПО, отвечающее за измерения. 3. МОК описывается в методике поверки СИ. 3. При поверке сумма, полученная по МОК, обязательно заносится поверителем в свидетельство. Это станет неким аналогом "пломбы". Что мы получаем? 1. Производитель волен обновлять свое ПО в рамках сохранения МОК неизменным, это снимет с производителей кучу проблем и упростит им жизнь. 2. Поверитель или контролирующий орган всегда сможет определить вносились ли изменения в ПО с момента последней поверки. Ведь мы именно этого добиваемся? 3. Любое изменение калибровочных таблиц будет вызывать изменение контрольной суммы, а не как сейчас делается в большинстве случаев - считают контрольноую сумму исполняемого файла, а файлы конфигурации, влияющие на результаты меняй как хочешь - сумма остается неизменной. (Да и по другомы не сделаешь, т.к. многие приборы нужно калибровать коэффициентами). В результате получаем "филькину грамоту" на выходе, которая ниочем не говорит. Основная проблема в данном подходе - определение МОК, но эту проблему решить гораздо проще чем пытаться осуществить неосуществимое, к чему нас обязывает текущее положение вещей.

к сожалению вопрос о защите авторских прав это не снимет но я думаю ничего страшного не случится