Вопросы по МИ 3290-2010 и МИ 3286-2010

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

Дмитрий Борисович, по Вашему мнению получается все Изготовители злостные преступники, а не радетили за качество своей продукции. Но это уже не метрология, а уголовщина.

как раз в уголовщине нас всех поголовно подозревает МИ 3290-2010 и МИ 3286-2010

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

и какое отношение "качество продукции" имеет к "контрольной сумме" ?

Александр Анатольевич, в "европах" аналогичные требования.

WELMEC 7.2 "Программная идентификация. Последовательность считываемых характеристик программного обеспечения, однозначно связанных с пролграммным обеспечением (например, номер версии, контрольная сумма)". Встроенное ПО должно иметь однозначную идентификацию для СИ с рисками классов от В до Е.

[richie 1]

...

Александр Анатольевич, в "европах" аналогичные требования.

WELMEC 7.2 "Программная идентификация. Последовательность считываемых характеристик программного обеспечения, однозначно связанных с пролграммным обеспечением (например, номер версии, контрольная сумма)". Встроенное ПО должно иметь однозначную идентификацию для СИ с рисками классов от В до Е.

Снова, прости за вмешательство.

В "европах" видно, что специалисты прорабатывают документы.

Сейчас уже того же вельмека 7точка2 версия 4 от 2009 года.

1. В нём, кстати, на странице 17 исключено требования предоставления при необходимости ИСПОНЯЕМОГО кода "(plus the executable code if necessary)".

Заметьте - ИСПОЛНЯЕМОГО кода, а не как в переведённом на "великий и могучий" кусочке части 4, предоставленного, если не ошибаюсь, Даниловым Александром Александровичем

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

2. Для идентификации написано:

"Пример приемлемого решения: Идентификация юридически значимого программного обеспечения содержит две части.

В первой части (А) происходит изменение идентификации, если измененное программное обеспечение требует нового утверждения.

Часть (В) показывает только незначительные изменения в программном обеспечении, например, исправление промахов (bug fixes), которые не требуют нового утверждения."

Заметьте, двойная версия юридически значимого ПО! Что для встроенного ПО вполне разумно и чаще всего так и реализовано производителями.

Далее, для моего вида приборов, квалифицированного по "Risk Class B" в вельмеке написано, что:

"1. Изменения юридически значимого программного обеспечения требует информирования об этом уполномоченного органа.

Уполномоченный орган решает, необходима ли идентификация нового программного обеспечения, или нет.

Новая идентификация программного обеспечения требуется только тогда, когда изменения программного обеспечения

приводят к изменению уже утвержденных функций или характеристик."

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

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

В приемлемых решениях по идентификации написано, что идентификация состоит из двух частей (A и B),

где часть A - версия юридически значимого программного обеспечения,

часть B - незначительные изменения в программном обеспечении, например, исправление промахов (bug fixes)

"Часть (А) идентификации состоит из номера версии или номера ТАС (Type Approval Certificate – Сертификат утверждения типа)."

И никакого упоминания контрольных сумм нет и в помине для моего класса Би.

3. Требования для моего оборудования в вельмеке сводятся к наличию ватч-дог таймера и хранению параметров в EEPROM.

Изменено 24 Февраля 2011 пользователем richie

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

Андрей Павлович, у меня имеется официальный перевод ВЭЛМЭК 7.2 только редакции 29 октября 2004 г.

Не знаю насколько изменился этот документ в редакции 2009 г. В редакции 2004 г были следующие требования к информации о ПО в описании типа:

[pivak 33]

Андрей Павлович, у меня имеется официальный перевод ВЭЛМЭК 7.2 только редакции 29 октября 2004 г.

Не знаю насколько изменился этот документ в редакции 2009 г. В редакции 2004 г были следующие требования к информации о ПО в описании типа:

Владимир Алексеевич!

Последняя официальная версия Welmec 7.2 от мая 2009, релиз 4, как и говорилось. Не знаю есть ли она на русском, но на официальном сайте Welmec она свободно выложена на английском. Я не буду вдаваться в детали сравнения наших МИ и Welmec, приведу лишь один факт. В Welmec приведена форма протокола (test report) для проверки ПО. Предоставление такого отчета в ГЦИ СИ и ВНИИМС от зарубежной компании-изготовителя, которая полностью работает по Welmec, вызывает лишь смех, т.к протокол требует только ответы на вопросы без каких либо цифр (для классов риска типа В). Все серьезное, и это в Welmec отмечено, - для счетчиков газа, воды, тепла, энергии, что понятно...Не понятно только как мы гармонизируем свои НТД с зарубежными, если эти протоколы отвергаются напрочь, как несоответствующие МИ,которое вроде как на welmec основано

Изменено 22 Февраля 2011 пользователем pivak

[Дедюхин А.А. 309]

Александр Анатольевич, в "европах" аналогичные требования.

а в "америках" и "азиях" как дела обстоят? мы больше приборов поставляем оттуда, это более животрепещущее

и все-таки как контрольная сумма влияет на качество СИ?

у меня имеется официальный перевод ВЭЛМЭК 7.2 только редакции 29 октября 2004 г.

Не знаю насколько изменился этот документ в редакции 2009 г.

о того, что кто-то что-то не перевел на русский язык оно не перестало существовать на свете, правда?

Не понятно только как мы гармонизируем свои НТД с зарубежными, если эти протоколы отвергаются напрочь, как несоответствующие МИ,которое вроде как на welmec основано

а это уже экстремизм, Алексей Вячеславович! над этими документами (МИ) работали "лучшие и заслуженные аккадемики нашей страны" и попытка оклеветать и деятельность - это и есть экстремизм

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

Владимир Алексеевич!

Последняя официальная версия Welmec 7.2 от мая 2009, релиз 4, как и говорилось. Не знаю есть ли она на русском, но на официальном сайте Welmec она свободно выложена на английском. Я не буду вдаваться в детали сравнения наших МИ и Welmec, приведу лишь один факт. В Welmec приведена форма протокола (test report) для проверки ПО. Предоставление такого отчета в ГЦИ СИ и ВНИИМС от зарубежной компании-изготовителя, которая полностью работает по Welmec, вызывает лишь смех, т.к протокол требует только ответы на вопросы без каких либо цифр (для классов риска типа В). Все серьезное, и это в Welmec отмечено, - для счетчиков газа, воды, тепла, энергии, что понятно...Не понятно только как мы гармонизируем свои НТД с зарубежными, если эти протоколы отвергаются напрочь, как несоответствующие МИ,которое вроде как на welmec основано

Алексей Вячеславович, я тоже считаю, что подход к исследованию ПО должен зависеть от назначения СИ (класса риска). В МИ 3286 подход от обратного, сначала исследования, как для класса риска Е, с предоставлением всех результатов, а только потом заключение, что защита не требуется.

[su215 658]

К вопросу о тестировании ПО : ссылка.

[Дмитрий Борисович 1 013]

К вопросу о тестировании ПО : ссылка.

Извините за грубые слова - Паранойя Профессора Юрия Петрова!

Ответы на цитаты:

Дело в том, что проектировщиками не используются научные достижения, которые позволили бы свести риски дальнейшей эксплуатации объектов к минимуму.

Если это заявляется то должно подкрепляться основательными аргументами. Говорить просто об отсутствии инновационной

политике крупнейших госкомпаний и госкорпораций - ГОЛЫЕ СЛОВА! Например таже корпорация "ИРКУТ" проводит расчеты

и моделирование на суперкомпьютерах! А что делают в Сарове???

- Она уже и 17 лет назад была острой. Проблема начала обостряться с восьмидесятых годов прошлого века, когда стали очень быстро усложняться системы управления, и уже была потеряна возможность их непосредственно руками потрогать. Вручную современный самолет не проверишь. Он настолько сложен, что нужно проверять проект. А чтобы проверять проект, нужно знать последние достижения прикладной математики: вполне возможны системы, которые теряют все свои свойства при самых малых отклонениях от расчетных значений.

Пусть профессор посмотрит хотябы учебное пособие для вузов "Бортовые цифровые вычислительные машины и системы" под

редакцией проф.В.И.Матова, Москва"Высшая школа" 1988г.(год специально отметил!)

- Да, но не проверяется! И особенно это стало сказываться сейчас, когда перевели проектирование на вычислительные машины. В целом это замечательно, но коль скоро их перевели, надо очень тщательно все алгоритмы проверять на эквивалентность преобразований, которые используются при уравнениях. Не проверяют! Стали мы более подробно смотреть, как это все происходит на самом деле, и выяснилось, что сейчас вообще отсутствует проверка программ

Профессор предлагает протестировать MathCAD, AutoCAD, Excel и тому подобные распространенные системы ? Или более

совершенные? Или предлагает свои системы для проектирования???

Любая система автоматизированного проектирования будет иметь ОШИБКИ!!! Так как анализ базируется на МОДЕЛИ (причем

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

Хотя она так и останется моделью! Насколько всё учли - сказать порой бывает очень сложно!

Все претензии сперва нужно предъявить системе подготовки специалистов в вузе!

Приходят молодые специалисты, умеют работать с определенным набором систем автоматизированного проектирования!

А взаимосвязи между параметрами - НЕЗНАЮТ!!!

И не понимают что это автоматизированные средства проектирования, а не автоматические!

Профессора НЕ ОБЪЯСНИЛИ!!!

[Ramil 148]

...

Ну Вы в принципе не противоречите.

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

А все потому что никто ручками не трогал. И не потрогает! Потому что: тендеры выигрывает тот кто дал меньшую цену, а значит денег на авторский надзор и опытную эксплуатацию нет, а проектирующая организация не сопровождающая свой проект во время опытной эксплуатации никогда не накопит опыт!

Согласно, ГОСТ 34.601-90 "Автоматизированные системы. Стадии создания".

"Стадия 1. Формирование требований к АСУ.

Стадия 2. Разработка концепции АСУ.

Стадия 3. Техническое задание.

Стадия 4. Эскизный проект.

Стадия 5. Технический проект.

Стадия 6. Рабочая документация.

Стадия 7. Ввод в действие.

Стадия 8. Сопровождение АСУ."

Вот Вы Дмитрий Борисович, как разработчик автоматизированной системы насколько соответствуете этому ГОСТ-у?

Есть ли у Вас полная информация о жизненном цикле Вашего изделия?

А по существу: Время уходит. Скоро поколение которое все строило уйдет и останется молодежь, которая кроме компьютеров ничего не знает.

Изменено 25 Февраля 2011 пользователем Ramil

[Дмитрий Борисович 1 013]

Вот Вы Дмитрий Борисович, как разработчик автоматизированной системы насколько соответствуете этому ГОСТ-у?

Есть ли у Вас полная информация о жизненном цикле Вашего изделия?

Приведенные этапы - это стандартные этапы при создании любого технического изделия.

Меня учили еще и тому, что разработчик ПОЖИЗНЕННО несет ответственность за разработку информационно- измерительных

систем, измерительных систем и т.д.

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

Вопрос не в этом.

Вопрос упирается в методах тестирования технических устройств, механизмов, сооружений и т.д.

Когда пришел на разработку после института (1980г.), опытные специалисты говорили: что сейчас есть огромный

недостаток при проведении испытаний - отсутствие граничных испытаний, невозможно оценить запас регулировочных

элементов и т.д.

Но потом и они поняли что в полном объеме на современных приборах с микроконтроллерами, встроенными микро-ЭВМ сделать

это невозможно! Они тогда еще привыкли работать с лампами у которых разброс параметров 20...30%. А у полупроводниковых

элементов разброс 200...300%!!!

Но это лирика.

Проверять, тестировать, аттестовывать (как еще можно выразиться?) конечно НУЖНО!

Весь вопрос КТО, в КАКОМ ОБЪЕМЕ, и НА КАКОМ ЭТАПЕ???

На этапе утверждения типа это уже ПОЗДНО!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Тем более на уровне ГЦИ СИ!!!

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

Это должны быть стадии 4 - 5 - 6!

[Ramil 148]

Проверять, тестировать, аттестовывать (как еще можно выразиться?) конечно НУЖНО!

Весь вопрос КТО, в КАКОМ ОБЪЕМЕ, и НА КАКОМ ЭТАПЕ???

На этапе утверждения типа это уже ПОЗДНО!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Тем более на уровне ГЦИ СИ!!!

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

Это должны быть стадии 4 - 5 - 6!

Позвольте с Вами не согласится, почему все видят область действия МИ где-то между калькулятором и EXселем.

Речь идет о всем ПО. Если извините у Вас программа в VB, то Вам извините и скрывать то нечего, а если это серьезная программа, то ..

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

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

А потому никто не может оценить к чему может привезти исправление в программе.

И потому нельзя написать программу, в которой потом не нужно ничего исправлять.

Потом выпускают патчи к программам, патчи к патчам.

Потому я и согласен с разработчиками МИ, внес изменение в ПО, тестируй заново.

[Ramil 148]

Приведенные этапы - это стандартные этапы при создании любого технического изделия.

Меня учили еще и тому, что разработчик ПОЖИЗНЕННО несет ответственность за разработку информационно- измерительных

систем, измерительных систем и т.д.

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

Вопрос не в этом.

Вопрос упирается в методах тестирования технических устройств, механизмов, сооружений и т.д.

Когда пришел на разработку после института (1980г.), опытные специалисты говорили: что сейчас есть огромный

недостаток при проведении испытаний - отсутствие граничных испытаний, невозможно оценить запас регулировочных

элементов и т.д.

Но потом и они поняли что в полном объеме на современных приборах с микроконтроллерами, встроенными микро-ЭВМ сделать

это невозможно! Они тогда еще привыкли работать с лампами у которых разброс параметров 20...30%. А у полупроводниковых

элементов разброс 200...300%!!!

Рад, что у нас не все так плохо, а то смотришь и на ум только одно слово приходит: Уныние.

[Фёдоров_Ф 298]

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

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

А потому никто не может оценить к чему может привезти исправление в программе.

И потому нельзя написать программу, в которой потом не нужно ничего исправлять.

Потом выпускают патчи к программам, патчи к патчам.

В таких случаях я цитирую мультик (кажется) "Крылья, ноги, хвосты": "Лучше день потерять, зато потом за час долететь!"

Никому не хочется день терять здесь и сейчас. Но когда возвращаешься к этой же работе через неделю и не можешь вспомнить, зачем был написан данный текст, то возникает ли мысль: "Лучше бы тогда не торопился! Потратил часть времени на "дурацкие" комменты."?

[Дедюхин А.А. 309]

Потому я и согласен с разработчиками МИ, внес изменение в ПО, тестируй заново.

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

[su215 658]

Потому я и согласен с разработчиками МИ, внес изменение в ПО, тестируй заново.

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

Не так это смешно, как может показаться. Если на минуту предположить, что мир устроен не так, как рисуют наши либералы, и не все вокруг - наши "друзья", то постоянные обновления сотовых, операционных систем и т.д. - не такая уж безобидная штука. Тем более учитывая, что на этих операционках, EXELях и т.п. - вся наша промышленность, финансы, управление. А то, что мы окружены не друзьями, видно невооружённым глазом.

[Ramil 148]

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

Насчет сотовых не скажу, не знаком.

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

Просто как пример приведу историю с "Тойотой".

Все технические подробности не знаю, но вкратце, было так:

Создали они авто, прошли испытания, все норм, пустили в серию.

Потом какой то специалист (видимо крупный) поменял одну детальку, на вроде такую же.

Эта деталь не выдерживала нагрузки(или стиралась, или еще что то не так делала - не знаю), но это

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

Вот к чему могут приводить как бы "мелочи".

[Дмитрий Борисович 1 013]

Позвольте с Вами не согласится, почему все видят область действия МИ где-то между калькулятором и EXселем.

Речь идет о всем ПО. Если извините у Вас программа в VB, то Вам извините и скрывать то нечего, а если это серьезная программа, то ..

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

Потому я и согласен с разработчиками МИ, внес изменение в ПО, тестируй заново.

Позвольте и мне с Вами не согласиться.

Если внимательно прочитать эти МИ то станет понятно что их область действия где-то между калькулятором и

EXселем. и причем без разграничения по какимто типам приборов. Дал информацию что содержит ПО - тестируй!

Вам наверное не повезло с разработчиками ПО....

Работаю с программным обеспечением с 1980г. и ниразу не видел чтобы разработчики не писали комментариев.

Горы бумаги!!!!Куча разрисовок алгоритмов.Не говоря что еще находится в компьютерах.

Кто занимался однокристальными микропроцессорами - вели сразу 3...4 темы. И разные! Без записей невозможно!

Недавно один разработчик уходя на пенсию говорил другому: " Как хорошо что я приучился вести комментарии. Я даже

через 3года, посидев 3...5дней могу вспомнить что делал и зачем!"

Системные программисты - каждый день запись и отчеты. Без этого нельзя даже вспомнить в понедельник чем закончилась

пятница , не говоря об отпусках....

НО почему мы так хотим проверить, то в чем не очень разбираемся?

Анализируем алгоритмы, проверяем арифметику.... А как быть с компилятором???? Каким пользоваться???

Время от времени и они меняются и обновляются...А исполняемый код определяется им. От его качества зависит и скорость

выполнения подпрограмм и корректность логических операций. И контрольная сумма.

Разные разработчики выбирают разные компиляторы. Кто чему больше доверяет.И мнения диаметрально противоположные.

Пока кто-то не "накололся" в каком-то глюке...

Так что мы тестируем по эти МИ?

[Дмитрий Борисович 1 013]

Не так это смешно, как может показаться. Если на минуту предположить, что мир устроен не так, как рисуют наши либералы, и не все вокруг - наши "друзья", то постоянные обновления сотовых, операционных систем и т.д. - не такая уж безобидная штука. Тем более учитывая, что на этих операционках, EXELях и т.п. - вся наша промышленность, финансы, управление. А то, что мы окружены не друзьями, видно невооружённым глазом.

МИР ПРЕКРАСЕН!!!!

Улыбнитесь Вас снимает скрытая камера :YES!:

[Ramil 148]

Позвольте и мне с Вами не согласиться.

Если внимательно прочитать эти МИ то станет понятно что их область действия где-то между калькулятором и

EXселем. и причем без разграничения по каким то типам приборов. Дал информацию что содержит ПО - тестируй!

Вам наверное не повезло с разработчиками ПО....

Работаю с программным обеспечением с 1980 г. и ни разу не видел чтобы разработчики не писали комментариев.

Горы бумаги!!!! Куча зарисовок алгоритмов. Не говоря что еще находится в компьютерах.

Кто занимался однокристальными микропроцессорами - вели сразу 3...4 темы. И разные! Без записей невозможно!

Недавно один разработчик уходя на пенсию говорил другому: " Как хорошо что я приучился вести комментарии. Я даже

через 3 года, посидев 3...5 дней могу вспомнить что делал и зачем!"

Системные программисты - каждый день запись и отчеты. Без этого нельзя даже вспомнить в понедельник чем закончилась

пятница , не говоря об отпусках....

НО почему мы так хотим проверить, то в чем не очень разбираемся?

Анализируем алгоритмы, проверяем арифметику.... А как быть с компилятором???? Каким пользоваться???

Время от времени и они меняются и обновляются...А исполняемый код определяется им. От его качества зависит и скорость

выполнения подпрограмм и корректность логических операций. И контрольная сумма.

Разные разработчики выбирают разные компиляторы. Кто чему больше доверяет.И мнения диаметрально противоположные.

Пока кто-то не "накололся" в каком-то глюке...

Так что мы тестируем по эти МИ?

И так Вы сами утверждаете, что процесс сложный.

Хорошо, что у Вас все поставлено на нужный лад. И может быть Вас бы и не стоило проверять.

Но нужно понимать, что МИ для всех, а не только для Вас и речь идет о системных требованиях ко всем разработчикам.

Нам приходится работать с различными СИ и ПО к ним. Так я скажу Вам, зная заранее, что некоторое ПО (кстати и СИ в том числе!) такое "глючное", никогда бы не связывались.

Другое дело, что насколько хорошо будут тестировать то же вопрос.

[Дмитрий Борисович 1 013]

И так Вы сами утверждаете, что процесс сложный.

Так я скажу Вам, зная заранее, что некоторое ПО (кстати и СИ в том числе!) такое "глючное", никогда бы не связывались.

Другое дело, что насколько хорошо будут тестировать то же вопрос.

Да процесс очень сложный, и "втиснуть" его в рамки каких либо стандартных рекомендаций НЕВОЗМОЖНО.

В тоже время непонятно, почему Вы заранее зная что ПО "глючное" - покупаете его и внедряете????

Если не зная купили, то протестировать его заранее никто ВАМ достоверно НЕ сможет!!!

Вообще на мой взгляд дискуссия заходит в тупик....

Опять получилась стенка, и подозрения что кто-то каког-то хочет провести....

Еще раз хочу подчеркнуть - ТЕСТИРОВАТЬ НУЖНО! МЕТОДЫ? ВРЕМЯ? КТО? ГДЕ? КАКОВА СТОИМОСТЬ?

На данный момент времени, МИ 3290-2010 и МИ 3286-2010, мягко говоря НЕ ДАЮТ никакого ответа на эти вопросы.

Ответьте на вопросы:

- кто и какой прибор протестировал ПО по методу сравнения с "эталонным" ПО.Только конкретно...

- кто и какой прибор провел оценку влияния ПО на метрологические характеристики проверяя только алгоритмы, арифметику,

исходный код ит.д.

- кто и на каком приборе выявил что встроенное ПО вносит НЕ ДОПУСТИМОЕ влияние на метрологические характеристики.

Именно ПО, а не весь прибор в целом!

- кто и на каком приборе выявил что его метрологические характеристики НЕ соответствуют записанным на него. Методы,

методики и т.д.

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

Предлагаю в течении недели всем ответить на эти вопросы. Конкретно по типам приборов и их характеристикам...

[Фёдоров_Ф 298]

Еще раз хочу подчеркнуть - ТЕСТИРОВАТЬ НУЖНО! МЕТОДЫ? ВРЕМЯ? КТО? ГДЕ? КАКОВА СТОИМОСТЬ?

На данный момент времени, МИ 3290-2010 и МИ 3286-2010, мягко говоря НЕ ДАЮТ никакого ответа на эти вопросы.

Ответьте на вопросы:

- кто и какой прибор протестировал ПО по методу сравнения с "эталонным" ПО.Только конкретно...

- кто и какой прибор провел оценку влияния ПО на метрологические характеристики проверяя только алгоритмы, арифметику,

исходный код ит.д.

- кто и на каком приборе выявил что встроенное ПО вносит НЕ ДОПУСТИМОЕ влияние на метрологические характеристики.

Именно ПО, а не весь прибор в целом!

- кто и на каком приборе выявил что его метрологические характеристики НЕ соответствуют записанным на него. Методы,

методики и т.д.

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

Предлагаю в течении недели всем ответить на эти вопросы. Конкретно по типам приборов и их характеристикам...

Поддерживаю целиком.

Но ответов ни на один из поставленных вопросов дать не могу... Увы

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

Еще раз хочу подчеркнуть - ТЕСТИРОВАТЬ НУЖНО! МЕТОДЫ? ВРЕМЯ? КТО? ГДЕ? КАКОВА СТОИМОСТЬ?

На данный момент времени, МИ 3290-2010 и МИ 3286-2010, мягко говоря НЕ ДАЮТ никакого ответа на эти вопросы.

Ответьте на вопросы:

- кто и какой прибор протестировал ПО по методу сравнения с "эталонным" ПО.Только конкретно...

- кто и какой прибор провел оценку влияния ПО на метрологические характеристики проверяя только алгоритмы, арифметику,

исходный код ит.д.

- кто и на каком приборе выявил что встроенное ПО вносит НЕ ДОПУСТИМОЕ влияние на метрологические характеристики.

Именно ПО, а не весь прибор в целом!

- кто и на каком приборе выявил что его метрологические характеристики НЕ соответствуют записанным на него. Методы,

методики и т.д.

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

Предлагаю в течении недели всем ответить на эти вопросы. Конкретно по типам приборов и их характеристикам...

Дмитрий Борисович, не понятно что Вам могут дать ответы на эти вопросы?

Во-первых, МИ 3290-2010 и МИ 3286-2010 говорят КТО должен тестировать ПО - Испытатель. МЕТОДЫ в них указаны в общем виде (это не значит что, я с ними согласен). А вот ВРЕМЯ, ГДЕ и КАКОВА СТОИМОСТЬ могут быть определены только для конкретных СИ, а не в общем.

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

В-третьих, имеет место и ноу-хау и конфиденциальность по данным оценкам, особенно, при НЕ соотвествиях.

Да МИ 3290-2010 необходимо корректировать, а МИ 3286-2010 - существенно изменять или заменять. Но необходимо, что-то предлагать, а не только отвергать.

[Дедюхин А.А. 309]

Насчет сотовых не скажу, не знаком.

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

а вы подумайте и посмотрите на вопрос шире и глубже - при изменении прошивки ПО мобильный телефон около вашего уха вместо 1,8 Вт может выдать все 18 Вт (рак мозга обеспечен ), стиральная машинка вместо оборотов центрифуги 1800 об/мин даст 18000 об/мин - как результат разрушение и разлет осколков барабана и .... подумать страшно, что произойдет если вы окажетесь рядом; принимая во внимание, что сертификация продуктов питания и лекарств отменена, то .... травитесь и мрите себе нездоровье; короче - ДАЕШЬ ТОТАЛЬНУЮ СЕРТИФИКАЦИЮ ВСЕГО И ВСЯМ и как же при всем этом упустить сертификацию ПО для средств измерения, например для измерения толщины? именно это должно спасти нацию от вымирания, при употреблении тухлого йогурта

Просто как пример приведу историю с "Тойотой".

Создали они авто, прошли испытания, все норм, пустили в серию.

Потом какой то специалист поменял одну детальку В результате куча разбившихся людей и отзыв машин (озвучивали убытки в 2 млрд$).

Вот к чему могут приводить как бы "мелочи".

ну это же Toyota! А АВТОВАЗ у нас в стране такие проблеммы абсолютно не волнуют

Вообще на мой взгляд дискуссия заходит в тупик....

Опять получилась стенка, и подозрения что кто-то каког-то хочет провести....

- узаконенное шаманство, на которое нет ответов

Да МИ 3290-2010 необходимо корректировать, а МИ 3286-2010 - существенно изменять или заменять. Но необходимо, что-то предлагать, а не только отвергать.

еще одно подтверждение о необходимости изменения шаманского танца

[Дмитрий Борисович 1 013]

Дмитрий Борисович, не понятно что Вам могут дать ответы на эти вопросы?

Во-первых, МИ 3290-2010 и МИ 3286-2010 говорят КТО должен тестировать ПО - Испытатель. МЕТОДЫ в них указаны в общем виде (это не значит что, я с ними согласен). А вот ВРЕМЯ, ГДЕ и КАКОВА СТОИМОСТЬ могут быть определены только для конкретных СИ, а не в общем.

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

В-третьих, имеет место и ноу-хау и конфиденциальность по данным оценкам, особенно, при НЕ соотвествиях.

1.

КТО? ИСПЫТАТЕЛЬ! Вы отдаете себе отчет в том что нынешнее положение ГЦИ СИ (технологическая база, наличие специалистов

по программному обеспечению...) не позволяют провести эти испытания. В лучшем случае Вы получите записи - "Не

оказывает...", "Не влияет...", "Погрешность вычисления уравнений в 12000раз меньше..."

МЕТОДЫ.А какие методы Вы еще знаете? Или могут предложить ГЦИ СИ???

ГДЕ.Спросите Дедюхина А.А. - знает ли он ГЦИ СИ которые могут протестировать ПО и провести оценку влияния ПО на

метрологические характеристики анализаторов спектра R&S или Agilent Technology???

КАКОВА СТОИМОСТЬ. Здесь прошу прощения перегнул палку - конфедециальность вопроса уж точно присутствует.

2.

4месяца! Это огромное время на "рынке" средств измерения!Сколько тендеров на поставку оборудования за это время

прошло!Раньше мы на свои простые приборы укладывались в месяц испытаний с бумагами и месяц экспертизы в ВНИИМС.

Кроме того наверное перед выходом в свет этих рекомендаций, проводилось опробование этих положений на каких то

приборах...Или как обычно мы с Вами стали подопытными кроликами?

3.

А вот ноу-хау и конфиденциальность по данным оценкам - это НОНСЕНС! Они должны быть открыты и прозрачны.

Понятны для всех.Как поверочная схема.

[Ramil 148]

Просто как пример приведу историю с "Тойотой".

Создали они авто, прошли испытания, все норм, пустили в серию.

Потом какой то специалист поменял одну детальку В результате куча разбившихся людей и отзыв машин (озвучивали убытки в 2 млрд$).

Вот к чему могут приводить как бы "мелочи".

ну это же Toyota!

Собственно это был пример, когда поменяли с виду безобидную вещь, а результат отрицательный.

А АВТОВАЗ у нас в стране такие проблеммы абсолютно не волнуют

Проблемы АвтоВАЗа системные, одной деталью там не обойтись, там проще эмблемку на другое авто повесить. ))