СЦБИСТ - железнодорожный форум, блоги, фотогалерея, социальная сеть

СЦБИСТ - железнодорожный форум, блоги, фотогалерея, социальная сеть (https://scbist.com/)
-   Сетунь (https://scbist.com/setun/)
-   -   Переход на ОС с открытыми кодами (Linux) (https://scbist.com/setun/47972-perehod-na-os-s-otkrytymi-kodami-linux.html)

Николай Николаевич 16.12.2017 14:11

Цитата:

Сообщение от m911ex (Сообщение 333120)
Для релейки с приблудами придумали название, название её РПЦ. Давайте совместно придумаем название для МПЦ с приблудами. Взгляните на СЦБ с точки зрения разделения процессов зависимостей, архивирования и диагностики, забыв, что что-то и как-то решалось в релейках. Все яйца в одной корзине не хранят. Либо она должна быть сверхнадежной и, следовательно, очень дорогой.

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

Игорь Данилин 16.12.2017 14:41

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

Николай Николаевич 16.12.2017 14:49

Цитата:

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

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

Просто инженер АиТ 16.12.2017 22:45

Цитата:

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

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

Просто инженер АиТ добавил 16.12.2017 в 23:45
Цитата:

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

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

Игорь Данилин 18.12.2017 09:38

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

Просто инженер АиТ 18.12.2017 10:16

Цитата:

Сообщение от m911ex (Сообщение 333102)
Чтобы создать совершенную мпц необходимо перестать мыслить категориями релейных систем.

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

АЛСНщик 18.12.2017 10:58

Цитата:

Сообщение от Просто инженер АиТ (Сообщение 333240)
без АРМов управления ("Наборная группа" с предварительным анализом зависимостей ЭЦ), АРМы это другая часть, не менее важная!

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

Просто инженер АиТ 18.12.2017 11:21

Цитата:

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

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

АЛСНщик 18.12.2017 11:47

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

Просто инженер АиТ 18.12.2017 12:15

Цитата:

Сообщение от АЛСНщик (Сообщение 333251)
АРМы являются частью МПЦ, пусть даже имеют иное ПО (на основе той же Винды) или АРМ изначально рассматривается как иное устройство, в состав МПЦ не входящее, но эту самую МПЦ мониторящее и, в отдельных случаях, управляющее МПЦ.

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

АЛСНщик 18.12.2017 12:26

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

Просто инженер АиТ 18.12.2017 12:35

Цитата:

Сообщение от АЛСНщик (Сообщение 333255)
Единственная задача управляющего устройства - в нём хранятся алгоритмы, в соответствии с которыми работает вся периферия.

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

Абрамов..ИЧ 18.12.2017 12:52

Цитата:

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

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

Николай Николаевич 18.12.2017 13:02

Цитата:

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

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

Абрамов..ИЧ 18.12.2017 13:16

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


Часовой пояс GMT +3, время: 03:08.

Powered by vBulletin® Version 3.8.1
Copyright ©2000 - 2025, Jelsoft Enterprises Ltd. Перевод: zCarot


Яндекс.Метрика