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

Тема ушла "не туда".
В соседней ветке появился вполне адекватный комментарий одного из руководителей "Инфотэкса" - всех отсылаю ознакомиться.
Все приоритеты там обозначены правильно.

paul_korablyov

Здравствуйте!

Раз зашёл разговор про Мониторинг, давайте я попробую прояснить ситуацию, изложив наш (Инфотэкса) взгляд на эту программу и ситуацию, связанную с ней.

Цитата: Есть такое ПО, но оно продается Инфотэксом за отдельные деньги, соответственно практически нигде не закуплено.

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

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

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

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

Нет, поставлена задача заделать дыру, которая привела к тому, что информация от КТСМ вовремя не была доставлена на АРМ ЛПК. Это на первом этапе.

С уважением, Павел Кораблев (Инфотэкс АТ).

Skay

Еще одна программа для ЦМ. Кто и как будет следить за этими данными? Сменным технологам хвотает основной программы. И идея была затащить эти данные (нужные для СЦБИстов) туда - где с анализом по различным алгоритмам выдавать сообщения об отказных и предотказных состояниях системы.

paul_korablyov

Мы предлагали различные варианты интеграции не по первичным данным, а по объектам, которые можно было бы внедрить в мониторинг. Речь идёт об экранных формах, которые могут быть реализованы с помощью технологий программирования и "вживлены" в единый мониторинг. Этот способ был отвергнут. И мы не поняли, кто должен будет реализовать упоминаемый Вами анализ и по различным алгоритмам (тоже неясно, чьим) выдавать сообщения об отказах и предотказных состояниях. Для нас это звучало так: отдайте все данные, а дальше мы сами всё сделаем. Мы решили, что этот бумеранг к нам вернётся с очень болезненными последствиями. Поэтому и стали предлагать альтернативные варианты, а они не были приняты. Поэтому и не изменилось ничего с 2006 года.

С уважением, Павел Кораблев (Инфотэкс АТ).

RUG47

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


Неужели это трудно сделать скажите мне лоху??

paul_korablyov

Здравствуйте!

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

С уважением, Павел Кораблёв (Инфотэкс АТ)

Скиталец

Какая неожиданность!

ilolge

Все отписАлись?
а пример памяток выложите выкладите покажите,пож-ста