Windows Сервис LKDSDomain
- Автор темы Andi
- Дата начала
grandetype
Новичок
Андрей Ефименко написал(а):
Дело в том, что у меня 2 сервера в разных местах и на обоих последнее время стало наблюдаться такое. С другого клиента ASPult такая же картина. Либо обновление Domain, либо ASPult.
Названия вообще всех блоков стали на английском
Последнее редактирование модератором:
Grande написал(а):
Что бы ускорить процесс поиска причин непонятностей существует пункт меню "Формирование данных для обращения в тех.поддержку (SaveLog)". Поэтому я и запрашивал эти данные.
Действительно был недосмотр и он бы выявился раньше, если бы данные были.
В обновление ПО выложен исправленный модуль, содержащий расшифровки кодов ошибок станций управления и наименований ЛБ.
Что бы изменения начали действовать сразу, нужно вручную обновить ПО, а затем вручную перезагрузить службу LKDSDomain.
В автоматическом режиме, обновление ПО произойдет ближайшей ночью, этой же ночью LKDSDomain начнёт сам использовать новые расшифровки кодов ошибок.
Одной из причин разработки LKDSDomain была необходимость использования новым возможностей ЛБ7.2
Важная новая возможность ЛБ7.2 - поддержка большого число точек для голосовой связи (переговорных устройств). Эти переговорные устройства можно описать в SPult в параметрах лифта и включать ГГС с нужной ПУ, но до сих пор не было невозможно определить с какого ПУ пришёл вызов.
LKDSDomain доработан для определения откуда поступил вызов.
Хотел бы эту возможность предварительно проверить. Для этого нужно заменить LKDSDomain.exe, причем описывать ПУ в SPult необязательно, если ПУ, откуда поступил вызов, не описана в SPult, то будет использовано предопределённое название ПУ.
Определение ПУ, с которого ПУ пришёл вызов, делается только для ЛБ с прямым подключением.
Доработанный LKDSDomain доступен здесь Выложено в штатное обновление ПО
Процедура замены следующая:
1. Файл \LKDSDrv\LKDSDomain\LKDSDomain.exe переименовываем в файл \LKDSDrv\LKDSDomain\LKDSDomain.exe_old
2. Файл LKDSDomain.exe переписываем в папку \LKDSDrv\LKDSDomain\
3. Из диспетчера задач из закладки "Службы" перезапускаем службу LKDSDomain
Важная новая возможность ЛБ7.2 - поддержка большого число точек для голосовой связи (переговорных устройств). Эти переговорные устройства можно описать в SPult в параметрах лифта и включать ГГС с нужной ПУ, но до сих пор не было невозможно определить с какого ПУ пришёл вызов.
LKDSDomain доработан для определения откуда поступил вызов.
Хотел бы эту возможность предварительно проверить. Для этого нужно заменить LKDSDomain.exe, причем описывать ПУ в SPult необязательно, если ПУ, откуда поступил вызов, не описана в SPult, то будет использовано предопределённое название ПУ.
Определение ПУ, с которого ПУ пришёл вызов, делается только для ЛБ с прямым подключением.
Процедура замены следующая:
1. Файл \LKDSDrv\LKDSDomain\LKDSDomain.exe переименовываем в файл \LKDSDrv\LKDSDomain\LKDSDomain.exe_old
2. Файл LKDSDomain.exe переписываем в папку \LKDSDrv\LKDSDomain\
3. Из диспетчера задач из закладки "Службы" перезапускаем службу LKDSDomain
Последнее редактирование модератором:
Ранее в конфигуратора LKDSDomainCfg была добавлена возможность групповой загрузки микропрограмм в ЛБ, которые имеют непосредственную связь с LKDSDomain
В обновление ПО выложен конфигуратор LKDSDomainCfg, который имеет возможность групповой загрузки микропрограмм в оконечные устройства ЛБ7 (переговорные устройства и т.п.). Групповая загрузка производится из списка оконечных устройств
по пунктам меню правой кнопки мыши 
В обновление ПО выложен конфигуратор LKDSDomainCfg, который имеет возможность групповой загрузки микропрограмм в оконечные устройства ЛБ7 (переговорные устройства и т.п.). Групповая загрузка производится из списка оконечных устройств
по пунктам меню правой кнопки мыши Вложения
kurilka написал(а):
Если имеется в виду в одном приложении изменять географическую структуру и пользователей всех организаций сразу, то нет.
Географическая структура и права пользователей одной выбранной организации могут быть изменены SPult в Административном режиме при удалённом подключении к выбранной организации.
Андрей Ефименко написал(а):
Допустим есть 10 контрагентов (заказчики). Им необходимо предоставить возможность наблюдать за работой лифтов своей организации. Для этого потребуется:
- создать 10 организаций;
- создать в каждой организации пользователя admin;
- создать 10 подключений в SPult (для каждой организации);
- подключиться админом к каждой организации и провести настройку как бы LKDSDisp для каждой отдельно.
Как все это контролировать и админить? А если контрагентов 300+?
kurilka написал(а):
Действительно, нужно действовать именно так, как описано.
Т.к. SPult удалённо подключается к LKDSDomain в режиме Администратора, то можно передать функции администрирования самому заказчику.
Если же ещё хочется для себя видеть все лифты сразу, как и предлагал poiZon, нужно сделать ещё одну организацию, содержащую лифты всех заказчиков, но только для наблюдения за состояниями лифтов, а не для администрирования организаций заказчиков.
Конечно, работа по заведению лифтов удваивается, но пока альтернативы нет.
LKDSDisp и SPult разрабатывались в паре друг для друга.
Андрей Ефименко написал(а):
Все первернуто с ног на голову.
Заказчики, которые могут что-то администрировать, обучают и аттестовывают свой персонал, организовывают свои диспетчерские - устанавливают КЛШ для наблюдения или компьютер. Те же, которые не хотят этим заниматься как раз и предают функции организации, обслуживающей лифты. Им нет никакого дела до структуры сети "Обь", до УМ, слотов и т.д. Все, что они хотят, это видеть заветные 5 (10, 20, у кого сколько лифтов) квадратиков у себя на экране и ткнув мышкой посмотреть, как работает лифт. И как это чудо происходит им все равно.
Андрей Ефименко написал(а):
А дальше? Например лифты из одной УК перешли в другую, поменялась структура сети и лифты из УМ1 переместились в УМ4. А если еще механиков завести?
Андрей Ефименко написал(а):
В общем-то я с kurilka согласен, специализированная организация для того и существует чтобы всякие мелкие ТСЖ и иже с ними не заморачивались администрированием и всякими проблемами, они хотят чтобы лифт ходил и их никто не беспокоил, иногда хотят за лифтами подглядывать. Логично что в домаин надо заводить организации по числу заказчиков, а администрировать все их одним пользователем. Кстати про права доступа в домаин я уже писал, почему механиков и связистов указывает админ? Есть прораб который назначает механа, пусть он и указывает. А теперь представим что администрировать приходится самому заказчику, он ведь вообще не в курсе какого механика ему назначила обслуживающая организация. Кстати на период отпуска или болезни механик назначается другой, не лишним было бы иметь возможность указывать подменного механика, и вообще отлично было бы если можно было указывать, что временный механик до такого-то числа (мы ведь заранее знаем когда у него отпуск закончится).
kurilka написал(а):
Вот тут не совсем понял. Если вы обслуживаете обе УК, то почему лифты перешли из УМ1 в УМ4, вы же номера УМ сами назначаете, и уж коли лифты у вас остались на обслуживании, то зачем менять структуру сети? Просто переносите лифты из одной организации в другую.
poiZon написал(а):
В моем предложении выше изменение структуры сети не является следствием перехода лифтов из одной УК в другую, т.е. запятую можно заменить союзом "или".
А как в LKDSDomain осуществляется перенос лифтов из одной организации в другую?
Андрей Ефименко написал(а):
Что сейчас предлагает LKDSDomain? Администрировать каждую организацию отдельно, т.е. одна организация – один админ, для каждой организации свои пользователи, свои группы , свои лифты. Все это изолированно друг от друга. Нет единой точки, откуда всем этим управлять, происходит «распараллеливание», появляются клоны лифтов, а для главного админа всей системы функции администрирования сводятся к настройке и поддержке функционирования сервера: чтоб железо работало и службы не висли.
Админ должен быть один. Админ должен добавлять лифты и предоставлять доступ к лифтам, а лифт должен быть в единственном экземпляре. Возможно ли это реализовать в текущей версии LKDSDomain вопрос сложный.
kurilka написал(а):
Сейчас штатными средствами нельзя перенести лифт из одной организации в другую.
Не понятно как это сделать и в базе данных. Можно, конечно, вручную прямо в базе данных в таблице Lift в записи лифта исправить поле CodHouse на код дома из другой организации, но это приведёт к плохим результатам, т.к. этот лифт (код записи лифта а БД) используется во многих таблицах, которые в свою очередь косвенно связаны с записью организации в таблице Team - это журнал событий (Event), переговоры (HdrVoice), группы лифтов по размещению (GroupLift), размещение в профилях (ProfileLift), описатели оповещения.
Лифт не может быть перенесён из одной организации в другую, т.к. в организации, из которой переносится лифт, должна остаться история по этому лифту.
В БД LKDSDomain есть таблица LiftUnit, в которой по сути и содержаться лифы (лифтовые блоки), а записи в таблице Lift - это как бы представление лифта в организации.
Можно представить конфигуратор типа SPult в административном режиме, который бы показывал общую структуру LKDSDomain, т.е. с дополнительным уровнем - организацией. В этом конфигураторе можно было бы скопировать лифт из одной организации в другую, при этом копировании нужно ещё указать нового пользователя для переноса оповещений, которые привязаны к лифту. Нужно ещё подумать что делать с группами по размещению в общей структуре организации и в профилях.
Можно обсудить возможности этого конфигуратора.
Андрей Ефименко написал(а):
К сожалению, можно констатировать тот факт, что LKDSDomain, который должен был избавиться от проблем LKDSDisp, не только сохранил их, но и приобрел новые. Новые ограничения, невозможность реализации некоторых задач и процессов. Конечно, можно обсуждать новый конфигуратор и искать способы обойти те или иные ограничения, но к чему это приведет. Новые конфигураторы, дополнительные настройщики и придуманные «обходные костыли» только сделают LKDSDomain громоздким, усложнят его настройку и администрирование. Пользователям снова придется мириться с ограничениями, которые не удастся устранить, придется подстраивать свои рабочие процессы под функционал LKDSDomain.
Очевидно, что источником всех этих ограничений и проблем является БД, которая является фундаментом данного программного продукта. Именно БД не позволяет реализовать многие задачи. В этой ситуации не понятно, почему ошибки, допущенные при проектировании БД, пытаются исправляться созданием новых конфигураторов и введением ограничений. Почему исправляются последствия, а не устраняется источник проблем. Ведь гораздо эффективнее «бросить силы» на исправление БД или создание новой, которая будет соответствовать текущим требованиям и задачам и будет способна реализовать пожелания и «хотелки» пользователей.
kurilka написал(а):
Мнение понятно.
1. Идеальных инструментов не бывает. Поэтому уже достаточно давно идет реализация стандартных интерфейсов для взаимодействия ДК «Обь» со сторонним программным и аппаратным обеспечением. Это даёт возможность пользователям разработать свои, полностью подходящие им средства диспетчеризации на основе лифтовых блоков, производства ООО «Лифт-Комплекс -ДС».
Самым первым был реализован интерфейс сервера OPC DA.
Этот интерфейс имеет существенные ограничения, поэтому был реализован протокол OPC UA и его функционал будет расширяться.
Уже есть начальная реализация протокола SIP для передачи голоса и интеграции с телефонией.
В настоящее время можно использовать лифтовые блоки вообще без промежуточного программного обеспечения, т.к. лифтовые блоки 7.2. поддерживают протокол MQTT и Modbus.
2. ДК «Обь» развивалось эволюционно. На мой взгляд именно это и позволило постепенно наращивать возможности, не теряя при этом преемственности. Опять же на мой взгляд, другого пути развития сложных технических систем нет. Видимые «революции» в развитии сложных технических систем — это переход большого количества, может и незначительных, эволюционных изменений в новое качество системы. Конечно, ДК «Обь», как и любая система, имеет ограничения и задача - осознанными доработками устранить эти ограничения. Поэтому предлагаю вначале «озвучить» ограничения, озвучить «текущие требования и задачи».