Практика разработки нескольких проектов однозначно остановила меня на выводе, что «целевое» понимание формируется вне индивидуальности и может быть сформировано в коллективе на основе осознании цели и способов её достижения и, соответственно, на основе декларации определений. Т.е. сначала надо определиться и ответить на вопросы:
1. Для чего мы это делаем
2. Как мы это пытаемся сделать
3. Что входит в словарь проекта
Для примера приведу термин «AppLib». Кому и что он говорит? Никому и ничего. Т.к. это внутренний термин проекта, для моих разработчиков определяющий ядро исполнительной системы, имеющий универсальный шлюз на прикладной уровень разработки. Понятно, что если один человек говорит на таком птичьем языке, а второй – пытается понять, то без «перевода» диалог будет просто бессмысленным…
«… Законы надо не пробовать, а изучать….»
Изучать можно до бесконечности… Не знаю – почему я привязался к авиации, но её история – сплошная цепь проб, удачных и неудачных, иногда трагических. Думается, что, если бы только изучали законы, то мы не имели в этой области такого уровня развития…
«…Какая должна быть цель?...»
Цель – очень амбициозная… Создать стандарт(!) на построение таких систем, не зависящий от корпоративных решений типа ОРС, Siemens, Microsoft etc. Их можно и нужно, на настоящий момент, использовать, но «смотреть в рот» и слепо идти за, зачастую, очень непродуманными решениями – дорога в никуда. Имхо. Сейчас очень хороший период, кода недорогие, надёжные решения могут отодвинуть построенную на откатах систему, взамен дав прозрачность и открытость решений. Идеализм? – Да! Но без подобного идеализма мы все погрязнем в болоте. Опять-таки ИМХО.
«…Я когда-то пытался разбираться с OPC-сервером и ничего такого, что могло бы облегчить решение задач, которые требовались заказчику, я не обнаружил…»
Как только произносится слово «ОРС», то сразу же вылезает DCOM, и сразу же подразумевается Windows. При этом, ОРС сам ничего не делает, это интерфейс передачи данных. Не более. Для обеспечения сопряжения разнородных (от разных изготовителей) систем. Дойная корова. И найти что-то в нём сверх этого – трудно.
«Также диспетчер имеет возможность посмотреть на мнемосхеме состояние любого объекта и значения аналоговых и дискретных параметров…»
Требования, в том числе стандартные, типа указанных, должны быть реализованы в любой систем. У нас основной вопрос не «Что?», а «Как?»
«…А куда его можно "вставить", и, главное, кто его будет настраивать..»
Тракт локального управления должен использоваться там, где он необходим. Это просто подсистема. Нет управления – «притягивать» его «за уши» в проект смыла нет. А настраивать… Настраивает тот, кто создаёт прикладную систему. Это очевидно.
«…почему мне понравился линукс … Мне в нём понравились очереди сообщений…»
Хороший инструмент, есть правда одно НО, в стандартном ядре (текущего положения дел, увы – не знаю) время нахождения события в очереди не регламентировано… Т.е. оно может находиться там и мСек, а может и Сек., что непозволительно для большинства систем сбора и обработки. В RT-примочках для линукса этот эффект как-то обходят.
Для альтернативы рассмотрим… UDP. Привязав порт к приемнику(источнику), можно данные кидать на любой узел (программу) сети. Правда UDP не в чистом виде, а чуть-чуть дополненный, но совсем чуть-чуть. А если взять SCTP – то вообще сказка получается. Рекомендую ознакомиться с этим новым сетевым протоколом (Stream Control Transport Protocol).
Новая часть.
Рассматривая вопрос о создании ядра, я как раз и исходил из того, что большинство решений обсуждаются не со стороны «как это работает», а со стороны «что это делает». Архивация, визуализация и т.п. рассматривается как цель. У меня нет такой цели. Архивы есть, а цели – нет. Так как цель – сформировать (и реализовать по возможности) набор принципов, реализующих СИСТЕМУ отношений. Сколько копий поломано на выборе ОС для системы? Сколько самопальных программ написано для реализации одних и тех же функций. Тут как раз рождается страшное следствие – из-за разнородности подходов, даже с применением средств разработки от ведущих производителей, разработки живут (во всяком случае на постсоветском пространстве) до тех пор, пока разработчик (почти всегда конкретная персоналия) уделяет ей время. Может, конечно, я ошибаюсь, но моя практика…
Альтернатива. Например. В силу унификации языка сообщений формат архива таков, что он просто протоколирует события (id системы, id параметра, время и т.п.) в БД. В простейшем случае их можно упаковать в обычный текстовый файл БЕЗ ПОТЕРИ ИНФОРМАТИВНОСТИ, а при желании – в любую, наперед заданную, БД. (Зависит от уровня сложности системы). При этом от системы к системе двоичный код архиватора и пр. не изменяется! Т.е. пишется всего одна программа!
Для реализации подобного подхода необходимо на уровне промежуточного контроллера провести первичную обработку сигнала, привести его значение к значению параметра (для составных параметров) и выдать информацию в сеть, где её и заархивируют и визуализируют и ОРСиют
.Вопрос. На моей практике не встречались системы, которые не разбивались бы на подсистемы, с меньшим количеством параметров (собственно туда и просится контроллер первичной системы). Приведённые количественные характеристики – все эти сотни дискретов и тысячи аналоговых параметров – неужели не делятся на привычные для того же оператора объекты?
Типа Цех - компрессорная, агрегат, система охлаждения и т.п.?
В институте я ничего подобного не изучал. Изучать самому принципы создания, когда не понятно, к чему (и когда) это можно будет применить -- задача, в общем, бессмысленная. А когда мы начали создавать диспетчерскую систему, я понял, что основное, что нужно диспетчерам -- это иметь возможность в любой момент узнать текущее значение любого сигнала, посмотреть, как менялись значения сигналов, какие были переключения и иметь возможность управлять сигналами. Ещё должна быть возможность ручного ввода значений сигналов на случай, если их значения передаются, например, по телефону голосом (если нет аппаратуры измерения этих значений).
