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

СЦБИСТ - железнодорожный форум, блоги, фотогалерея, социальная сеть (https://scbist.com/)
-   ЦШ ОАО "РЖД" - обратная связь (https://scbist.com/csh-oao-rzhd-obratnaya-svyaz/)
-   -   От ЭЦМ КБЦШ - к перспективной МПЦ (https://scbist.com/csh-oao-rzhd-obratnaya-svyaz/48181-ot-ecm-kbcsh-k-perspektivnoi-mpc.html)

Вы просматриваете версию для печати. Если вы хотите увидеть статью полностью - перейдите по ссылке

Просто инженер АиТ 13.03.2017 14:42

На самом деле процессный подход используется и применяется в ЖАТ. Например, процесс формирования кода, конденсаторный дешифратор, производит нечто иное как дешифрирование импульсной работы процесса.
Пусть в схеме есть реле. Тогда в процессной модели будет описано два его состояния:
1 реле выключено - нет процесса связанного с этим реле,
2 реле включено - есть процесс характерный только для данного реле, этот процесс по функциональной логике связывается с другими процессами (если они порождены) в результате чего (по старой идеологии может включится/выключится реле) может породится следующий процесс/выключится уже существующий.

Просто инженер АиТ добавил 13.03.2017 в 14:42
Цитата:

Сообщение от tiksi (Сообщение 312451)
Не о нейронных сетях молвите?

Да, очень похоже на них! Но, нейронные сети требуют обучения, а здесь всё более жёстко связано!

Deutsch 13.03.2017 16:10

Цитата:

Сообщение от Просто инженер АиТ (Сообщение 312425)
Что-то я почитал про МПЦ и как понял полностью от реле не могут отказаться, т.е. нет управления напольными устройства без применения реле!?

А что читали? Киньте в меня "ссылкой".

CHUK 13.03.2017 16:15

Цитата:

Сообщение от Просто инженер АиТ (Сообщение 312452)
Да, очень похоже на них! Но, нейронные сети требуют обучения, а здесь всё более жёстко связано!

Любые новые устройства требуют обучения (только разного по времени), у нас как обычно, как-нибудь запустить, как-нибудь принять, после как-нибудь работать, только спрашивать за работу по полной программе.

Просто инженер АиТ 13.03.2017 17:14

Цитата:

Сообщение от Deutsch (Сообщение 312470)
А что читали? Киньте в меня "ссылкой".

То, что на форуме советовали.
1 "Микропроцессорные системы централизации", Вл.В. Сапожников, В.А. Кононов, С.А. Куренков
А.А. Лыков, О.А. Наседкин, А.Б. Никитин
А.А. Прокофьев, М.С. Трясов. 2006 г.
2 МПЦ EBilock-950 2008 г.

Просто инженер АиТ добавил 13.03.2017 в 17:14
Процессное построение отличается от обычной функциональной логики своей динамикой.
Например. Y =(( X1 | X2 ) & X3) ^~X4 - Это условие срабатывания реле Y, где X - пусть будут контакты или статичные сигналы. В процессном подходе X - это динамические процессы, которые для Y связаны формулой. Например,
X1 - циклический код 01110001010100 (Динамическая Функция Кода)
X2 - циклический код 01110101010111 (ДФК)
X3 - циклический код 11110101110100 (ДФК)
X4 - циклический код 00010111110100 (ДФК)
То Y - также будет циклическим кодом связанной формулой Y =(( X1 | X2 ) & X3) ^~X4 для каждого такта.

Скиталец 13.03.2017 17:16

Цитата:

Сообщение от CHUK (Сообщение 312471)
Любые новые устройства требуют обучения

Речь-то не про обслуживающий их персонал идет.:oiE:

Deutsch 13.03.2017 18:18

Цитата:

То, что на форуме советовали.
1 "Микропроцессорные системы централизации", Вл.В. Сапожников, В.А. Кононов, С.А. Куренков
А.А. Лыков, О.А. Наседкин, А.Б. Никитин
А.А. Прокофьев, М.С. Трясов. 2006 г.
2 МПЦ EBilock-950 2008 г.
А ничего, что на дворе 2017 год?

17845 13.03.2017 18:32

Цитата:

Сообщение от tiksi (Сообщение 312451)
Не о нейронных сетях молвите?


Обныкновенное самоедство. Нет ясных ориентиров -что и как из себя должно представлять и работать. РЖД перестало быть единым организмом. Профильные НИИ ждут бабла, чтобы выдать очередное мозголомство, в департаментах ждут чего скажут "сверху ". Всем хорошо и все при зряплате.

"Настоящих буйных мало- вот ...."
Сплошные онанотехнологии. Практическая работа перешла в стадию соплежуйства. Не у всех, конечно. Но тем, кто пытается реально что- то дельное доказать, или тем более сделать......
Поэтому со стороны это выглядит как растерянность и имитация деятельности. (ИМХО).
Так что мож это и с нейронами связано, но сдается , джентльмены, что это даже и не комедия.

tyubik 13.03.2017 20:17

Пока что интуитивно сдул пыль с "Комбинаторики и теории графов". Идея отказа от ЦП ... . Что-то есть в этом элегантное ;)

Николай Николаевич 13.03.2017 21:55

Цитата:

Сообщение от tyubik (Сообщение 312495)
Идея отказа от ЦП ... . Что-то есть в этом элегантное ;)

А мне не дает покоя идея "удаленного" расположения ЦП и его интеграции в вычислительные мощности ВЦ...

Монти Холл 13.03.2017 23:02

Цитата:

Сообщение от Николай Николаевич (Сообщение 312497)
А мне не дает покоя идея "удаленного" расположения ЦП и его интеграции в вычислительные мощности ВЦ...

А чё, в "колбасном ряду" МПЦшки закончились?
Так еще компьютерный отдел в супермаркете есть ... там не спрашивали?

17845 13.03.2017 23:28

Цитата:

Сообщение от Николай Николаевич (Сообщение 312497)
А мне не дает покоя идея "удаленного" расположения ЦП и его интеграции в вычислительные мощности ВЦ...

Элементарно.
Для ускорения передачи информации с переферии надо её на сверхпроводящих триогенных куатронах зафигачить. Трафик и скорость обработки неограничены . Правда проблемы с жидким гелием, но зато ни у кого ещё нет- а в РЖД будет.

Superhero 13.03.2017 23:35

Навскидку.

Хочется сказать что при структуре 1 ЦП на 1РЖД или даже 1 ЦП на 1 дорогу неизбежно потребуется использование многоуровневой сети. Обилие коммутаторов разного уровня вызовет хаос в ЦП при попытке пообщаться с удаленными контроллерами объектов. Потому что:
- ПО должно циклическим с циклом не более 2 секунд (это супермаксимум);
- общение с удаленными контроллерами тоже должно быть циклическим, о спорадической передаче информации нужно забыть. ЦП должен всегда понимать, кто из контроллеров в каком состоянии находится. Спорадический способ это не обеспечит. Соответственно вся эта армада контроллеров будет постоянно требовать общения с ЦП, причем один раз за цикл опроса (за те самые 2 секунды). Да и передавать надо будет не 2 байта, а с учетом избыточности поболее раз в десять. Попробуй-ка уложись с каждым контроллером в строго отведенный для общения таймфрейм, если вся инфа туда-сюда должна пройти через 3-4 коммутатора, а структура сети - звезда. Херушки, не выйдет. Либо нужно снижать скорость и тогда забыть о миллиардах объектов, либо увеличивать цикл опроса, что недопустимо;
- а ПО ЦП кроме задач общения с контроллерами должно также обсчитывать алгоритмы ЭЦ и АБ, обеспечивать взаимодействие со своими парами или тройками (для безопасности), со своими дублерами (для резерва), выдавать информацию смежникам (в какое-нибудь АСУТП). Плюс самодиагностика, плюс архивирование, да по мелочи набежит задач вагон.

Собирая в кучу вышесказанное, вангую, что пару тысяч объектов при линейной структуре сети - предел для этой утопии.

Ну и самое главное, чего я не увидел в этой ветке - движки не простят, если вдруг по всей сети разрешающие показания сменятся на запрещающие, а сбои в ПО никто не отменял, тем более в таком сложном и при 24/7. А если не дай бог железо накрылось, то совсем нехорошо будет. Даже если это будет обыкновенный коммутатор второго уровня, он положит жд ветку напрочь. Потому что как ни резервируй каналообразующую, все равно теоретически в ней возможно накопление отказов. Канал должен всегда быть нагружен чем-то, иначе будет неясно, жив ли он. Это решаемая задача, но опять же требует ресурсов.

Эта тема перспективна на малодеятельных участках, тут я двумя руками за. А на сети дорог надо все-таки быть немного реалистом. Или много.

ПС Это то, что пришло в голову навскидку. Наверняка подводных камней здесь еще немеряно и каждый из них надгробный для идеи.

Просто инженер АиТ 14.03.2017 09:44

Пока особо идей я не вижу! Но критика уже есть - это очень Хорошо!!! Вы критикуете - я думаю и поправляюсь, исправлю те места, где Вы обнаружили дырки!
Теперь продолжим по существу! Общая идеология построения ЭЦ показана на примере релейных систем! Наша задача уйти от реле (не только на уровне наборной группы, но самое важное сделать Исполнительную группу электронной, бесконтактной), но выдержать общую идеологию построения ЭЦ!
Как я выше излагал, мы должны создать ключевой элемент на основе бесконтактных элементов (устройств), который выполнял бы функции нам родного Реле, тогда можно будет воспользоваться идеологией ЭЦ на реле (в частности меня привлекает БМРЦ).
При этом я предлагаю отказаться от статического представления ключевого элемента типа Реле, а перейти к понятию Реле с точки зрения Процесса, т.е. необходимо создать нечто с функцией реле, но только в виде Динамичного Процесса!
В чем весь сыр бор с бесконтактными устройствами - это симметричность (равно вероятность) их отказа, чем не страдает устройство типа Реле 1 класса надёжности (при любом виде отказа Реле переходит в строго установленное состояние).
Так вот именно динамика и даёт возможность сделать такую схемотехнику, которая сделает Процесс (а не статическое состояние на каком-то выходе) типа Реле несимметричным (что-то напоминающего езду на велосипеде, пока педали крутишь, то не падаешь!).
Вы посмотрите, практически в всё в нашем мире тактируется, живет в циклах (Зима, Весна, Лето, Осень).
Так что же будет соответствовать состоянию Реле Включено! - Состояние Процесса, который формирует определенный циклический код! Состоянию реле Выключено - отсутствие этого кода. Соответственно схемотехника управления реле, должна понимать не статическое состояние функциональных элементов включенных по определённой функции, а состояние Процессов этих функциональных элементов.
Ну пока хватить! Это надо ещё переварить!

Николай Николаевич 14.03.2017 09:47

Цитата:

Сообщение от Superhero (Сообщение 312504)
Навскидку.

Хочется сказать что при структуре 1 ЦП на 1РЖД или даже 1 ЦП на 1 дорогу неизбежно потребуется использование многоуровневой сети. Обилие коммутаторов разного уровня вызовет хаос в ЦП при попытке пообщаться с удаленными контроллерами объектов. Потому что:
- ПО должно циклическим с циклом не более 2 секунд (это супермаксимум);
- общение с удаленными контроллерами тоже должно быть циклическим, о спорадической передаче информации нужно забыть. ЦП должен всегда понимать, кто из контроллеров в каком состоянии находится. Спорадический способ это не обеспечит. Соответственно вся эта армада контроллеров будет постоянно требовать общения с ЦП, причем один раз за цикл опроса (за те самые 2 секунды). Да и передавать надо будет не 2 байта, а с учетом избыточности поболее раз в десять. Попробуй-ка уложись с каждым контроллером в строго отведенный для общения таймфрейм, если вся инфа туда-сюда должна пройти через 3-4 коммутатора, а структура сети - звезда. Херушки, не выйдет. Либо нужно снижать скорость и тогда забыть о миллиардах объектов, либо увеличивать цикл опроса, что недопустимо;
- а ПО ЦП кроме задач общения с контроллерами должно также обсчитывать алгоритмы ЭЦ и АБ, обеспечивать взаимодействие со своими парами или тройками (для безопасности), со своими дублерами (для резерва), выдавать информацию смежникам (в какое-нибудь АСУТП). Плюс самодиагностика, плюс архивирование, да по мелочи набежит задач вагон.

Собирая в кучу вышесказанное, вангую, что пару тысяч объектов при линейной структуре сети - предел для этой утопии.

Ну и самое главное, чего я не увидел в этой ветке - движки не простят, если вдруг по всей сети разрешающие показания сменятся на запрещающие, а сбои в ПО никто не отменял, тем более в таком сложном и при 24/7. А если не дай бог железо накрылось, то совсем нехорошо будет. Даже если это будет обыкновенный коммутатор второго уровня, он положит жд ветку напрочь. Потому что как ни резервируй каналообразующую, все равно теоретически в ней возможно накопление отказов. Канал должен всегда быть нагружен чем-то, иначе будет неясно, жив ли он. Это решаемая задача, но опять же требует ресурсов.

Эта тема перспективна на малодеятельных участках, тут я двумя руками за. А на сети дорог надо все-таки быть немного реалистом. Или много.

ПС Это то, что пришло в голову навскидку. Наверняка подводных камней здесь еще немеряно и каждый из них надгробный для идеи.

Спасибо за высказанное мнение!
Будем надеяться, что это конструктивный разговор!
"Один ЦП на все" - это крайний случай, чисто теоретический разговор, как раз для того, чтобы увидеть и понять "края".
Если чуть-чуть приблизиться к реальности: одна дорога - это примерно 10000 стрелок или около 50000 объектов управления и контроля. И на дороге - оценочно - 10 ШЧ. Ставим на каждую ШЧ отдельный ЦП (один или несколько рядом стоящих конструктивов). Но все ЦП всех ШЧ дороги - в одном зале ВЦ. Делаем оптимальные сети связи - максимально персонифицированные для каждой ШЧ. Не поднимаем на этот уровень диагностическую информацию о состоянии объектов - ту, которая не требуется ЦП для выполнения своих функций - пусть с ней работают специалисты ШЧ.
Стало ли в таком случае меньше надгробных камней и не появились ли новые?

Монти Холл 14.03.2017 09:50

Цитата:

Сообщение от Просто инженер АиТ (Сообщение 312511)

Теперь продолжим по существу!....

И тут Остапа понесло!


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

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


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