Коллеги и Господа!
Предлагаю написать новую (для России) книгу: Удаленный контроль, визуализация и диспетчеризация инженерных систем здания
Сразу за "рога":

1. Возможно, кто-то готов написать вступление, небольшое, ½ страницы.
2. Кто готов дать краткое содержание или сделать оглавление (желаемое)?

Разумеется, название несколько условное, но вроде смысл отражает.
В чем плюсы участия в творческом коллективе для написания книги?
Да, наверное, по-разному специалисты могут решить этот вопрос для себя. Обещать гонорары пока совсем неоткуда. Вопрос с включением в список авторов, мне кажется решаем. Упоминание компании - возможно. Если специалист сделает существенные замечания, то, наверное, и это можно отразить упоминанием.
И самое главное как мне кажется – это получить свой именной экземпляр книги раньше, чем она выйдет из печати.

С учетом мыслей в другой теме, предлагаю ограничиться "академическим" рассмотрением материала. Так быстрее найти спонсоров для издания. Почти наверняка будет и другой список, "свой в доску" вот про этот вариант получения именного экземпляра выше я и упомянул. Такой никто не согласится издать за свой счет. А в электронном виде иметь будем и активистам разошлем.
З.Ы. Извиняюсь перед ggg_ggg, что не утерпел до апреля. Сам виноват, пишет. Если не начну сейчас за ним подбирать, то боюсь многое потеряем .
Во, один автор есть. Пусть он и решает, кто вторым станет!

Вся проблема в главном - найти причину, по которой надо применять этот удаленный доступ.
Я тут недавно отказался от участия в проекте: Москва, Центр, Банк, а управление - из Лондона. Не нравится мне это. Не понятно.
А если что-то непонятно - я в этом не участвую.

Неплохо было бы еще определится начиная с какого расстояния доступ начинает считаться удаленным и какие технологии связи могут использоваться для удаленного доступа (только TCP/IP или другие варианты тоже принимаются)

В другой ветке я пытался дать определение "удаленному доступу". Предлагаю за основу взять ВРЕМЯ, необходимое для внесения изменений в функционирование системы, причем эти изменения не должны быть предусмотрены алгоритмом системы. Проще говоря, то время, которое потребуется, например, для включения "выбитого" автомата. Конечно, тут есть над чем подумать. Например, зимой, при -25, "выбитый" автомат защиты циркуляционного насоса - это очень плохо. Летом - пофигу. Т.е. надо определить список "критических аварий и нештатных ситуаций" для АСУЗ, требующих вмешательства ЧЕЛОВЕКА.
Насчет TCP/IP - ну конечно же это не единственный вариант. Модемные соединения, SMS, да хоть голосовое управление - все это имеет место быть. Просто TCP/IP - самое распространенное решение.

!!!
Если идти от простого к сложному, то один из самых простейших вариантов:
http://www.e2000.ru/E2051s.html

2 ggg_ggg
С предпосылками, по моему все ясно.
Собственники, и управляющие компании не хотят заморачиваться с инженерией.
=> Направление аутсорсинга обслуживания инженерной инфраструктуры будет развиваться.
=> мы придем к тому, что аутсорсная аварийно-сервисная служба, будет работать как пожарная бригада, т.е. мчаться по сигналу от систем диспетчеризации.

+ появляются возможности, для интеграция с EAM для крупных/сетевых объектов

imho диспетчеризация инженерки 100% движется в направлении WEB (WEB 2.0) как и весь мир плане софта (долго еще правда )
Предпосылки:

1. Удаленный доступ или мобильное рабочее место - уже есть (не надо ничего ставтить кроме IE и Java - например)
2. Стоимость - получается дешевле чем покупать лицензию на каждое место
3. Аутсорсинг пожалуйста - к какой систем подключился с той и работаешь ничего не надо ставить

С модным словом "аутсорсинг" соглашусь. Про WEB - тоже понятно, сам об этом писал. Про ЕАМ не понял. Теперь про "нехорошести".
1) Пожарные подстанции расположены так, чтобы обеспечить заданное ВРЕМЯ прибытия на объект. Еще у них мощные машины, мигалки и
обширные права, но иногда и это не помогает из-за несознательности граждан. Значит, критерий - ВРЕМЯ прибытия на объект.
2) Для обеспечения эффективной работы ремонтной бригады необходимо УНИФИЦИРОВАТЬ ВСЕ РЕШЕНИЯ! Трудно представить бригаду, которая за 5 минут разберется в проекте и примет решение о устранении неисправности. Опять же - запчасти и прочее. Какие же спецы должны там работать?
3) Лицензии КОПЕЙКИ стоят на фоне стоимости "инженерки". Для WEB - Сервера придется делать (для аварий, логов, трендов). Причем очень нехилые.
Любое изменение в проекте - и понеслась.... Думаю, расписывать не стоит - вещь очевидная. Особенно приятно, когда выехавшая бригада
"экстренной помощи" что-то сделала для "оживления" объекта. Неделю писать будут, не до работы. А если не будут - то потом там НИКТО не разберется.
4) "Текучка" кадров в аутсорсинговой компании с WEB-технологией добавит "головной боли" по поддержанию безопасности. А это - деньги!
Ну, пока хватит "негатива".

То ggg__ggg:

1., 4. Не столь существенно, если "пожарной командой" будет бригада управляющей компании. Соответствующие специалисты при наличии соответствующего оборудования должны быть в наличии, иначе работать УК (аутсортинговая компания, если угодно) не сможет.
2. Унификация решений предполагает серьёзное объединение на уровне страны проектных и монтажных организаций, создание холдинга по типу СССРовских "Монтажспецстрой", единой проектной организации в Москве с обязательным выполнением проектных решений по всей стране. Подготовка специалистов по единым учебным программам. Потом создание Госплана. Потом опять застой. Если это будет, то не так скоро.
3. Лицензии почти умерли, что будет с СРО ещё не совсем понятно, по крайней мере, у нас про это пока тишина и существенные движения начнутся при массовом окончании срока действия лицензий.
4. При наличии реальной проблемы угрозы безопасности всегда найдутся решения. Самым простым является ежедневная смена пароля, как на каналах ЗАС связи.

To ATX
Поясните, плз, Вашу мысль.
Чашка кофе и сигара - потянуло на "позитив".
Предлагаю следующую идею. Почти ВСЕ производители крупных узлов и агрегатов для "инженерки" имею какой-то интерфейс для сервиса.
Будь то LON, Modbus или что-то другое. В случае обнаружения отказа (неисправности) оборудования, можно :
1) переключиться на резерв , ручное управление, выключить из техпроцесса данный агрегат
2) отправить сообщение в сервисную службу
3) ГЛАВНОЕ - переключить на УДАЛЕННОЕ тестирование данный агрегат, но ТОЛЬКО ЕГО, а не всю систему.
4) дождаться прибытия сервисной службы, сняв "головняк" с допуском на объект, точнее - помещение, где стоит агрегат.
Конечно. если бы ВСЕ производители перешли на WEB- технологии, было бы проще. Вот для них это СУЩЕСТВЕННО, т.к. ВСЕ преимущества WEB стали бы помощниками. Однако, пока это УТОПИЯ, а вот организовать на объекте доступ сервисных служб фирм-поставщиков к СВОИМ агрегатам - это достаточно злободневная задача.
Здесь и можно порассуждать о методах организации такого удаленного доступа.

to ATX
Теперь увидел ВЕСЬ пост, а то был кусок из 5 слов.

Ну пока чтона своих объектах я сам являюсь аварийной службой, даже если объект за 500 км. Удалённый доступ не использую в связи с:
1. Возможностью местного персонала перейти на ручное задание уставок (перевода ЧРП в ручной режим и режим задания требуего поддержания параметра с пульта ЧРП, и т.д.)
2. повсеместного использования резервирования оборудования.
3. Удалённое тестирование покажет лишь причину, даже начальник котельной (кстати, по образованию ветеринар), может рассказать по телефону суть происходящего, из чего причина ясна.
4. 3 года назад пытался на двух котельных, принадлежащих городским теплосетям, но находящихся в 20-ти км от города, сделать удалённую диспетчеризацию при условии создания одной бригады на 2 котельные. ООО "Гортеплосети" это не надо. Диспетчеризация на GPRS и Контар-Скада проработала, пока на СИМ-картах деньги не кончились.
5. Если у сервисных служб (допустим, меня), не будет допуска к оборудованию, то оно и работать не будет.

to ATX
Понимаю.
Это хорошо, когда причина ОЧЕВИДНА. Бывает и по-другому.
Все-таки хотелось услышать Ваше мнение по поводу удаленной диспетчеризации (не МОНИТОРИНГА) объектов? Критерий применимости, исходя из свойств объекта? Ну и вообще...
В соседней ветке привели критерии для КОНТАРА ( небольшие объекты и прочее).

Моё мнение, как разработчика подобных систем, очевидно: они нужны, их реализация экономит средства заказчику при строительстве и, особенно, дальнейшем обслуживании, эксплуатация самой системы диспетчеризации не требует специалистов суперквалификации, достаточно обычных эксплуатационников + обычный сисадмин при:
1. Монтаже объекта, не требующем дальнейшего обслуживания.
2. Переданной исполнительной документации, после прочтения которой Зак сможет обслуживать объект своими силами.
Критерии применимости: Удалённость объекта, возможность работы без постоянного присутствия обслуживающего персонала, наличие оборудования, сложного в обслуживании силами заказчика,
распределённость составных частей объекта в пространстве, наличие на объекте разнородных систем, но при обслуживании требующих одних и тех же специалистов энергоучастка (теплоснабжение, вентиляция, электрика, связь, ОПС).

На недавнем объекте мы предложили удаленный мониторинг, причем у них сегменты сети изолированны, доступ должен был быть к одному порту (CoDeSys) через vpn. Круче защиты не придумать Заказчик отказался - "Мне проще что бы вы прилетели (8 часов дорога от Москвы ), чем "кто-то" у нас там в сети копался". Но там военные рулят - перепуганные. Так что проблема не в технической реализации, а в головах в первую очередь.

P.S. Контроллер, к которуму планировался доступ, Wago 750-841.

Ну начнем с темы аутсорсинга. Промышленные предприятия на просторах нашей Родины дружными колонами движутся в этом направлении. Укрупняют и избавляются от ремонтных служб. Результаты как в анекдоте: "мыши плакали, кололись, но продолжали жрать кактус." Даже не касаясь особенностей технологий цехов и парка оборудования основной недостаток такой организации труда это: ВРЕМЯ РЕАГИРОВАНИЯ НА НЕИСПРАВНОСТЬ И ВРЕМЯ НА ЕЕ УСТРАНЕНИЯ. Как результат идет частичный откат к прежней организации труда - часть ремонтных служб стараются оставить в цехе. Ну это про ремонтников.
Об удаленной диспетчеризации: Бывал я тут на одном стекольном заводе. Общался с сотрудниками. Они и рассказали такую историю. РСУ у них обслуживает компания находящаяся в Польше. Завис один процессор, потом второй. И чего делать? Из специалистов одни технологи. Чип и Дейл далеко Печь останавливать? Проецируя на теплосети -при хорошем морозе за несколько часов будет обеспечен хороший объем работ для большого и дружного коллектива ремонтников, включая служащих МЧС.
Нам указывают на успешный опыт Европы, но там плотность производственных компаний на кв. км намного выше. И компания по обслуживанию с меньшей территории кормиться. И оборудование они стараются брать с ближайшего завода (чувствуете разницу по ремонтной базе и номенклатуре приборов) .
У нас (в целом по стране) с унификацией приборного парка вообще огромная проблема. Вы можете себе представить, что все предприятия региона договорятся брать одну модель очень хорошего прибора (контроллера, двигателя, насоса). Я представляю это только в случае если это сделает проектная организация и ей не будут выкручивать руки заказчики.
По поводу специалистов скажу только следующее. Для изучения особенностей технологий и оборудования специалисту
(именно так без сарказма) необходимо как минимум 1-2 года (срок зависит от масштабов и новизны производства). Если материально специалистов не удержать, то результаты будут плачевны в первую очередь для производства.

К вопросу о EAM.

EAM - оторванная от объекта, т.е. функционирующая offline - это бред, наблюдающийся в тех конторах, куда этого г* напихали манагеры от IT.
В действительности, это инструмент который позволяет сносно функционировать предприятию, даже в условиях текучки кадров.
В базе данных EAМ должна "ЖИТЬ" информация о фондах.
Т.е сервисная служба работает не с махровой калькой, а актуальной документацией, со всеми изменениями, дополнениями и историей.

EAM и прочие "приблуды" по эффективной организации управления производством имеют смысл при наличии двух (по крайней мере) условий :
1) наличие персонала, в том числе и управленцев верхнего уровня, УМЕЮЩЕГО ими пользоваться
2) единая структура документооборота предприятия
Я могу на эту тему "трындеть" долго, т.к. заработал на этих системах достаточно денег и язву в придачу. В России - это такое же баловство, как
и "умный дом".
Ладно, допустим что-то вдруг резко поменялось и эти все условия выполнены. Поекты АСУЗ выполняют РАЗНЫЕ фирмы, у каждой из них свои предпочтения в оборудовании и технологических решениях (природу предпочтений выведем за скобки). Имеем "зоопарк", который НИОДНОМУ производству не приснится даже в самом кошмарном сне. На производстве ВОЗМОЖНО влиять на выбор оборудования.
Вывод - если Зак хочет передать эксплуатацию АСК (АСК - АутСорсинговая Компания), то имеем следующие варианты:
1) АСК НАСТОЯТЕЛЬНО рекомендует фирмы и оборудование, к которыми она "привыкла" работать. Значит, либо подрядчик применяет данное оборудование и технологии, либо "идет лесом". Либо выбирается "нужный" подрядчик. Таким образом, имеем ЕЩЕ ОДНУ ИНСТАНЦИЮ, с которой надо что-то согласовывать, подрядчику - "откатывать", повышаем "ВЗЯТКОЕМКОСТЬ" проекта, его цену . Далее, все зависит от фантазии.
2) ЗАК выбирает АСК, работающую с выбранным оборудованием и, главное, знакомую с технологическими решениями Подрядчика.
Я с трудом представляю АСК, удовлетворяющую этим условиям. Правда, есть выход - сократить до МИНИМУМА количество Подрядчиков, например, оставить на МОСКВУ штук 10 (по количеству Административных округов). Правда, многие имеют "нехорошую привычку" работать и за пределами Москвы, но можно и поделить Россию на зоны влияния.
3) Стандартизовать ВСЕ - проектные решения, оборудование и т.д. Кто не попал в Реестр - "гнать взашей". ВЗЯТКОЕМКОСТЬ ОФИГЕННАЯ !!!
Так что, "куда ни кинь - везде клин". Конечно, могут быть и другие варианты.
В следующем посте попробую описать некоторые другие проблемы с реализацией идеи АСК.

Думаю, бардак, коррупция и зоопарк, который мы сейчас наблюдаем - явление временное, лет на 10 (кроме коррупции ))) ).
Привели ведь в порядок вертикальный транспорт.
Там и диспетчеризация, и EAM, и аутсорсные сервисные службы, и типовые проектные решения.
У нас же пока, рынок молодой, несложившийся, дикий.

Вот привел.
Интересно. Некоторые восприняли слова удаленный контроль, как вопросы телемеханики.
Может выкинуть из названия книги?
Или правильнее будет дистанционное управление?
Если "на пальцах" имхо, то выключатель на входе в с/у устройство дистанционного управления, а вот выключатель при входе в комнату не совсем.
Если можно управлять на щите, не важно посредством кнопок, панелей - то это скорее не дистанционно.
Если панель для включения и управления приточки , выведена на 1 этаж в холл - то это визуализация и дистанционное управление, сиречь удаленный контроль.

Теперь вернемся к теме:
3. Надо бы написать словарь терминов с комментариями.
4. Нужен список нормативных документов по теме, желательно с комментариями.
5. Нужен список литературы, желательно с комментариями.
6. Типовые проектные решения безусловно будут, но они обязательно будут привязаны к оборудованию... Как по другому?
Господа! А вам не кажется, что от книги немного отдалились...

Замените слово "удаленный" на слово "дистанционный" и непонятки пропадут. Удаленное управление у меня ассоциируется с существенным удалением т.е. десятки километров

Слово заменили, тему подняли...

К пукту 3 про определения терминов см. в приложении.
Потихоньку набирается авторский коллектив. Надеюсь скоро дать и об этом информацию.

А зачем архив то паролить...Глянуть то хотца

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

Сказка про белого бычка получается... Как я могу вам чем то помочь, если я не видел что делают остальные
Желание помочь есть.

Пароль дал и пропал человек...

Сорь, не пропал...
Работы много, за комп сесть некогда...

Ну и славно. Понимаю. Гоню всякие ч. мысли и ждем.

50 человек скачало. Один попросил пароль. Нормально пошла...
Ну вот пока тогда быль...

Цифровой томик

Советник президента России Леонид Рейман написал книгу "На пути к цифровому дому", которая пополнила библиотеку Института современного развития. Книга призвана помочь обществу освоиться в мире высоких технологий.
Материал для книги Рейман начал собирать еще будучи министром информационных технологий и связи. А вот обобщить и интегрировать его в законченное произведение удалось лишь после перехода на пост советника президента. "Времени стало больше, - пошутил Леонид Рейман на встрече с журналистами. - Для того чтобы построить что-то законченное, нужно сначала хорошо это спланировать".
По словам Леонида Реймана, написание книги помогает систематизировать в голове множество знаний. Книга "На пути к цифровому дому" призвана помочь освоиться в мире высоких технологий жителям даже самых отдаленных уголков России. "В частности, там раскрываются понятия "умный дом", "телемедицина", цифровое неравенство", - говорит Леонид Рейман. - Она поможет людям поудобнее устроиться в информационном обществе. За счет этого и экономика России станет более конкурентоспособной".
Пока книга выпущена ограниченным тиражом, но она поступит в свободную продажу. В случае если издание будет пользоваться спросом, выйдут дополнительные тиражи.
"В отличие от западных, наши лидеры IT-компаний очень любят критиковать, как можно сделать по-другому, как было бы лучше, но когда спрашиваешь, что конкретно нужно изменить - молчат, - отметил депутат Государственной Думы Илья Пономарев. - Эта первый раз, когда книга выражает видение автора, взгляд в будущее, на то, как должно развиваться информационное общество".
На презентации книги Рейману предложили приняться за следующее произведение, в котором уделить внимание развитию ИТ-бизнеса в условиях кризиса. "На западе подобные книги пишут руководители ведущих IT-компаний, накопившие достаточно опыта и знаний в описываемой сфере, - отметил исполнительный директор ассоциации АП КИТ Николай Комлев. - У нас пока такой практики нет. Это "первая ласточка". Но в будущем, скорее всего, подобных изданий станет больше".
27 февраля 2009 Источник новости: comnews.ru

* Какой советник напишет "ласточку" про автоматизацию зданий? Пора бы.

Доброго времени суток уважаемые!
Накидал тут "рыбу" под содержание, правда немного, но если я ее сейчас не выложу, могу опять замотаться. Тогда написание книги будет не долгим, а очень долгим.

To Pasekov.
Я там накидал только по диспетчеризации, все тоже самое можно и для остальных разделов сделать. Можно начать обсуждать, тогда и содержание подрастет


И...ё моё, вычисти свой личный почтовый ящик на форуме, я тебе этот файл уже неделю скидывать пытаюсь.
Пароль тот же.

А мне пароль получить можно?
Я не волшебник, я только учусь.
Многое о чем пишите предстоит узнать, но хочется учиться не на своих ошибках.

Pasekov, а ты обижалси...
смотри, второй ужо пароль просит

Нихкто не обижалси.. Варанье...
Скидывай Snorri пароль, и мне тоже... пока ждал тебя сам потерял...

Во, дожили
Держите пароль *******

Не дожили, а живем...
Даже шутим...
Snorri получил от Вас пароль?

Snorry пароль получил.
Владимир, осторожно интересуюсь насчет приготовленных помидор за столь малое содержание.

Snorri пароль получил... только архивы найти не могу

А нафига запаролили то? Ищ тайна мадридского двора.

Паролим шоб нал нами не смеялись

А Вы меньше слушайте тех кто смеется, потому как сказано: "Не ошибается тот, кто ничего не делает"

так пароль для того и нужен, чтобы разрешили посмеяться или нет... если знаний хватит.

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

Сделать то можно, вот только зачем???

Присоединяюсь.

Зачем???
Да у нас своего ничего не осталось!
Продай газ, лес, нефть.. и купи оборудование.
Мы то хоть чего-нибудь технологичное делаем или только "отвертками крутим"?

Отечественный стандарт создавать надо. Не для того, чтобы поддержать отечественного производителя (ругают всех производителей и хонивел, и данфосс, и Овен, и остальных).
Отечественные средства обойдутся дешевле при тепершнем кризисе - это имеет значение.
Второе, можно использовать Windows (Eng) для работы, но Windows(Rus) все таки приятнее.
В настоящее время рекомендуются тендеры, чтобы обеспечить возможность выбора потребителю.
И последнее конкуренция - двигатель качества независимо от страны производителя. Применение отечественных средств - может повлиять и на зарубежных производителей.

Изобретение велосипеда в 21 веке ничем хорошим не закончится, особенно при наличии массы готовых решений.

Существование готового языка Бейсик не предотвратило появление языков Perl, Си, Делфи.

Как не предотвратило наличие массы стандартных протоколов передачи данных рождение совецких кривобоких протоколов "на базе RS-485".
З. Ы. Вы правда не понимаете о чем я говорю или прикидываетесь?

Не понимаю, что надо понять.
Достоверность передачи данных обеспечивается :
1. надежностью кодирования информации
2. частотой запросов
и всё !
Если необходима интеграция оборудования в системы верхнего уровня необходим OPC, производитель должен его предоставить.
Если используется самопал-Bus, который обеспечивает достоверность передачи данных в чем проблема? Закрытый протокол - это внутренние проблемы производителя, имеет полное право его применять.
Советский это протокол или антисоветский дело десятое, если обеспечана достоверность передачи информации.

1. Из-за самопальных протоколов к верхнему уровню приходится тянуть не один кабель, а несколько, для каждого нестандартного протокола свой. Иногда такой возможности просто нет. Например, при удаленном доступе к оборудованию через какой-то канал связи.

2. Интеграция бывает нужна на нижнем, а не на верхнем уровне, поддержка нестандартных протоколов в этом случае требует дополнительных расходов. Тогда как для стандартных протоколов достаточно подобрать контроллер, который этот протокол знает.

В общем, чтобы самопальный протокол оставался внутренней проблемой производителя, а не стал моей, этот производитель может быть посылан далеко.