Николай Николаевич

Кроме "собственно МПЦ" - аналога совокупности релейных стативов - еще неизбежно нужно иметь:
- АРМ ДСП - аналог пульт-табло;
- линейный статив ДЦ - отдельный или интегрированный;
- средства внутренней диагностики;
- средства внешней диагностики элементов периферии;
- питающую панель.
Ну и "где-то еще" - комплект объектных контроллеров той или иной функциональности.
Вроде - все...

Игорь Данилин

В рассуждениях появился термин объект, т.е. некая сущность, которая занимает память. Соответственно, кто-то эту память:
- должен найти;
- сделать так, чтобы туда никто случайно ничего не записал;
- дать прочитать оттуда только тому, кому можно;
- при уничтожении объекта эту память освободить.
Так что, операционная система нужна, да еще как.

Николай Николаевич

Почему "появился" - объект был всегда, и это объект управления и контроля: стрелка, светофор, изолированный участок и др.
В части "занимает память" - память занимает информация о состоянии объекта.
А еще - память должна занимать таблица разрешенных состояний объектов и их совокупности, то, что в СЦБ называется "взаимозависимостями".

Просто инженер АиТ

Всё Вы интересно говорите и рассуждаите, но пока у Вас нет архитектуры как железа от мышки до последнего транзистора включающего лампу светофора в ОК, от загрузки ПО до последнего объекта или бита в сообщении в ОК ничего не получится.
Как я вижу Вы строите не МПЦ, а центр управления станциями и устройствами съёма информации и управления
объектами на станции. У Вас всё перемешалось.
Вы хотите сделать супер голову и тупые органы: чувств и управления со сверх надёжными каналами передачи информации и питанием управляющих органов.
Моё тревожное мнение, что получится медленно действующий монстр. Это моё мнение и я не кому его не навязываю.
P.S. Больше рисуйте, кодировать могут многие!

Просто инженер АиТ добавил 16.12.2017 в 23:45
В реальности, в ПО всё намного сложнее.
И тогда появился "Объект", и было у него "Имя", а также "Конструктор" и "Деструктор" и ещё ряд абстрактных методов "Установить состояние" и "Получить состояние"...

__________________
Не важна реальность, важно как мы к ней относимся!

Игорь Данилин

Просто инженер АиТ,
Я не занимаюсь проектированием ЭЦ ни в какой части. Просто читаю эту ветку форума, что называется, для общего развития. Встретив рассуждения о том, что ОС не нужна, решил "поправить". Вопросы связанные с организацией доступа к физической памяти - одни из главных у ОС.

Просто инженер АиТ

Полностью согласен.
Есть мысль как должно выглядеть ПО именно МПЦ ("Исполнительная" часть)(всё может быть простым до безобразия), без АРМов управления ("Наборная группа" с предварительным анализом зависимостей ЭЦ), АРМы это другая часть, не менее важная!

__________________
Не важна реальность, важно как мы к ней относимся!

АЛСНщик

Какие именно АРМы имеются в виду? АРМ оператора (ДСП, ДНЦ), АРМ администратора (ШЧшника, который "шарит"), или АРМ дежурного персонала (диспетчера ШЧ) ?

__________________
Я по роду-племени тутошний, а вот по образованию - я тамошний

Просто инженер АиТ

АРМ оператора (ДСП, ДНЦ) - только эти АРМы являются управляющими! Остальные АРМы не могут управлять устройствами ЭЦ.

__________________
Не важна реальность, важно как мы к ней относимся!

АЛСНщик

Спасибо! Но теперь возникли новые вопросы.
АРМы разных пользователей могут быть абсолютно идентичными, а права пользователей (движенцев, ШЧшников) привязываться только к логину и паролю при входе в комп АРМ? Или в АРМах могут и должны быть различия по "железу" и софту?
Точка подключения АРМа к МПЦ - это прежде всего IP адрес точки, или для отдельных АРМов (в аппаратной ДСП, в "релейке") возможно физическое подключение, например по RS-232 ?
АРМы являются частью МПЦ, пусть даже имеют иное ПО (на основе той же Винды) или АРМ изначально рассматривается как иное устройство, в состав МПЦ не входящее, но эту самую МПЦ мониторящее и, в отдельных случаях, управляющее МПЦ.

__________________
Я по роду-племени тутошний, а вот по образованию - я тамошний

Просто инженер АиТ

Как я вижу систему управления станциями (станцией). Система должна быть многоуровневой:
- нижний уровень - Объектные Контроллеры,
- уровень МПЦ, обрабатывает информацию от ОК и реализует команды управления устройствами централизации, через ОК,
- средний уровень - сервер, взаимодействует с МПЦ, позволяет подключить Клиентов, различные АРМы, контролирует доступ разрешенным Клиентам, определяет информационные потоки Клиентов,
- верхний уровень Клиентов - АРМов.

__________________
Не важна реальность, важно как мы к ней относимся!

АЛСНщик

Как я понял, устройство, управляющее всей сетью МПЦ на верхнем уровне - это аналог IP АТС для IP телефонии. Т.е. некая "жалязяка", которая может быть где угодно в локальной вычислительной сети и подключается к сети обычным образом через "точку" с IP адресом. По идее, самой "жалезяки" может и вовсе не быть - достаточно специальной программы на сервере (с IP телефонией такое тоже "прокатывает", но в профессиональных сетях связи IP АТС всё же "железная", а не виртуальная).
Единственная задача управляющего устройства - в нём хранятся алгоритмы, в соответствии с которыми работает вся периферия. Можно даже спроектировать систему с несколькими управляющими устройствами по принципу Master и Slave. В нормальном режиме работы "рабы" всего лишь сверяют свою конфигурацию с мастером (которая признаётся единственно верной), а если мастер выходит из строя или пропадает с ним связь, его место в управлении МПЦ занимает Slave. Данные устройства, в принципе, можно раскидать по разным уголкам страны, например разместить в ВЦ различных дорог.

__________________
Я по роду-племени тутошний, а вот по образованию - я тамошний

Просто инженер АиТ

Думаю здесь всё может быть проще, достаточно сформировать команду на управление и отправить её, естественно хорошо было бы проверить возможность реализации команды на основе данных состояния устройств, чтобы не посылать команду явно не выполнимую по условиям безопасности движения.
Реализовать команду будет МПЦ, а здесь обязательная проверка всех условий безопасности.

__________________
Не важна реальность, важно как мы к ней относимся!

Абрамов..ИЧ

Хм.. ну вообще ШН тоже вполне себе "оператор" АРМ (ШН), т.к. он является его пользователем.

Николай Николаевич

Не соглашусь!
Оператор он же пользователь у МПЦ - один-единственный, и он называется ДСП. Его инструмент - соответственно АРМ ДСП.
Все остальное - вторично!
МПЦ должна "делать репликацию" поездного положения в "квазиреальном времени" в ДЦ, в РБЦ, в МАЛС, в систему оповещения пассажиров, в систему оповещения работающих на путях, и т.д., и т.п., и в том числе - в "АРМ ШН", в "АРМ мониторинга" и др. Но эти АРМы - я их не зря взял в кавычки - всего лишь возможность "гонять архив поездного положения туда-сюда в разном масштабе времени", не более...

Абрамов..ИЧ

ШН может получать из АРМ ШН то, к чему нет доступа у ДСП, например к диагностической информации.
По отношению к системе - и ДСП, и ШН являются её пользователями, каждый из которых работает в соответствии с отведенными правами.
Более того, доступ ДСП к АРМ назначает ШН (в рамках УПРАВЛЕНИЯ паролями). В каком-то смысле в правах он даже выше ДСП, можно сказать администратор.