Maiverik

Пользователи
  • Число публикаций

    17
  • Регистрация

  • Последнее посещение

Репутация

0 Новичок

О Maiverik

  • Звание
    Участник

Недавние посетители профиля

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

  1. Maiverik

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

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

    ФГИС "АРШИН"

    API работает. Другое дело, что формат XML описан не точно и отладка его формирования может занять несколько месяцев, т.к. после отправки приходится несколько недель ждать результата обработки, в котором обязательно будет указание на какую-нибудь ошибку типа "неверный формат даты", "а вот тут написано то что не должно быть написано" "если вы здесь что-то написали то тут нельзя ничего писать". Уже два месяца не можем отправить отчет из-за этого, но скоро должны победить.
  11. Вывод у вас не правильный. Во-первых, нигде нет определения что такое знак поверки, также как и указания на то что ГН является единственно возможным знаком поверки Во-вторых, "Результаты поверки средств измерений удостоверяются знаком поверки (написано на голографической наклейке) и (или) свидетельством о поверке.", в котором эту наклейку клеить совершенно не обязательно, но т.к. ее по указанию свыше лепят все ГЦСМы то в народе ходит миф что без нее свидетельства не действительны.
  12. Извините, что поднимаю динозавра, но не нужна данная дружба для указанного пункта.
  13. Вот смотрите, Вы согласны со мной, что коэффициенты прямо влияют на результаты. Теперь берем текст из ГОСТ Р 8.654-2009 нужное выделено жирным. По ГОСТу Вы не можете отнести калибровочные коэффициент к метрологически не значимой части, и соответсвенно ваше решение не осуществимо при текущем положении вещей . Я не знаю что здесь можно придумать, кроме того как снова и снова править ГОСТ, расписывать его положения более подробно. Например более подробно расписать определение метрологически значимой части, выделить калибровочные коэффициенты в отдельную категорию, и расписать правила их обновления и защиты.
  14. Как тогда устранить коллизию связанную с тем, что часть программы, содержащая калибровочные таблицы непосредственно влияет на метрологические характеристики, выдаваемые прибором, и по определению должна быть включена в метрологически значимую часть ПО?
  15. Я понимаю что на данный момент поменять что-то сложно, но ИМХО вариант с фиксированной контрольной суммой метрологического ПО вляется тупиковым. Система должна быть гибче. Как вы смотрите на такую общую схему для приборов со "сложным" ПО: 1. При испытаниях определяется метрологически значимая часть, влияющая непосредственно на результаты измерений. 2. К данной части определяется однозначный, неизменный, защищенный метод определения ее контрольной суммы (МОК) - именно его нужно защищать от какого либо изменения, фиксировать его суммы и т.п. а не само ПО, отвечающее за измерения. 3. МОК описывается в методике поверки СИ. 3. При поверке сумма, полученная по МОК, обязательно заносится поверителем в свидетельство. Это станет неким аналогом "пломбы". Что мы получаем? 1. Производитель волен обновлять свое ПО в рамках сохранения МОК неизменным, это снимет с производителей кучу проблем и упростит им жизнь. 2. Поверитель или контролирующий орган всегда сможет определить вносились ли изменения в ПО с момента последней поверки. Ведь мы именно этого добиваемся? 3. Любое изменение калибровочных таблиц будет вызывать изменение контрольной суммы, а не как сейчас делается в большинстве случаев - считают контрольноую сумму исполняемого файла, а файлы конфигурации, влияющие на результаты меняй как хочешь - сумма остается неизменной. (Да и по другомы не сделаешь, т.к. многие приборы нужно калибровать коэффициентами). В результате получаем "филькину грамоту" на выходе, которая ниочем не говорит. Основная проблема в данном подходе - определение МОК, но эту проблему решить гораздо проще чем пытаться осуществить неосуществимое, к чему нас обязывает текущее положение вещей.