Уставкин пишет:Вроде стандарт есть, и вопросов быть не должно.
Когда НАЧИНАЕШЬ ИСПОЛЬЗОВАТЬ станадарт вопросы и появляются.
1.Стандарт международный. В стандарте есть файлы описаний .cfg .hdr .inf в которых содержатся названия дискретных и аналоговых параметров,
дополнительные описания. Стандарт использует для этого ASCII.
А как быть с кириллицей, в какой кодировке должны использоваться строки описаний? Современные операционные системы используют UNICODE (которых тоже не одна).
2. Стандарт разработан институтом IEEE и имеет две ревизии 1991(IEEE Std 111-1991) и 1999 (IEEE Std C37.111-1999)
Они отличаются требованиями к форме заполнения полей в файле конфигурации и наличием дополнительных полей. Чтобы отличать эти версии введено дополнительное поле года ревизии и в его описании указывалось на
его критичность (обязательность). Отсутствие поля указывало на соответствие версии файла конфигурации 1991 году, наличие – году пересмотра (ввода изменений) стандарта.
В чем проблема?
Программа просмотра ориентирующаяся на оба стандарте IEEE определят его по значению 1999.
Более поздние корректировки должны определяться по другой дате.
В 2001 году появляется стандарт IEC 60255-24 First edition 2001-05 принятый МЭК.
Сам стандарт практически слово в слово копирует документ IEEE Std C37.111-1999.
Однако при описании года ревизии в качестве примера приводится 2000 год, а в разделе приложений указан 1997 год.
Некоторые производители ссылаются на поддержку IEC стандарта COMTRADE и ставят в файле конфигурации год ревизии
2001. Поэтому сторонняя программа просмотра ориентриующаяся на IEEE и вышедшая до 2001г может выдать ошибку, не поняв о какой ревизии идет речь.
В прошлом году вышел IEC 60255‐24 Ed 2.0/IEEE C37.111‐2013, Published on April 30, 2013
Новый стандарт имеет два логотипа IEEE/IEC, т.е. должен трактоваться однозначно. Есть ли в нем более строгое требование к данному полю пока не знаю, может кто из более сведующих подскажет.
Уставкин пишет:Программисту ведь не сложно сделать, чтобы "открывалось"
COMTRADE имеет две стороны - сторона записывающая в этом формате и сторона читающая.
Если это дело рук одного производителя, то вопросов, как правило, не возникает.
Если РАС (регистратор аварийных событий) или (функция РАС) записывает файл конфигурации с отклонениями от стандарта, то должна ли читающая программа распознавать это и производить корректировки
или просто сообщать об ошибке?
С точки зрения стандарта - второе, ибо стандарт предписывает в случае ошибки в критически важном поле считать файлы не соответствующими стандарту и читающая программа не обязана ее исправлять ибо не знает причину (источник) ошибки.
С точки зрения использования программы, а если она коммерческая и привлекательности - первое.
Проблема только в том, что читающая программа не знает заранее какие ошибки могут появиться от того или иного производителя. Поэтому если устройство эксплуатируется и производитель не собирается
менять его "прошивки" (хотя бы потому что прибор уже устарел) ищите (пишите) программу читающую данный формат, что и сделал Евгений Георгиевич (doro).
Для людей занимающихся написанием программ чтения полезно иметь подборку РЕАЛЬНО записанных файлов с различными "проблемами". Поэтому просьба к doro разместить где-нибудь - на своем сайте или на форуме -
тестовый архивчик с такими файлами - программистам он будет подспорьем. А может и форумчане добавят свое.
Уставкин пишет:А для этого надо из всех возможных вариантов (версий) COMTRADE - собрать один рекомендуемый шаблон
По моему каждая версия COMTRADE и есть рекомендованный шаблон. Может быть речь идет о том, чтобы собрать правильные примеры для всех вариантов стандарта.