Прикладные модули дистрибутива LKDSDst (MPult, MStat, MDisp) не в полной мере используют возможности драйвера LKDSDrv, в частности невозможно в одном MPulte отобразить состояния ЛБ из разных подсетей.
Подобная возможность может показаться экзотической, однако она имеет и вполне реальное применение. Часто встречаются конфигурации, когда в Главной Диспетчерской (ГД) имеется оборудование, информация с которого должна отображаться только в этой Главной Диспетчерской. Кроме того, есть оборудование, состояние которого должно отображаться в Диспетчерских Заказчика (ДЗ), т.е. в диспетчерских эксплуатирующих организаций, и в ГД одновременно, причем приоритет в отображении информации в ДЗ. Т.е. информация должна гарантированно доставляться в ДЗ, а в ГД информация нужна для общего мониторинга и для технического обслуживания (смены микропрограмм, настройка ЛБ). Пусть, для конкретности, есть одна - ГД и две – ДЗ.
В пределах одной подсети подобную структуру можно сделать двумя способами:
1. Объявить ГД активной диспетчерской (компьютер в слоте 8), а ДЗ пассивными диспетчерскими (компьютер в слоте 9), т.е. оповещения о появления событий вначале будут приходить в ГД, а потом перенаправляться в ДЗ.
2. Объявить ДЗ активными диспетчерскими, а ГД пассивной диспетчерской, т.е. оповещения о появления событий вначале будут приходить в ДЗ, а потом перенаправляться в ГД.
Оба способа имеют изъяны.
По первому способу, при потере связи между ГД и ДЗ, в ДЗ не будут приходить оповещения об ошибках, хотя зачастую КЛШ стоят непосредственно в том же ММИ, что и компьютер ДЗ.
По второму способу придется описать оборудование ГД в одной из ДЗ. Эта ДЗ будет принимать оповещения об ошибках, появляющихся в оборудовании, расположенном в ГД, и, затем, переправлять эти сообщения в ГД. При потере связи между ГД и ДЗ в ГД не будут приходить оповещения об ошибках оборудования, которое непосредственно подключено к тому же ММИ, что и компьютер ГД.
Проблема может быть решена при использовании в ГД двух подсетей. В первой подсети описано оборудование, которое непосредственно подключено к ГД и должно контролироваться в ГД. В этой подсети ГД описана как активная диспетчерская и других диспетчерских (компьютеров) в этой подсети нет. Во второй подсети описано оборудование двух ДЗ, сама ГД во второй подсети описана как пассивная. В одной ДЗ описано оборудование, которое непосредственно контролируется данной ДЗ, сам ДЗ описана как активная диспетчерская.
Можно допустить самостоятельное развитие ДЗ, т.е. они сами могут добавлять новые УМ. Что бы исключить пересечение номеров УМ, можно использовать три подсети – одна, как и была, подсеть ГД, вторая подсеть – оборудование первой ДЗ, третья подсеть – оборудование второй ДЗ. Разбиение на три подсети позволяет улучшить защиту – Mscan, запущенный в ДЗ, покажет оборудование только этой ДЗ.
Выложен первый вариант ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, содержащий прикладные модули MPultPro (аналог MPult) и MStatPro (аналог MStat), которые могут одновременно обращаться к разным подсетям. Это архив LKDSru.rar. Последовательность установки следующая:
1. Обновить LKDSDrv (c сайта) . Обязательно исполнить RegDRV.Bat
2. Заменить/добавить файлы из папки Common в папку Common установленного дистрибутива LKDSDst
3. Сделать в папке LKDS установленного дистрибутива папку MPultPro, переписать в созданную папку файлы из папки MPultPro.
4. Сделать в папке LKDS установленного дистрибутива папку MStatPro, переписать в созданную папку файлы из папки MStatPro.
5. После чего нужно пользоваться модулем MPultPro (не MPult) и MStatPro (не MStat). Что бы случайно не загрузить MPult, можно изменить ярлык запуска на рабочем столе и в меню "все программы"
При первом запуске, MPultPro проверяет наличие конфигурационного файла MPultPro.XML. Если файл не найден, то ищется файл ..\MPult\MPult.XML, который конвертируется в файл MPultPro.XML. В процессе конвертации делаются, в основном, два действия:
1. Каждому ЛБ присваивается глобально уникальный идентификатор из 32 символов – это параметр GUID раздела LIFT
2. Каждому ЛБ присваивается номер подсети, в которой он находится – это параметр SubNet раздела LIFT. Значение параметра (собственно номер подсети) берется либо из ключа –n, либо, если ключ не указан, то это номер подсети «по умолчанию». Номер подсети может быть изменен в самом файле MPultPro.XML.
В отличие от MPult, модуль MPultPro использует для уникальной идентификации лифтового блока не параметр ID (идентификатор), а GUID. Соответственно GUID используется и в именах файлов статистики (папка MPultPro\STAT) и в именах файлов предысторий ошибок (папка MPultPro\MBLog). Раньше в именах файлов использовался адрес ЛБ в сети «Обь», т.е. <УМ>_<слот>_<адрес_на_ЛШ>.Log, сейчас <GUID>.LOG. Имена файлов все равно пришлось бы менять, т.к. в адрес добавился номер подсети. Можно было бы сделать имена в формате <подсеть>_<УМ>_<слот>_<адрес_на_ЛШ>.Log Сделано <GUID>.LOG, потому, что адрес в сети «Обь» одного блока достаточно часто меняется и не может служить идентификатором. Кроме того, введение идентификатора преследовало и другую цель – возможность получения информации не только от LKDSDrv. С появлением ЛБ6Pro встал вопрос о его встраивании с сеть «Обь». Решением стал программный КЛШ – некая абстракция, понятная только тем, кто уже эксплуатировал традиционное оборудование LKDS. Если делать диспетчеризацию только на ЛБ6Pro, то может возникнуть вопрос о целесообразности использования LKDSDrv, возможно было бы разумнее сделать отдельный сервер-драйвер, настройка которого была бы проще, чем настройка LKDSDrv.
Модули визуализации данных (Common\MBLog, Common\MGraf) доработаны так, что понимаю и новый и старый форматы файлов данных. Модуль Common\ MWavManager.exe доработан так, что понимает формат имени звуковых файлов, содержащих в имени номер подсети. В папку Common добавлены модули LKDSVideo, LKDSPlayVideo предназначенные для работы с видеовозможностями ЛБ6Pro
Подобная возможность может показаться экзотической, однако она имеет и вполне реальное применение. Часто встречаются конфигурации, когда в Главной Диспетчерской (ГД) имеется оборудование, информация с которого должна отображаться только в этой Главной Диспетчерской. Кроме того, есть оборудование, состояние которого должно отображаться в Диспетчерских Заказчика (ДЗ), т.е. в диспетчерских эксплуатирующих организаций, и в ГД одновременно, причем приоритет в отображении информации в ДЗ. Т.е. информация должна гарантированно доставляться в ДЗ, а в ГД информация нужна для общего мониторинга и для технического обслуживания (смены микропрограмм, настройка ЛБ). Пусть, для конкретности, есть одна - ГД и две – ДЗ.
В пределах одной подсети подобную структуру можно сделать двумя способами:
1. Объявить ГД активной диспетчерской (компьютер в слоте 8), а ДЗ пассивными диспетчерскими (компьютер в слоте 9), т.е. оповещения о появления событий вначале будут приходить в ГД, а потом перенаправляться в ДЗ.
2. Объявить ДЗ активными диспетчерскими, а ГД пассивной диспетчерской, т.е. оповещения о появления событий вначале будут приходить в ДЗ, а потом перенаправляться в ГД.
Оба способа имеют изъяны.
По первому способу, при потере связи между ГД и ДЗ, в ДЗ не будут приходить оповещения об ошибках, хотя зачастую КЛШ стоят непосредственно в том же ММИ, что и компьютер ДЗ.
По второму способу придется описать оборудование ГД в одной из ДЗ. Эта ДЗ будет принимать оповещения об ошибках, появляющихся в оборудовании, расположенном в ГД, и, затем, переправлять эти сообщения в ГД. При потере связи между ГД и ДЗ в ГД не будут приходить оповещения об ошибках оборудования, которое непосредственно подключено к тому же ММИ, что и компьютер ГД.
Проблема может быть решена при использовании в ГД двух подсетей. В первой подсети описано оборудование, которое непосредственно подключено к ГД и должно контролироваться в ГД. В этой подсети ГД описана как активная диспетчерская и других диспетчерских (компьютеров) в этой подсети нет. Во второй подсети описано оборудование двух ДЗ, сама ГД во второй подсети описана как пассивная. В одной ДЗ описано оборудование, которое непосредственно контролируется данной ДЗ, сам ДЗ описана как активная диспетчерская.
Можно допустить самостоятельное развитие ДЗ, т.е. они сами могут добавлять новые УМ. Что бы исключить пересечение номеров УМ, можно использовать три подсети – одна, как и была, подсеть ГД, вторая подсеть – оборудование первой ДЗ, третья подсеть – оборудование второй ДЗ. Разбиение на три подсети позволяет улучшить защиту – Mscan, запущенный в ДЗ, покажет оборудование только этой ДЗ.
Выложен первый вариант ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ, содержащий прикладные модули MPultPro (аналог MPult) и MStatPro (аналог MStat), которые могут одновременно обращаться к разным подсетям. Это архив LKDSru.rar. Последовательность установки следующая:
1. Обновить LKDSDrv (c сайта) . Обязательно исполнить RegDRV.Bat
2. Заменить/добавить файлы из папки Common в папку Common установленного дистрибутива LKDSDst
3. Сделать в папке LKDS установленного дистрибутива папку MPultPro, переписать в созданную папку файлы из папки MPultPro.
4. Сделать в папке LKDS установленного дистрибутива папку MStatPro, переписать в созданную папку файлы из папки MStatPro.
5. После чего нужно пользоваться модулем MPultPro (не MPult) и MStatPro (не MStat). Что бы случайно не загрузить MPult, можно изменить ярлык запуска на рабочем столе и в меню "все программы"
При первом запуске, MPultPro проверяет наличие конфигурационного файла MPultPro.XML. Если файл не найден, то ищется файл ..\MPult\MPult.XML, который конвертируется в файл MPultPro.XML. В процессе конвертации делаются, в основном, два действия:
1. Каждому ЛБ присваивается глобально уникальный идентификатор из 32 символов – это параметр GUID раздела LIFT
2. Каждому ЛБ присваивается номер подсети, в которой он находится – это параметр SubNet раздела LIFT. Значение параметра (собственно номер подсети) берется либо из ключа –n, либо, если ключ не указан, то это номер подсети «по умолчанию». Номер подсети может быть изменен в самом файле MPultPro.XML.
В отличие от MPult, модуль MPultPro использует для уникальной идентификации лифтового блока не параметр ID (идентификатор), а GUID. Соответственно GUID используется и в именах файлов статистики (папка MPultPro\STAT) и в именах файлов предысторий ошибок (папка MPultPro\MBLog). Раньше в именах файлов использовался адрес ЛБ в сети «Обь», т.е. <УМ>_<слот>_<адрес_на_ЛШ>.Log, сейчас <GUID>.LOG. Имена файлов все равно пришлось бы менять, т.к. в адрес добавился номер подсети. Можно было бы сделать имена в формате <подсеть>_<УМ>_<слот>_<адрес_на_ЛШ>.Log Сделано <GUID>.LOG, потому, что адрес в сети «Обь» одного блока достаточно часто меняется и не может служить идентификатором. Кроме того, введение идентификатора преследовало и другую цель – возможность получения информации не только от LKDSDrv. С появлением ЛБ6Pro встал вопрос о его встраивании с сеть «Обь». Решением стал программный КЛШ – некая абстракция, понятная только тем, кто уже эксплуатировал традиционное оборудование LKDS. Если делать диспетчеризацию только на ЛБ6Pro, то может возникнуть вопрос о целесообразности использования LKDSDrv, возможно было бы разумнее сделать отдельный сервер-драйвер, настройка которого была бы проще, чем настройка LKDSDrv.
Модули визуализации данных (Common\MBLog, Common\MGraf) доработаны так, что понимаю и новый и старый форматы файлов данных. Модуль Common\ MWavManager.exe доработан так, что понимает формат имени звуковых файлов, содержащих в имени номер подсети. В папку Common добавлены модули LKDSVideo, LKDSPlayVideo предназначенные для работы с видеовозможностями ЛБ6Pro
Последнее редактирование модератором:
, и формат видеофайла наверняка нестандартный 
.
Но даже если и посмотрел номер УМ то искать потом в полутысчи лифтов этот адрес практически нереально... так и есть.
