Цитата:
|
а до автора второй день не могу дозвониться
|
Выкладывайте нет проблем!
Ж.д. телефон автора 9-25-79 или 8-(8172)-79-25-79.
Просто инженер АиТ добавил 30.01.2013 в 09:11
А Зингер М.Б. вчера был в Москве. А по техническим вопросам может ответить и
Просто инженер.
Просто инженер АиТ добавил 30.01.2013 в 10:04
Уважаемый Николай Николаевич! А видели ли вы документ написанный ещё 2003 г. после того, как, тогда ещё "Лаборатория микропроцессорной техники" реализовала свою централизацию КТСМ, по причине отсутствия каналов связи для построения СПД АСК ПС по стандартной схеме. В этом документе есть ответы на многие вопросы, которые сейчас появились. Три года мы честно поддерживали централизацию, пока не появились каналы связи.
КТСМам считаю необходимым придать статус системы отвечающей за безопасность движения и системы реального времени, а отсюда сразу же появятся реальные требования.
Кроме того, я бы КТСМ увязал с АБ и ЭЦ станции, так как например, увязывают УКСПСы и дополнил её системой "Пальма" для возможности индентифицировать сразу номер больного вагона. Технически это сделать можно без особых проблем. Правда сертификация потебует материальных затрат. А если систему "Пальма" слегка переделать, то её можно размещать на опоре контактной сети.
Просто инженер АиТ добавил 30.01.2013 в 16:56
Хочу вставить пару картинок как у нас было.
Просто инженер АиТ добавил 30.01.2013 в 16:59
Просто инженер АиТ добавил 31.01.2013 в 09:44
Как видно из картинок вроде ничего сложного
, но вот только пару моментов омрачают ситуацию:
1 - нельзя потерять ни одного сообщения;
2 - доставить нужно хотя бы за 5 секунд.
И из за этих моментов ПО перестаёт, казаться, простым. Для многих систем ТС/ТУ (АСДК, ДЦ, СДУМ и т.д.) первый момент не так критичин, т.к. опрос происходит циклично и потеря одного сообщения даже не будет видна в АРМе.
Но совсем другое дело в централизации КТСМов, потеря одного сообщения может привети к потери больного вагона!!!
Просто инженер АиТ добавил 31.01.2013 в 10:09
То, что показано на картинках - это только одна часть функций, которые поддерживал Концентратор Информации ЛМТ (КИ ЛМТ).
КИ ЛМТ выполнял следующие функции:
1 поддержка СПД любой архитектуры с возможностью объединения и расщепления информационных потоков с контролем доставки сообщений. Обмен по физическим линиям связи (линии связи как правило выделяли самые отвратительные, по которым телефон, то не мог толком работать), по каналам ВЧ (поддерживалось до 18 модемов на один КИ и 16 СОМ портов), по UDP/TCP соединениям;
2 Съём дискретных сигналов с предварительной обработкой (собственные модули съёма с лампочек пульт-табло, ПИК120) (количество сигналов практически не ограничено);
3 Съём аналоговых сигналов ПИК-10;
4 Стыковка с аппаратурой ДИСК на нижнем уровне и централизация;
5 Стыковка с КТСМ на уровне станций;
6 Централизация КТСМ;
7 Стыковка с системой "Пальма" на уровне НСУ;
8 Централизация системы "Пальма" и обмен с АСУ:
9 Сервер Баз данных;
10 Web сервер (АСДК, КТСМ, "Пальма").
Ещё так по мелочи.
Всё ПО+Linux помещалось на "Disk-on-chip" размером в 32 метра и могло работать на IBM подобной машине с 386 процессором и выше. ПО без изменения исходных текстов могло работать под: DOS 6.22, QNX 4.25, Linux, Windows при этом загруженность процессора была ниже 1%.
Просто инженер АиТ добавил 31.01.2013 в 10:35
ПО представляло из себя трансфомер, при запуске ПО конфигурировалось согласно файлам инициализации, поэтому загрузочный модуль был всегда один и тот же, что для станции, что для серверов, что очень удобно при обслуживании, не надо ломать голову какие загрузочные файлы устанавливать.
Конфигурирование различных съёмов было автоматическое, т.е. не надо было описывать какие и сколько модулей съёма (дискретный модуль съёма, ПИК120, ПИК10, ...) были подключены, но была диагностика работы каждого съёма.
ПО без диагностики (аппаратных средств, контроля выделяемой памяти, обмена, ...) некогда не обеспечит должного качества работы.
