Я уже писал Вам, в Адастру, некоторые свои мысли по этому поводу, теперь я этот текст доработал. Данный текст направлен не столько на устранение конкретных недостатков, сколько на открытие дискуссии по идеологи современной SCADA-системы, поэтому ответа на каждое замечание я не жду, но хотелось бы узнать Ваше мнение в общем. Заранее извиняюсь за объем выплескиваемой информации.
Суть в том, что база каналов должна быть уподоблена UNIX-образной файловой системе по аналогии: диск=узел, директория=объект, файл=канал. Т.е. в разных объектах могут быть каналы с одинаковыми именами, объекты могут быть вложены друг в друга; объект может содержать ссылку на канал, содержащийся в другом объекте; каналы и объекты имеют определенный набор атрибутов. То, что написано ниже, только поясняет эту мысль, извините, если сумбурно. Я хорошо понимаю минусы такого подхода по сравнению с существующим: сейчас канал идентифицируется неким ID-номером (видимо 2байта), что позволяет достичь высокого быстродействия системы при пересчете канлов. Конечно, идентификация типа «диск/директории/файл» более ресурсоемка. Но этот вопрос во многом решается небольшой предварительной компиляцией таких идентификаторов до тех же двух-трех байтов. Зато какие замечательные получаются плюсы: клонирование объектов будет упрощено до минимума, дублирование экрана сопровождается простой заменой объекта- директории, программы обработки каналов на Техно IL и Техно LIST смогут легко устраивать циклы по одноименным каналам разных объектов, привязка FBD-блоков может осуществляться относительно текущего объекта-директории или абсолютно привязана к конкретному каналу (аналогия с исполнением командных bat-файлов, когда расположение файла может быть указано с полным путем или относительно текущей директории). Фактически в пятой версии на одинаковые имена каналов в разных (хотя и однотипных) объектах наложено табу: интерфейсы DDE и ODBC просто не смогут эти каналы различать! Когда-то очень давно я использовал SCADA Sitex (под QNX), там примерно так все это и было, и это было очень удобно. А еще там был такой интересный поход: объект базы каналов сам является каналом особого типа, и одним из его параметров является адрес устройства, к которому он подключен (в Вашем случае это часть удаленного адреса (ADDR), на которую действует групповая правка). Поля атрибутов канала-объекта (аналогия с атрибутами директории), таким образом, берут на себя часть атрибутов каналов ввода-вывода, во многих случаях отпадает необходимость групповой правки и ручной перепривязки каждого канала. Заодно отпала бы необходимость забивать отдельно базу каналов объекта базы каналов и базу каналов объекта графической библиотеки (каламбур конечно, а что делать). Зачем, например задавать для каждого канала период опроса, если это свойство всего объекта? Или базовый адрес? Кроме того излишне индивидуальные настройки каждого канала повышают вероятность ошибки при заполнении их свойств. В конечном итоге, такая реформа приближает систему к идеологии объектно-ориентированного подхода, от которого никуда не денешься. Особенно все это актуально для нас, интеграторов на базе НЕ PC-контроллеров, ведь через один узел TM должны работать 256 контроллеров, по 256 каналов каждый. Нам не хватает прозрачной структуризации. В нашем случае один объект – это один контроллер. Очень логично при этом разделять свойства контроллера (т.е. связанного с ним объекта) и свойства его каналов. Конечно, если используются PC-совместимые контроллеры с микроТМ на борту – проблемы такой не стоит, так как для контроллера в этом случае выделяется отдельный узел, свойства узла становятся свойствами контроллера – это удобно. А что же делать нам, не совместимым? Сейчас, даже с учетом групповой правки, многие операции очень трудоемки, причем неоправданно трудоемки, иногда язык не поворачивается назвать это интеллектуальным трудом (про изменение периода опроса уже писали на форуме). Никаким автопостроением эти проблемы не решаются, ведь проекты надо не только создавать, но и корректировать, причем оперативно. Я не случайно повел аналогию с файловой системой UNIX (вообще то я работал с QNX, но разница небольшая). Кроме каналов должны быть и ссылки на каналы. Что это означает? Сейчас существует возможность создания объекта РБК, собирающего в себя каналы по некоторому признаку, при этом не создается новых каналов. Но если переименовать этот объект и забыть о его свойствах, о которых визуально ничего не напоминает, то непонятно: это разные каналы в разных объектах одинаково называются, или это одни и те же каналы объединены по разным критериям. Вот тут то и помогает понятие ссылки на канал. Т.е. база каналов имеет прозрачную древовидную структуру (типа файловой системы), но существует возможность альтернативной группировки каналов с помощью ссылок на них. Разумеется, при одном взгляде на ссылку должно быть хорошо видно, что это ссылка, а не канал. Как следствие, в одном объекте не должно содержаться и канала и ссылки на него, и тем более, не должно быть двух каналов с одним именем в одном объекте (что сейчас почему-то допускается). Для более прозрачной структуризации проекта можно устроить два типа группировки каналов в объекты: по физическому подключению и по логической привязке. Тогда объекты, содержащие ссылки на каналы из других объектов, можно назвать, например группами. В этом случае группами, очевидно, окажутся все системные объекты – рассылки, дискретный ввод, M-LINK и прочие создаваемые по умолчанию. А объектом будем называть объединение каналов по признаку подключения к одному шкафу, котроллеру, плате… Физическое подключение каналов, как правило, прозрачно соотносится с топологией объекта автоматизации, поэтому объекту можно сразу сопоставить и некий набор графики, но это уже совсем другая история. Кстати прошу прощения за лирическое отступление, но Вы только представьте себе как удобно было бы работать с каналами, если бы для этого существовал канал-менеджер, аналогичный нортонообразному файл-менеджеру. Это же был бы 100% интуитивно-понятный интерфейс. (РБК сейчас больше похож на «проводник» в режиме больших значков). F7 – создал объект, F6 – перенес в него канал, F3 – посмотрел свойства, F4 – отредактировал их же, F8 – удалил его [в корзину]. А если надо – то выделил не один канал а несколько и сделал групповую операцию. А можно выделить не только канал, но и вложенный объект – копируй на здоровье. (И курсов даже не надо устраивать.) С помощью этой аналогии я собираюсь подвести Вас к следующей мысли: если канал содержится в объекте А, а объект А – в объекте Б, то не должен этот канал содержаться в объекте Б. Этот недостаток особенно заметен при работе с РПД: куча каналов, куча объектов. Две большие кучи вместо привычной древовидной структуры! Вместо простого дерева! Выбор канала в узле должен походить на выбор файла на диске, это будет очень удобно. Причем, если у меня выбран канал с именем 1 в объекте А и мне хочется выбрать канал 1 (т.е. другой канал с тем же именем) из объекта Б, то переходя по дереву из А в Б, я должен автоматически выбрать именно его, канал 1 из объекта Б, а не канал 0 или 2 на том основании, что у него меньше ID, на который мне вообще смотреть не хочется. Ведь не нужно же знать пользователю расположение файла в таблице FAT, чтобы с ним работать.
И в заключении еще одна ценная мысль. Очень нечасто бывают нужны те скоростные качества архивации и пересчета, которые Вы успешно (хотя я не проверял) демонстрируете. Зато очень часто не хватает простоты (не в смысле программистского минимализма, а наоборот) и удобства разработки. Системный интегратор не может постоянно находится рядом с пользователем, а у пользователя голова о другом болит постоянно, редко вообще на местах выделяется специалист для работы с Trace Mode. Современное развитие железа позволяет уже меньше заботится об оптимизации вычислений. Нужно жертвовать производительностью ради удобства. Пускай архив будет занимать больше места, необязательно ему быть в одном файле (хоть 1000), сделайте дополнительный файл – таблицу соответствия полных имен каналов (NODE:\OBJECT1\…\OBJECTn\channel1) и их индексов в архиве, ничего, что она будет меняться в процессе разработки проекта (можно динамические подстановки индексов организовать), зато ничего не потеряется и все удобно извлечется по ODBC. Опять же удаленный адрес из 6 байт – это очень компактно, но маловато, особенно, если вспомнить, что пользователю для адресации устройства и канала в нем остается реально всего 4 байта (одно 2-байтовое поле и два по байту, либо 4 по одному байту) – это тесновато. Восстановление текущих значений из файла – хорошая штука, но как же она глючит! Это что-то с чем-то, как мы с ним намучались. Малейшее изменение в проекте – файл надо стирать, причем вручную. Не понимаю, почему нельзя проверять каждое значение на корректность, почему отказываться надо от всего файла из-за одного несоответсвия. И почему сохранять текущие значения надо обязательно для всех каналов? Должна быть такая же опция, как в случае с архивом. Я бы даже голосование устроил: кто за утяжеление файлов в пользу надежности и удобства разработки, можно прямо на форуме, у меня будет много сторонников. Можно также устроить два варианта исполнения проекта (они фактически уже есть – профайлер и МРВ, но отличаются мало, только ведением лога) – «тяжелый», запускаемый из РПД, и «легкий» - с откомпилированными индексами каналов. Т.е. пока идет разработка пускай каналы адресуются по полным именам (NODE:\OBJECT1\…\OBJECTn\channel1) и все работает медленно, а когда пора работать с реальным объектом – компилируем имена в индексы и все работает быстро. Кому надо постоянно корректировать проект – пусть все время работает в «тяжелом» варианте, купит поновее ПЭВМ и памяти побольше. Спасибо, что дочитали до конца, можете что-нибудь ответить на atmoscow@online.ru .
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Уважаемый Fedor V. Gluhov!
Это очень важные проблемы. Они, конечно, заслуживают дискуссии. И она, видимо, будет.
Со своей стороны, я должен обратить Ваше внимание на 2 момента, которые, по-моему, не вполне корректно сформулированы. Да и попали они не по теме.
1. "Опять же удаленный адрес из 6 байт – это очень компактно, но маловато, особенно, если вспомнить, что пользователю для адресации устройства и канала в нем остается реально всего 4 байта (одно 2-байтовое поле и два по байту, либо 4 по одному байту) – это тесновато."
Конечно, чем больше возможностей для настройки пользовательских функций, тем лучше. Кто бы спорил.
Но из 6 байтов для каналов КОНТР_1 только 1-й байт занят номером COM-порта, остальные - в Вашем распоряжении. Еще 1 байт, видимо, использован для организации групповых запросов, но ведь это тоже пользовательский ресурс.
1 байт на адресацию устройств - это 255. Маловероятно, что на одной физической линии будет большее количество устройств.
2 байта - на адрес переменной - это 65537. Вряд ли в каком-либо контроллере имеется больше переменных одного типа. А для задания типа можно использовать оставшийся 1 байт.
2. "Восстановление текущих значений из файла – хорошая штука, но ... почему отказываться надо от всего файла из-за одного несоответсвия. И почему сохранять текущие значения надо обязательно для всех каналов?"
Да ведь такая опция есть. Существует стандартный объект БЕЗ ВОССТАНОВЛЕНИЯ, в который следует поместить все каналы, значения которых не должны восстанавливаться при загрузке узла.
Для микроМРВ введена подобная опция - запрет восстановления значения канала из файла сохранения состояния системы осуществляется установкой флажка СПАД.
И отказываться от всего файла из-за возникших после редактирования несоответствий не надо. Надо в окне ОБЪЕКТОВ соответствующего узла нажать на клавиши Ctrl+R и сохраненные в файле значения будут приняты в качестве начальных значений в текущей базе каналов. Теперь старый файл не нужен. Можно его удалить, или отказаться на первом запуске от "подчитывания".
Posted by zem21 (Участник № / Member № 418) on :
Согласен, что 6 байт для IA мало. Для базового адреса и номера канала достаточно. А вектор прерывания, номер канала DMA, прочие настройки, да мало ли чего умеют современные устройства? Кстати, для каналов дискретного ввода/вывода два последних байта произвольно использовать нельзя. Хотя для некоторых случаев и 6 байт много. Считаю, что диалоговое окно настройки параметров должно находиться в драйвере устройства (с учетом моего предложения об открытой архитектуре драйверов), который будет упаковывать их в некий буфер и сообщать Трейс Моуд его размер. Согласен с необходимостью разделить свойства устройства и свойства канала (с учетом иерархической структуры проекта).
![[Улыбка / Smile]](smile.gif)
в режиме больших значков). F7 – создал объект, F6 – перенес в него канал, F3 – посмотрел свойства, F4 – отредактировал их же, F8 – удалил его [в корзину]. А если надо – то выделил не один канал а несколько и сделал групповую операцию. А можно выделить не только канал, но и вложенный объект – копируй на здоровье. (И курсов даже не надо устраивать.)