Полностью согласен с Николай Николаевичем! Может быть для начала нарисовать функциональную схему этого комплекса.
Теперь насчёт педалей. Какие бы вы педали не взяли, хоть горочные (ну например, разработки Штанке - эти педали применяются на горках, есть возможность определять направление движения, педали также работают с 0 скоростями - это очень важно при маневровых работах, когда движение может быть реверсивным с остановками) сложность заключается в подтяжке сигнала от этих датчиков (могут теряться импульсы, может не настраиваться датчик (емкость кабеля)), далее не менее важным становится стоимость кабеля и кабельных работ, которые могут во много превышать стоимость датчика, здесь нужна оптимизация.
Т.е. тупо пытаться приспособить какую-либо систему боюсь не получится!
Далее. Номера вагонов вы будите вводить в ручную, с натурного листа, автоматически? Это тоже интересный вопрос, который требует отдельной проработки!
Вообще, мне эта система несколько напоминает работу горки, только без надвига с одними маневровыми передвижениями. Чем-то похожа на ГАЦ-МП, только по проще (не надо тормозить).
На входе ставим измерительный участок со снятием номеров вагонов для составления по осной модели состава. А далее педали на входе каждой стрелки.

Просто инженер АиТ добавил 16.10.2013 в 12:53
Горочные системы сейчас могут отслеживать передвижение вагонов в любом направлении, хоть во время роспуска, хоть при вытяжке чужаков и перестановке их на другие пути маневровыми передвижениями, при этом номера вагонов также меняются в парке накопления.

Комплексная система автоматизации сортировочного процесса (КСАУ СП) – общие сведения


В соответствии с «Программой совершенствования и развития сортировочных станций железных дорог на период до 2015 г.» в «НПП «Югпромавтоматизация» разработана и получает дальнейшее развитие КСАУ СП, структурная схема которой приведена на рисунке 1.15.
В состав КСАУ СП входят следующие средства и подсистемы горочной автоматизации:
» ГАЦ-МП управляет маршрутами отцепов при расформировании составов, контролирует накопление отцепов и маневровых передвижений в зонах горки и парков, осуществляет увязку с АСУ-СС и ГАЛС-Р (по техническим условиям). В ГАЦ-МП автоматизированы рабочие места дежурного и операторов по горке;
....

Подсистема ГАЦ-МП автоматически контролирует показания сигналов постового и напольного оборудования для реализации функций управления маршрутами отцепов и контроля их накопления на подгорочных путях. ГАЦ-МП осуществляет информационную увязку с АСУ СС на терминале дежурных по горке ДСПГ и ДСП. Это дает возможность принимать и корректировать сортировочные листки, запрашивать информацию о состоянии парка приема, передавать в АСУ СС информацию о поступивших на пути сортировочного парка вагонах С помощью функции формирования параметров отцепов на из мерительном участке (номера вагона, количества осей, веса особых признаков груза) и привязки их к программе роспуска можно менять в ходе роспуска маршруты и их специализацию, восстанавливать маршрутные задания в случаях нерасцепов и нагонов на спускной части горки. Благодаря функции автоматизированного управления маршрутами осуществляется управление стрелками согласно программе роспуска сформированной по сортировочному листку с учетом корректирующих действий ДСПГ и/или маневрового диспетчера

Горочный измерительный участок (ИУ) состоит из 4х датчиков счета осей, одного комплекта РТД-С и тензометрического весомера (если говорить о системе КСАУ-СП). Весомер нужен для автоматического торможения и в рассматриваемом проекте, скорее всего, не потребуется. Если делать ИУ, то на двухпутке их потребуется минимум 4 шт. Но опять же, ИУ на горке обеспечивает безопасность движения при автоматическом роспуске, поэтому на обычной станции столько датчиков в одном ИУ может оказаться избыточно.

У нас сейчас на финишной стадий ГАЦ АРС ГТСС, что за система время покажет.

Нет, не согласен с данными тезисами абсолютно.
1. Разработчиков сейчас - плюнуть некуда, только ленивый не лезет на жд со своими предложениями. В нашем конкретном случае разработчиком этой системы будет ЦКЖТ, дабы не плодить геморроя при эксплуатации. Тем более, что наработки метровские по ГИДу есть, за поездами слежка ведется.
2. УВК у всех примерно одинаковый. Отличие только в безопасен/не безопасен. Поэтому правильнее всего начинать работу именно с определения типов напольных устройств, оставив за скобками ССО как запасной вариант.
Определив тип датчиков, определяется и интерфейс к ним (релейный или бесконтактный типа токовой петли или RS-485 в случае активного датчика).
3. Определив тип датчика, можно строить алгоритмическое обеспечение для работы с ними, параллельно разрабатывая алгоритмы обработки информации для построения вагонной модели.
4. Вчера в голове родилась первая версия системы:
- датчики с релейным интерфейсом, ставим два для понимания направления движения;
- последовательность срабатывания реле обрабатывает плата УМВ (небезопасная, 56 входов, т.е. обработает 28 точек установки датчиков). Частота опроса контактов реле высокая;
- информация от УМВ поступает в УВК в виде "1 точка, 3 оси в четном направлении / 2 точка, 4 оси в четном направлении и тп). Цикл опроса 1-2 секунды;
- ну а дальше дело программистов обработать, нарисовать и передать выше.
5. Предлагаемое Н.Н. решение - одно из возможных, на мой взгляд излишне громоздкое и заточенное под ССО. Локальные мозги - вообще излишества для системы, не заточенной под безопасность.
6. Про кабельные сети - верно. Это геморрой еще тот, но он неизбежен.

Забыл упомянуть, что на входе на станцию будет камера, считывающая номера вагонов, далее номера будут распознаны и переданы в ЭЦ-МПК-У или в АРМ ГИД для дальнейшей обработки. Считывать и распознавать будет череповецкая контора, Малленом вроде как.


Александр Михайлович, система будет новая. Возможно кто-то где-то это уже делал, но я знаком с цифрами, которые выкатывают ГТСС и ЮгПА за свои разработки, и поверьте мне, они не внушают никому оптимизма, кроме самих разработчиков и их крыш. Возможно, я подхожу к задаче не совсем по-коммерчески, но еще Брат говорил, что "В чем сила, брат? Ты думаешь, она в деньгах? Нет, сила - она в правде". Да, мы заработаем на этом проекте деньги, но после нас заказчик не останется с вытаращенными от недоумения глазами и с голым задом.

-В чём сила, брат?
-В ньЮтонах!

С большим уважением отношусь к сотрудникам , так как сам ЛИИЖТовец и со многими из них учился или работал на кафедре, также работал с сотрудниками ЮгПА во времена, когда только создавался КГМ-РИИЖТ и сейчас поддерживаю хорошие отношения.
Да, цена определяет многое - это так! Но есть пословица - "Скупой платит дважды или ещё больше раз". За серьёзными разработчиками стоит многолетний опыт, набранный на собственных ошибках, поэтому стоит ещё подумать. Но я опять же рад, что разработчиком будет ЦКЖТ - там ребята очень способные!
Теперь хочу спросить у вас есть "Технические требования" или ТЗ к вашему НЕЧТО (ОСТ32.181-2001)? Дело в том, что это очень важные документы и лучше сейчас потерять время по их составлению, чем потом потерять кучу денег! Чем более будут детализированы различные технические решения, тем легче будет реализация.
- это какой тип датчика? Релейный интерфейс находится в самом датчике? Если да, то тогда смотрим на ЭМС и климатику.
, а какая частота считается в данном случае высокая?
- за такой цикл опроса сколько осей успеет прокатится по датчику при скорости 25 км/ч? Например, цикл опроса датчиков в УВК ГАЦ МП ~10мс.
- не забывайте, есть большая разница считывать и распознавать номера автомобилей и номера вагонов, когда вагон проходит вдоль камеры! Возможно, вам поможет контрольная цифра в номере вагона на определение достоверности распознавания? А может проще брать натурный лист АСУ?, как это делается в ГАЦ МП.

Мысль в корне верна. К сожалению, внятного ничего нету, но без ТЗ естественно никуда. Скорее всего, после осознания и согласования с заказчиком как делать, чем делать и что будет в итоге, будет и написано ТЗ. А по другому не получится, ибо техническую политику определяет заказчик.

Да сами не знаем, что за зверь такой! Есть предположение, что он в природе существует. Реле либо на посту, либо в РШ рядышком. Думаем о применении реле не 1 класса.

Лично мне кажется, что опрашивать состояния контактов реле достаточно с частотой 100 Гц. Этим можно достоверно определить и отсеять дребезг контактов. повторюсь, что скорости предполагаются небольшие. Сейчас УМВ работает примерно с такой же частотой, по-моему чуть с большей.

Хоть десять пусть прокатится. УМВ отдаст в УВК информацию о количестве и направлении осей, а не о факте проследования оси.

Да, это понятно. И заявленная ими 99% точность распознавания - величина меня не очень устраивающая, но по телефону было сказано, что для повышения достоверности можно поставить еще счетных пунктов и сравнивать полученные результаты. В конце-концов эта аппаратура будет стоять только на входе и при возникновении коллизии ДСП пошлет кого-нибудь посмотреть номер вживую или запросит соседнюю станцию. В любом случае иного нету, все заявляют пресловутые 99%, не понимая, что это один вагон из ста, т.е. один случай нераспознавания на два принятых состава. Это много.

- не совсем верно, по интервалам между срабатываниями датчика определяется прохождение вагона и его осность! Иначе вы не можете контролировать прохождение вагонов и их количество или я не представляю ваш алгоритм обработки информации по осям. И ещё не забудьте о реверсивном движении при манёврах!!!
- посмотрите на временные характеристики реле и подсчитайте интервал между срабатываниями датчика!!! У реле время дребезга контактов очень велико и может превышать 10мс. Предлагаю посмотреть в сторону аппаратных средств применяемых в промышленной автоматики, например, WAGO - достаточно дёшево и мощно! Но, опять же климатика, но зато мощный контроллер (Linux), работающий в режиме реального времени полностью способный решать задачу отслеживания прохождения подвижных единиц (не просто тупой ввод состояния датчиков) и передавать готовую информацию в УВК, тем самым разгрузив его работу и упростив ПО УВК.

Наверное ваш расчет более правилен, если отталкиваться от условных единиц - знаков. В моем подсчете условными единицами были вагоны. К чему применить 99% - неизвестно.
Цифра 99% была получена при телефонном разговоре с этими ребятами: http://www.mallenom.ru/arscis.php

Не, вы меня не поняли. УМВ считает оси и направление. делает это быстро. Но в УВК она отдает информацию раз в секунду, саккумулировав все полученные за эту секунду данные. Отдает не факт проследования оси, а кол-во осей в единицу времени и их направление. А УВК уже обрабатывает эти данные с учетом реверсивного движения, наката и прочих тонкостей.

- думаю, что этого не достаточно, чтобы определить прохождение вагона! Я делал алгоритм прохождения вагона для САИ "Пальма" с учётом пропуска срабатывания датчика, но в информации с НСУ присутствовало не только срабатывание датчика, но и время срабатывания с точность до 1 мс.
Всегда рассчитывайте на то, что что-то может сработать криво, иначе ваша система будет работать только на столе, а природа очень изобретательна на различные штучки, вносящие квизну в работу чего-либо!:dance:
Вы не обижайтесь на критику, просто хочется, чтобы у Вас всё получилось! Кроме, того критика - это подсказка, основанная на плоде моих ошибок и мучений!
Сделать что-то - это 1/1000 по сравнению с тем, что потребуется сделать, чтобы это что-то работало хорошо и надёжно!

Обижаются девочки. Я - даю сдачи.:oiE:
На самом деле за критику надо благодарить. Значит люди проявили интерес, потратили время, чтобы чем-то поделиться. А критиковать, имея за плечами опыт, не только можно, но и нужно.

Я подозреваю, что у вас в системе информация с датчиков сразу направлялась в УВК и там с соответствующими специфическими проблемами обрабатывалась. Мы же предполагаем рассредоточенное ПО - софт УМВ определяет кол-во осей и направление за определенное время (1-2сек), а софт УВК обрабатывает эти данные.

Я немного подумал и пришёл к следующиму выводу, ваша задача - задача логистики. На безопасность движения никак не влияет и состоит из следующих подзадач:
1. АСДК (свободность/занятость путей/секций, положения стрелок);
2. Модели распределения вагонов по путям/секциям;
2.1 - определение передвижения подвижных единиц,
2.2 - логистика распределения подвижных единиц.
Первая задача решается достаточно легко, сейчас данную задачу умеет решать, кажется, каждый.
Определение передвижения подвижных единиц вы хотите решить установкой датчиков счёта осей. Для решения данной задачи с наименьшими затратами необходимо создать распределённую вычислительную сеть контроллеров (группа датчиков подтягивается к контроллеру (ЭМС+климатика), установленному на поле, с контроллера на УВК поста (две жилы кабеля, можно даже 220В, которые идут на питание контроллера счёта осей)) с цель экономии кабеля и кабельных работ - это как раз то место, где можно значительно сэкономить!!! Как технически решить эту задачу тоже понятно и нет особых проблем!
Логистика - что-то типа АРМа с увязкой с АСУ - тоже несложно!
Удачи вам!

Интересно чем закончилось изобретение "велосипеда"?
На мерседесе картошку возить накладно, хотя как знать,
надо смотреть стоимость жизненного цикла системы.
Может оказаться, что мерседес - самое то.
Мне лично нравится немецкое качество, комфорт и дизайн.:thumbup1: