Во первых, о типах:
Считаю благоразумным составить единую общедоступную таблицу с пронумерованным списком "душе угодных" типов (напр. до 256 шт).
1. на сколько плотно: думаю тут правильным было бы "узаконить" нестандартные подтипы DATE TIME, типа: TShortDate TDirectLogicData, TFloat64Date и т.д. а после воткнуть их на законных основаниях в уникальную таблицу..
1.1. PS таким образом можно вести реестр всевозможных сложных типов.
1.2. Предлагаю в контроллерах ввести структуру имеющую стартовую ячейку Начала Спецификации Буфера Обмена (СБО) устройства, а также Начала Данных Буфера Обмена (ДБО), а также их размеров в [Бт].. Таких структур можно в контроллере указать несколько следующих друг за другом (назовем их группы опроса).
Стартовая ячейка будет указываться в таких контроллерах как Direct, ScadaPack.. где сложно "двигать" этот базовый адрес и ячейка будет доступна для редактирования по месту на таких контроллерах (напр. RTU188) кот. могут этот адрес легко поменять..
1.3. Формат последующих за базовой ячейкой данных будет содержать метаданные, где каждый последующий байт будет содержать номер типа в таблице. Т.о. имеем четкую инфу о порядке параметров, их размеров, о типе (вид представления).
1.4. Непременно программист тут спросит, а как же узнать период опроса и названия параметров в таких метаданных?
Просто
. Достаточно с устройством распространить файл конфигурации устройства для OPC-сервера. Там и названия, и адреса по-умолчанию, и группы опрашиваемые с разным периодом и типы всегда указываются..
1.5. Как сопоставить телеМеханику
какой файл конфигурации от какого объекта автоматизации в поле? Хм.. ну тут думаю проблем не возникнет, если следующие за базовым адресом ДБО базисные данные будут содержать версию, дату билда и id разработчика)
1.6. Пример: на переферийный узел канала связи установили новый объект. Разработчик Верхнего Уровня (РВУ)
дает команду телемеханики "инициализация", указав СБО и ДБО. В этот момент читается метаинформация с групп и запоминается в ТМ. Тут РВУ видит тип устройства, разработчика, зав. номер и прочее.. Подбирает файл конфигурации для OPC и смело подключает это устройство однозначно.
2. Почему бы не оставить все эти типы? TWideString TShortString, TASCIIString...
3. Почему бы нет? Заложить эту информацию в сам тип.. TBCDInt
4. Опять же это можно отнести к сложным типам.. TShortFloat16, TInt16Div10, TInt16Div100?
Не думаю, что метаданные будут слишком большой расточительностью, но даже если и будут, то всегда можно уйти к свободному формату для каждой версии устройства индивидуально - задав данные только в файл - конфигурацию для OPC..! :)
Другой вопрос захотят ли это реализовать зажравшиеся в собственных нотациях и спецификациях к чужим девайсам РВУ? )))