Формат таблицы сигналов (аварий и пр.) для верхнего уровня

[uni]

Доброго.

Такой вопрос. В каком электронном виде лучше передавать описание сигналов программы ПЛК (вшитой), чтобы разработчику верхнего уровня было удобнее его использовать? Какой будет применяться верхний уровень не известно. Это может быть и SCADA, и операторская панель. В общем и целом, если клиенту не нужен OPC-сервер, а нужен только ПЛК и он сам всё "сверху" сделает, то как бы покрыть универсальным форматом все возможные хотелки по виду таблички сигналов? Её размер может быть до нескольких сотен элементов.

[Romcheg]

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

[uni]

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

Давайте уточню. Вот конкретный пример. Я проектирую HMI на EasyBuilder Pro для панели Weintek, мне нужны списки: DI, DO, AI, AO и внутренних регистров, плюс текстовое описание структур и перечислений. На основе полученных списков я формирую в Excel специализированную библиотеку тегов, которую уже использую в среде разработки (импортирую xls-файл). Дело в том, что в макросах среды я могу обращаться к тегу по имени и хорошо, если эти имена уже привязаны к адресам и имеют осмысленный идентификатор. Исходя из этого, мне удобнее иметь первоначальный набор в виде CSV-файла или сразу XLS.

Это единичный пример. Может быть другой проектировщик делает это как-то по-иному в своей среде. Вот доп. вопрос, удобно было бы использовать кодировку UTF-8 для списка сигналов? Например писать Δt, а не dt, использовать цифры в верхнем индексе. В среде EasyBuilder Pro этим можно пользоваться.

[Romcheg]

А как же вы планируете получить ответ на вопрос, когда неизвестно точно какая именно система будет использоваться разработчиками верхнего уровня?
Формат (CSV, или что-то еще), а также кодировка (ASCII или UTF-8) определяется только поддержкой этого в том ПО, которое планируется использовать на верхнем уровне. И если оно не известно, то и ответ на Ваш вопрос неизвестен.
Из личного опыта могу сказать, что CSV - это самый распространенный формат, в котором передается подобная информация между системами. И опять же, из личного опыта, могу сказать, что очень много скада-систем вообще не поддерживают функции импорта-экспорта своих баз переменных проекта в структурированные открытые форматы (больше всего смешит их аргументация: "А это никому не нужно").

[uni]

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

Можно попробовать узнать наиболее распространённые системы в России и покрыть их, если они имеют возможности импорта.

И если оно не известно, то и ответ на Ваш вопрос неизвестен.

Можно ведь пойти от противного. К примеру, вот тут кому-то не понравился pdf. :)

2) В ТЗ все материалы включая таблицы сигналов представлены в формате PDF, который к тому же еще и закрыт паролем. НЕНАВИЖУ проектировщиков, работающих в PDF (сколько не работаю, все время данный формат вызывает только торможение в процессе разработки)! Хоть раз заставить бы их самих делать системы по документации, представленной в таком формате.
...
Сами таблицы сигналов в основном представляются в структурированных форматах (csv,excel,word,таблицы СУБД), конечно же велик соблазн перекинуть все это структурированное многообразие через обычный буфер обмена методом copy-paste, что и было мной сделано. Теперь для быстрого формирования набора сигналов проекта можно просто копировать столбцы сигналов из ТЗ прямо в проект скады через буфер обмена.

Вопрос, как видно, вполне себе закономерен.

[Romcheg]

Не, заниматься анализом популярности систем я не буду, а такой готовой достоверной информации у меня нет. Я рекомендую Вам сделать это в формат CSV, это как минимум. Кодировку выбирать UTF8, почти все современные системы работают в ней (те, что мультиязычность поддерживают). С этим форматом будет больше всего шансов "угадать".

А про PDF - это как раз пример втыкания палок в колеса инженеру-разработчику от проектировщиков. Потому как, дать информацию в закрытом формате PDF - это верх издевательства, все равно в конечном итоге инженеру из него ручками набивать всю инфу.

[Jackson]

А про PDF - это как раз пример втыкания палок в колеса инженеру-разработчику от проектировщиков.

"Эта х%ень у нас нормой зовётся". (с) Проектанты ж проект делают, и для проекта оно им в ПДФ очень даже вполне годится. Как данные из CSV красиво вставить в проектную документацию? Тут возиться надо. Excel уже проще, но тоже придётся повозиться, а WORD - самое оно. Для проектантов.