Форум » » Зпись логов » Ответить

Зпись логов

Kirillka: Доброго времени суток. Может мой вопрос покажется немного странным, но очень для меня актуален. Поскольку опыта в обращении с контроллерами не очень много, я не много не понимаю в какую сторону мне копать. Возникла необходимость в записи логов использования тачпанели. А именно какие кнопки были нажаты, что именно включалось и выключалось и в какой момент времени. Сие необходимо для того, что бы не было отрицания в виде "Все сломалось, но эти кнопки я не трогал" Подскажите. есть какая то возможность вынести запись логов на сторонний сервер. Какое По для этого можно использовать ?

Ответов - 8

eoulianov: Добрый день, Kirillka! Технически это делается в зависимости от OS стороннего сервера - на e-Control®2 Power Applications (e-DataLog из них), RoomView® Express или Fusion RV®. Я предпочитаю первый из них, но сейчас уже придётся повозиться с compatibility, чтобы оно завелось на Windows 7. По уму, если вы пришли к проблеме, что пользователь что-то ломает в системе с кнопок, и он это реально делает, а вам нужно оправдываться - значит вам нужно работать над дуракоустойчивостью системы. Нужно договориться и подправить задание, чтобы ядерные кнопки ушли из интерфейса, или скрылись под пароль, или сделались недоступны, когда могут повредить системе, или вы изменили бы логику системы чтобы всё не ломалось, а наоборот - чтобы вы написали стабильные макросы, которые всегда включают систему в запрашиваемый режим независимо от предыдущего (пусть бы и "сломанного" пользователем с кнопок панели) состояния системы.

Игорь K.: Согласен с вышевыступающим насчет политического решения политических же проблем, хоть и с запозданием. Разруливание технически (программно) по опИсанному сценарию приведет к потере понимания с заказчиком. Запись логов применима для ловли ошибок в программе, глубокого анализа и осмысления своих же деяний.

Kirillka: Прошу прощение, наверное немного не правильно выразился, поломка пользователем программы маловероятна, тут скорее технический аспект. Т.е пользователь начинает тыкать по разным кнопкам включения экранов и выключения. Включение поликомовских камер или отключение. В результате камеры выключаются, и что бы опять поднялись нужно некоторое время. пользователь пугается и начинает усиленно вводить систему в ступор нажимая на все подряд. Как вы выразились защита от дураков. Но тут есть еще одна проблема. приставить конкретного человека на включение и выключение, это не выход. И конечно не все могут отреагировать ан дружелюбный интерфейс с русским описанием. казалось бы куда уж проще, но видать есть еще куда. Иногда бывает просто обрыв канала, что бы его поднять, нужно нажать на реконнект, но куда там, некоторые дома и кран с водой могут отломить при включении воды. Добрый день, Kirillka! Технически это делается в зависимости от OS стороннего сервера - на e-Control®2 Power Applications (e-DataLog из них), RoomView® Express или Fusion RV®. Я предпочитаю первый из них, но сейчас уже придётся повозиться с compatibility, чтобы оно завелось на Windows 7. За совет спасибо, если я у вас поподробнее узнаю, ничего страшного ? вин 7 тут не априори, можно найти что то и на win serv 2003 -2008 можно и на 2000 построить не вопрос, главное что бы стабильно работало. вот наверное отсюда и будет вопрос, что будет попроще в настройке и выше перечисленного ?


p.vladi: А может не делать индивидуальный контроль под питание камер и экранов? Задержку в включении после выключения можно отследить, команду задержать, показать убывающий слайдер. Канал можно проверять пингом… На самом деле, клиенту нельзя доказывать, что он не прав. Они этого очень не любят. Особенно когда не правы

Kirillka: Тут скорее опять непонятки вышли ) Я вроде про клиентов не писал. Я пишу не от лица Вендела, или интегратора. А скорее наоборот, я являюсь пользователем. а точнее тех. специалистом который все это дело обслуживает. Но по специфике мне пришлось заняться программированием, чему я очень рад потому что мне это понравилось. Ну и как раз вылезают вот такие проблемы, как я описал вышел. Клиентов у нас как таковых нет, есть сотрудники, которые проводят ВКС. Ему ведь, сотруднику не объяснишь куда можно нажимать а куда лучше не нужно когда идет рабочая ВКС. А потом начинается, Это я не нажимал, вы не правы, я даже и не трогал эту кнопку. И ведь никто не признается. Вот и возникла проблема с ведением логирования на отдельный сервер

eoulianov: Логи не помогут в этой ситуации, потому что кроме действий в них не будут записаны причины, по которым пользователь нажимал это всё - и потом не разберёшься что зачем( Займитесь эргономикой: - попользуйтесь системой "ручками", - выделите рабочие сценарии (повторяющиеся последовательности действий, которые вы производите во время работы), например "сначала включается экран, на него выводится кодек, в нём - адресная книга, там выбирается абонент или сервер многоточки, и происходит подключение" - определите режимы (те состояния, между которыми переходит система по вашему осмысленному желанию), например "докладчик у нас" = "на экране камера удаленной стороны, на другом - контент с нашего презентационного устройства (напрямую), звук - с ВКС, шторы закрыты общий свет приглушен, докладчик ярко освещен, уровень микрофона докладчика - нормальный, остальных - понижен" - составьте список кошмарных ситуаций, возникавших или потенциально возможных при пользовании системы (например, попадение метеорита в окно), оставьте те, которые можно решить на лету (например, отключение микрофона необдуманным широким жестом), попробуйте придумать, как можно автоматически угадать, какие из них случились (пропала картинка с источника, и сенсор это засёк), решите, нужно ли вам что-то от пользователя в какой-то проблеме (вы определили разрыв IP соединения и нужно переспросить пользователя, стоит ли реконнектиться), ну и собственно каким образом можно сделать хорошо в сложившейся ситуации. Для чего это всё нужно? -Сценарии нужны чтобы собрать в кучу необходимые для их выполения кнопки (и спрятать подальше ненужные) и дать возможность пользователю выполнять часто используемые действия не переключая страниц на панели. Ничего, если курсорные кнопки кодека ВКС окажутся повторены на нескольких страницах, но плохо если кнопка перезагрузки кодека находится опасно близко от enter) -Режимы нужны для написания макросов под них - чтобы пользователь нажал одну кнопку этого режима, например, "презентация", а система включила всё в этот режим сама. Пока система переходит из чего-то в выбранный режим, заблокируйте управление, чтобы пользователь не порушил этот процесс. Всякие кнопки раздельного включения/выключения аппаратов выкиньте, оставив вместо них режимы - это проще пользователю. - Обработка сбойных ситуаций добавляет ощущение "надёжности" и "контроля над ситуацией". Вот пример достаточно простой инструкции: "Нажимайте кнопки, на которых написано то, что вам сейчас хочется. Если что-то идёт наперекосяк - вернитесь назад и выберите заново режим (кнопки режимов должны отличаться от остальных кнопок, как и кнопки переключения страниц самой панели), если и это не помогло - выключите всё и включите заново". Придумайте что-то подобное для этого проекта и в одном стиле выдерживайте. Отношения у вас все равно клиентские: вы с этими "сотрудниками" не связаны прямо договором купли-продажи или оказания услуг, но опосредовано с работодателем - трудовым договором. И удовлетворение потребностей этих "коллег", увы те же - только сбоку)

Kirillka: Может оно и так ) Но тут ничего не поделать. С эргономикой тут вы правы, это все в перспективе. лично мое видение переговорных в моей компании разительно отличается от того что есть сейчас. Но пока так, я приложу все усилия что бы сделать так как будет действительно все было довольно эргономично. А сейчас к сожалению мне поставили задачу сделать логирование, именно того что я описал вышел. Вот по этому и возник вопрос по поводу выделения логов на отдельный сервер.

Igor: Kirillka, в качестве радикального способа можно рекомендовать поднять на объекте какую-либо SCADA, способную поедать и разбирать данные с того же СОМ-порта ПК. Подключить контроллер к этому ПК, разработать свой простенький протокол, в котором информировать SCADA о фактах активности со стороны сенсорной панели.



полная версия страницы