Книга: Дистанционный контроль, визуализация и диспетчеризация инженерных систем здания, Бестселлер АСУЗ Опции

[Pasekov]

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

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

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

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

[Pasekov]

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

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

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

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

[Гость_ggg__ggg_*]

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

Сообщение отредактировал ggg__ggg - 20.1.2009, 20:35

[AlexG]

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

[Гость_ggg__ggg_*]

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

[elexm]

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

[ProjectM]

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

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

[GYUR22]

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

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

[Гость_ggg__ggg_*]

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

Сообщение отредактировал ggg__ggg - 22.1.2009, 6:08

[Гость_АТХ_*]

То ggg__ggg:

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

Сообщение отредактировал АТХ - 22.1.2009, 7:01

[Гость_ggg__ggg_*]

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

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

[Гость_АТХ_*]

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

[Гость_ggg__ggg_*]

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

[Гость_АТХ_*]

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

[Abysmo]

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

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

[libra]

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

[ProjectM]

К вопросу о EAM.

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

[Гость_ggg__ggg_*]

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

[ProjectM]

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

[Pasekov]

В другой ветке я пытался дать определение "удаленному доступу"....

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

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

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

[Сергей Долганов]

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

[Pasekov]

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

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

[Pasekov]

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

Прикрепленные файлы

 Определение_терминов.rar ( 4,34 килобайт ) Кол-во скачиваний: 413

 

[Akirra]

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

[Pasekov]

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

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

[Akirra]

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

Сообщение отредактировал Akirra - 11.2.2009, 18:43

[Pasekov]

... если я не видел что делают остальные
Желание помочь есть.

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

[Akirra]

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

[Pasekov]

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

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

[Pasekov]

К пукту 3 про определения терминов см. в приложении.

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

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

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

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

[Akirra]

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

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


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

Прикрепленные файлы

 Рыбаподсодержаниекниги.rar ( 2,93 килобайт ) Кол-во скачиваний: 320

 

[Гость_Snorri_*]

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

[Akirra]

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

[Pasekov]

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

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

[Akirra]

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

[Pasekov]

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

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

[Akirra]

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

[Гость_Snorri_*]

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

[Сергей Долганов]

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

[Akirra]

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

[Сергей Долганов]

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

[Гость_Snorri_*]

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

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

[AlexG]

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

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

[Сергей Долганов]

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

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

[Гость_Snorri_*]

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

[elexm]

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

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

[Сергей Долганов]

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

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

[elexm]

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

[Сергей Долганов]

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

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

Сообщение отредактировал Сергей Долганов - 20.3.2009, 10:30

[elexm]

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

[AlexG]

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

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

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

[elexm]

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

Из этих примеров вытекает ответ на вопрос :

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

Зачем нужен единый протокол назовем к примеру Modbus Rus.
Чтобы свести к минимуму количество нестандартных протоколов.

[AlexG]

Из этих примеров вытекает ответ на вопрос :

Зачем нужен единый протокол назовем к примеру Modbus Rus.
Чтобы свести к минимуму количество нестандартных протоколов.

Вот только вопрос был риторическим и вообще о другом.

Чтобы свести к минимуму количество нестандартных протоколов для начала надо прекратить их плодить.

[elexm]

Чтобы прекратить плодить, нужен единый протокол.

[Сергей Долганов]

Зачем нужен единый протокол назовем к примеру Modbus Rus.
Чтобы свести к минимуму количество нестандартных протоколов.

Вот это меня в отечественном народе потрясает больше всего. Зачем делать модбас рус если есть модбас просто?

[elexm]

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

[AlexG]

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

[elexm]

2. Перечисленные проблемы Модбаса мне прекрасно известны, также как и варианты их решения. Есть проблемы и посерьезнее.

Например какие проблемы ?
А если есть варианты решения проблем Модбаса помогите, человек ищет :
Тема: RS-485 и Ethernet. Прозрачная замена кабельной линии.

[HelenASU]

Для Pasekov и Akirra. Дайте, пожалуйста пароли для "терминов" и "содержания". Очень хочется быть в теме.

[GYUR22]

Хе Хе
уже придуман общий протокол для всего BACnet называется (шютка )
На самом деле куча разных протоколов дает хлеб создателям OPC и Gateway так что ж вы его хотите отнять ?

[Сергей Долганов]

Ничего не хотят отнять, хотят опять развести песню про "особый Русский путь". Потратить миллионы денег, набить кучу шишек и выпустить в конце концов устаревший к моменту выхода протокол.
Догонять, товарищи, легче с середины дистанции а не от старта.

[Kass]

Из этих примеров вытекает ответ на вопрос :

Зачем нужен единый протокол назовем к примеру Modbus Rus.
Чтобы свести к минимуму количество нестандартных протоколов.

Даже если кто то опубликует свой протокол как Modbus Rus, то остальные производители объявят ему войну.
Вся беда в нашем менталитете. Мы зачастую воспринимаем соседей по бизнесу как конкурентов, как врагов, а не компаньонов и друзей.
Поэтому поливание грязью вполне заменяют партнерские отношения.
Поливание грязью всего отечественного теми, кто что то лепит на зарубежном приводит к тому, что и все оборудование и проект и автоматику заказывают зарубежом. Зачем заказывать у местных кустарей, если они сами говорят, что в России ничего нормального не сделать. Поэтому в последнее время множество объектов переделываем за югославами, итальянцами и т.п.

Наши российские протоколы давно существуют. К чему изобретать велосипед? Более того, совместными усилиями людей, способных на партнерские отношения и сотрудничество мы распространяем эти протоколы среди российских и зарубежных производителей для их реализации. Обсуждать это здесь бессмысленно. Война вспыхнет. Каждый с пеной у рта будет отстаивать какой то буржуйский бренд, как свой собственный.

[elexm]

Вся беда в нашем менталитете. Мы зачастую воспринимаем соседей по бизнесу как конкурентов, как врагов, а не компаньонов и друзей.
Поэтому поливание грязью вполне заменяют партнерские отношения.
Поливание грязью всего отечественного теми, кто что то лепит на зарубежном приводит к тому, что и все оборудование и проект и автоматику заказывают зарубежом.
Каждый с пеной у рта будет отстаивать какой то буржуйский бренд, как свой собственный.

+120 Абсолютно согласен. /с возвращением г.Kass/.
Только, если копнуть историю, можно вспомнить, что производители принтеров ставили различные разъемы продвигая свою продукцию.
И только "центроникс" положил конец безпределу.

[Pasekov]

Наши российские протоколы давно существуют. К чему изобретать велосипед? Более того, совместными усилиями людей, способных на партнерские отношения и сотрудничество мы распространяем эти протоколы среди российских и зарубежных производителей для их реализации. Обсуждать это здесь бессмысленно. Война вспыхнет. Каждый с пеной у рта будет отстаивать какой то буржуйский бренд, как свой собственный.

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

[soliton-ua]

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

Тема весьма интересная. Но, как и все hi-tech темы и направления развивается настолько стремительно, что к выходу книги поизойдет смена поколения оборудования/протоколов/решений.
Например, мы помогали партнерам в подготовке книги по вентиляции и кондиционированию воздуха в части автоматизации и диспетчеризации. Прошло 5 лет после выхода книги, базовые технологии сохранились, но обновилась линейка контроллеров, ПО системы диспетчерзации, вместо DDE основные производители используют OPC сервера.

Я задавал вопрос инженерам (из компании - производителя коммуникационного оборудования для промышленных сетей Ethernet, Тайвань) о цикле производства - от идеи до готового продукта. Ответ - не более 9 месяцев, иначе не будет перспектив для продаж. За год интенсивно продвинулись направления по PoE, IP видеонаблюдению, WiMax.

Производители контроллеров и систем для зданий, конечно-же более инерционны. Линейка продукции обновляется каждые в 3-5 лет. Но все-таки решения по удаленной диспетчеризации связаны больше с коммуникационными технологиями и решениями. Все таки - интерес в том, чтобы книга стала коммерческим продуктом, или информационным ресурсом? Если второе - то, наверно, лучше, чтобы это был обновляемый интернет-ресурс.

Относительно проблем информационной безопасности при удаленной диспетчеризации - это общая проблема информационных систем и решается теми-же средствами.
Один из плюсов таких систем - удаленное рабочее место для специалистов, чья квалификация в части СУЗ выше, чем квалификация персонала службы эксплуатации здания.
В Москве наш клиент успешно эксплуатирует три офисных здания, подключенные через телефонные модемы с относительно старенькой системой BMS.
Наши колллеги из Германии делились опытом проектов единой системы по диспетчеризации десятков зданий в разных городах. И никого не пугает подключение к сети internet, как наши "продвинутые" службы Заказчиков. Некоторые компании, удаленно сервисующие здания, получая только проценты от экономии энергоносителей, чувствуют себя весьма неплохо. Наши партнеры предоставляют доступ к серверам систем диспетчеризации городских теплопунктов и котельных как услугу для городских коммунальных служб.

Наверно утомил народ своим флером , но тема действительно перспективная.
Владимиру - удачи.

[Pasekov]

Тема весьма интересная. Но, как и все hi-tech темы и направления развивается настолько стремительно, что к выходу книги поизойдет смена поколения оборудования/протоколов/решений.

Значит книгу надо писать быстрее. Контроллеры сменятся, а идеология построения сетей останется, общий подход. Да и сами стандартные протоколы так быстро не меняются.

Производители контроллеров и систем для зданий, конечно-же более инерционны. Линейка продукции обновляется каждые в 3-5 лет. Но все-таки решения по удаленной диспетчеризации связаны больше с коммуникационными технологиями и решениями. Все таки - интерес в том, чтобы книга стала коммерческим продуктом, или информационным ресурсом? Если второе - то, наверно, лучше, чтобы это был обновляемый интернет-ресурс.

У меня цифры большие до 7 лет. Да и ПО последнее время имеет тенденцию к увеличению срока. Коммерческая составляющая не просматривается. идея "Большого" интернет-ресурса витает в воздухе. А Книга - должна быть книгой. Ксати, мне кажется, что правильнее эту тему осветить в трех главах большой книге об автоматизации зданий.

Относительно проблем информационной безопасности при удаленной диспетчеризации - это общая проблема информационных систем и решается теми-же средствами.
Один из плюсов таких систем - удаленное рабочее место для специалистов, чья квалификация в части СУЗ выше, чем квалификация персонала службы эксплуатации здания.
В Москве наш клиент успешно эксплуатирует три офисных здания, подключенные через телефонные модемы с относительно старенькой системой BMS.

Полностью согласен.

Наверно утомил народ своим флером , но тема действительно перспективная.
Владимиру - удачи.

Мне кажется, это лучший пост в теме. За пожелания - СПАСИБО!

[Skif_Sib]

Я вот отвечу. Не сочкану.

По поводу отчества (отечественные контроллеры, датчики, исп.мех-мы и т.д и т.п.) - хочу сказать, что только с внедрением (обязательным) систем диспетчеризации, использование НАШИХ контроллеров стало более безопасным.
По опыту - помню (никогда не забуду) как дежурили на одном ЦТП года 3 назад при наладке АСУ, 72 часа испытаний. Помню, как до этого "посадили" по давлению строящийся дом - и всю медь разорвало (на улице было -20 чтоли) в 10 этажном доме. Это проектировщики составили винегрет: Минитерм (лично подбирал параметры ПИД-регулирования), ECL Danfoss, частотники Danfoss, а более не помню, но много чего было.
К чему я - ранее ставили мы эти ECL Danfoss, настраивали и забывали - ну что может там сломаться? А поставишь наш ОВЕН - и душенька болит, неспокойно... Случалось то с нашей техникой разное и самое неожижанное. А контроля на месте не было. Поэтому НАШИ ставили редко, чаще буржуйные.
Но! Рынок и так нужно расширять - сколько объектов ждут своих героев, а тут еще и кризис - как снизить цену решения?

Ответ ВСЁ НАШЕ + диспетчеризация.

Поставил наши контроллеры, датчики, исп. механизмы - вывел в СКАДУ к главному инженеру - и эксплуатируй. Запал клапан - дом не "встанет" - аларм диспетчеру. Что-нибудь случилось (что с буржуйными не случается) - всё диспетчеру Аларм.

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

Мы так делаем и мне не страшно теперь. Я перестал плеваться при упоминании нашегвсого девайса.

P.S. В Кузбассе не до разносолов.

[CHANt]

По поводу отчества (отечественные контроллеры, датчики, исп.мех-мы и т.д и т.п.) - хочу сказать, что только с внедрением (обязательным) систем диспетчеризации, использование НАШИХ контроллеров стало более безопасным.

Эксплуатационный персонал должен работать и грамотным быть! Зачастую, на объекте, полупьяные киповцы, чистя селедку на комплекте чертежей системы автоматизации, "вспоминают" чегой то они там, три года назад копались в цепях управления...Такое отношение к работе сводит на нет любые преимущества систем, присутствует диспетчеризация или нет, импортный контроллер или отечественный.

[тихий инженер]

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

[Skif_Sib]

2 CHANt:
Гм... Молодой человек, если честно, то я не понял пассаж про киповцев, селедку и наставление на путь истинный . Это относитя ко мне лично? В вашем выпаде нет ни строчки по теме. Может не моняли меня? Почитайте еще раз - я писал о том, что 3 года назад (точнее- 5 лет) отложился у меняф в сознании факт, что от нашего оборудования - только головная боль, проблемы и ор заказчика.
Тогда я не принимал решения в подборе оборудования, а когда стал сам проектировать АСУ - то старался обходить НАШЕ сторной. И только теперь (с массовым внедрением Дистанционного контроля, визуализации и диспетчеризации инженерных систем здания) решение об установке на тот или иной объет нашего оборудования кажется мне менее сомнительным.
Если вас так беспокоят пьяные КИПовцы - заведите ветку - "влияние пьяных киповцев на устойчивость АСУ ТП".

[CHANt]

Может не моняли меня? Почитайте еще раз - я писал о том, что 3 года назад (точнее- 5 лет) отложился у меняф в сознании факт, что от нашего оборудования - только головная боль, проблемы и ор заказчика.
Тогда я не принимал решения в подборе оборудования, а когда стал сам проектировать АСУ - то старался обходить НАШЕ сторной. И только теперь (с массовым внедрением Дистанционного контроля, визуализации и диспетчеризации инженерных систем здания) решение об установке на тот или иной объет нашего оборудования кажется мне менее сомнительным.

Я понял Вас, и не согласен с Вашим мнением. Считаю, что диспетчеризация не является панацеей от всех бед. Длительная и успешная работа систем автоматики зависит как от проектных решений, так и последующего текущего обслуживания, своевременных ремонтов, наличия у эксплуатанта соответствующих квалифицированных специалистов. Не мешало бы, чтобы горе топ-менеджеры и ресурсы выделяли для проведения ТОРО... В противном случае, через короткий промежуток времени, все превращается в груду хлама, и как Вы выражаетесь в "ор заказчика". В последнее время достаточно много предприятий разработчиков, исходя из конкретных условий, стараются взять на сопровождение свои системы, обеспечивая таким образом нормальные условия эксплуатации.

Гм... Молодой человек, если честно, то я не понял пассаж про киповцев, селедку и наставление на путь истинный . Это относитя ко мне лично?
...Если вас так беспокоят пьяные КИПовцы - заведите ветку - "влияние пьяных киповцев на устойчивость АСУ ТП".

Не надо додумывать то, чего не было сказано. А раз избрали назидательный тон, то просветите дилетанта, к примеру, как Вы разрабатываете организационное обеспечение при проектировании АСУ, что включаете, на что обращаете внимание в документации в большей степени. Если Вас не затруднит.

[Pasekov]

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

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

как Вы разрабатываете организационное обеспечение при проектировании АСУ, что включаете, на что обращаете внимание в документации в большей степени.

Вот и меня это интересует, чтобы потом ВСЕМ рассказать. Причем собрать разные точки зрения. Лучше с примерами. Тогда читатель сам сможет разобраться.

[kdu]

ещё одна жаркая тема ни о чём для желающих попи...еть ни о чём! Ну и как ребята, хоть 1 предложение своей "книги" написали???? Тема - явный кандидат в мусорку...
Давайте ещё создадим тему - "удачные конструкции вечного двигателя 1-го рода и рассуждения о нём" Буэ!!!

[Pasekov]

...Тема - явный кандидат в мусорку...

Согласен! Написать одно предложение в книгу, сложнее указания отправить тему в мусорку.

[Гость_Председатель_*]

Доброе время суток!
ПРошу помочь!
Необходимо для обслуживания Подробное техническое описание
программы диспетчеризации - Excel Building Supervisor (Honeywell)
Прошу рассказать про возможные заморочки

СПАСИБО

[Jenka]

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

[Pasekov]

1. И тема заглохла...
2....где книга то?
3. Смените название на: "как объяснить заказчику необходимость диспечеризации", будет иметь успех.
4.. и в принципе не важно, будет эта книга современной или нет, если она будет понятной обычному человеку без специального образования.
5. Самым лучшим вариантом будет книга написанная вместе с производителем(ями) оборудования.

Спасибо за пост.
1. Так тоже бывает.
2. Так авторов даже не набралось. Что-то никто не захотел бесплатно писать, а возможные спонсоры тоже активность не проявили. Но время не прошло даром (см. ниже).
3. Интересный поворот, но скорее всего правильный. Вот второй день размышляю над вашей этой мыслью.
4. Вот. Надо писать именно так. Согласен. Из трех моих рассылок по автоматизации зданий самой большой популярностью пользуется «Автоматизация зданий для Дилетантов». В короткой аннотации к ней говорится о возможности простым языком и без рекламы рассказывать об автоматизации зданий.
С 11 февраля прошлого года вышло 23 выпуска (хотя и был большой вынужденный перерыв). Из этих выпусков требуемую книгу, конечно, не составишь, но я получил опыт, который мало у кого на сегодня имеется. Кстати, и других авторов привлекал.
5. Выскажу имхо. Пока из китов (Siemens, Honeywell, JCI и Schneider Electric) никто не написал на русском языке ничего подобного. Вопрос:"Почему?" Ответ может выйти не совсем политкорректным. Хотя мысль привлечь именно производителей, а не крупных интеграторов тоже весьма интересна и смысла не лишена.
Но на этом форуме специалисты-интеграторы бывают, а вот из производителей почти никого и нет.

[Гость_free-lexx_*]

Я создал тему с запросом об открытии WIKI по автоматизации в рамках данного сайта. ИМХО это имеет много преимуществ перед бумажной книгой. Перечислю причины, которые первым делом приходят на ум:

1. Большинство заморочек с организацией процесса написания отпадают, такие как: обеспечение согласованности авторов между собой и сведение воедино их текстов.
2. Актуальность информации поддерживается постоянно и не надо переиздвавать книгу
3. Простота добавления сведений. Так, например, если человек решил внести свой вклад в дело в виде одного предложения, то ему не надо просить кого-то внести это предложение, объяснять куда внести и пр.
4. Доступность информации на порядок (а может и больше) выше, чем с книгой.

[Гость_free-lexx_*]

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

Если на создание WIKI на этом сайте откажут, то можно создать отдельный ресурс. При отсутствии спонсора можно за бесплатно создать ресурс с доменным именем второго уровня.

[Pasekov]

Я создал тему с запросом об открытии WIKI по автоматизации в рамках данного сайта. Перечислю причины...

А кому этот запрос был адресован?
Если просто тема, то скорее всего темой и останется. Как, например, с этой книгой.
Идея ваша не плоха, хорошо, если поддержат.
Но книга в бумажном виде все равно нужна. Просто, начав с WIKI, потом можно будет отредактировав материал сделать книгу.
Я за!!!

[Ludvig]

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

Сообщение отредактировал Ludvig - 28.5.2010, 16:15

[Pasekov]

Книга, как источник знаний, конечно нужна....

Как-то не очень хочется подводить отрицательный итог началу этой темы. Полагаю, что и так многим все понятно.
Поэтому попробуем с "другой стороны зайти".
Что такое книга? С одной стороны - это набор хорошего материала, структурированного и обобщенного одной темой. С другой - работа команды и некий бизнес процесс. Эта вторая сторона пока явно не работает.
Но тема ясна - АСУЗ и смежные вопросы, как их не называй. Актуальность только растет, причем в разных кругах.
Может стоит поискать нормальные статьи и привлечь этот материал и их авторов в книгу?
Задача не очень простая, но для всего коллектива форума подъемная.
При нахождении любой стоящей статьи требуется просто сообщить о ней или прислать ссылку и т.п.
Глядишь и начнет собираться материал, а уж обработать я смогу.

[Palsan]

Задача конечно хорошая, но Вы сразу отвергли IP и GSM каналы, хотя сейчас при их помощи можно мониторить что угодно в любой точке где есть связь.
Здесь надо начать с прикладной теории управления: объекты, субьекты управления, способ управления, каналы связи (управления), виды обратных связей, уровни управления, иерархические структуры, способы отображения информации, методы повышения точности, устойчивости и т.п.
После этого подводить элементную базу, типовые задачи и типовые решения.
Контроль банкомата, управление насосами и счетчик на конвейере это достаточно разные системы, но объединены одной теорией, а значит возможна их интеграция.

[Pasekov]

1...но Вы сразу отвергли IP и GSM каналы, хотя сейчас при их помощи можно мониторить что угодно в любой точке где есть связь.
2. Здесь надо начать с прикладной теории управления: объекты, субьекты управления, способ управления, каналы связи (управления), виды обратных связей, уровни управления, иерархические структуры, способы отображения информации, методы повышения точности, устойчивости и т.п.
3. После этого подводить элементную базу, типовые задачи и типовые решения.
4. Контроль банкомата, управление насосами и счетчик на конвейере это достаточно разные системы, но объединены одной теорией, а значит возможна их интеграция.

Уважаемый Palsan!
1. С чего Вы взяли, что IP и GSM отвергнуты?
2. А может с прикладной задачи? Учебники АСУ есть, но не по зданиям и сооружениям.
3. Такая схема для производителя хороша, а для пользователей? Писать, например, что ОВЕН подходит для всего?
4. Все так, но интеграция в здание обусловлена не только единой теорией. В АСУЗ скорее надо несколько сместить акцент подачи материала.

[Andrew771]

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

Если на создание WIKI на этом сайте откажут, то можно создать отдельный ресурс. При отсутствии спонсора можно за бесплатно создать ресурс с доменным именем второго уровня.

Давайте WIKI создадим. Кто это умеет делать? А дальше все, кто хочет, будут там писать по возможности. Это пока самое реальное.

[Pasekov]

Давайте WIKI создадим. Кто это умеет делать? А дальше все, кто хочет, будут там писать по возможности. Это пока самое реальное.

Не вопрос. Wiki сделать можно. Я и сам немного разберусь.
Проблема в другом. Как отсюда перекинуть ресурсы готовых писать на Wiki? Как им сообщить об этом?
Не реально писать всем в почту. А общее объявление на форуме будет воспринято как реклама другого ресурса со всеми вытекающими неприятностями....

[Andrew771]

Первые люди придут туда, а потом по сарафанному радио и гуглю
Тем более, не собирается же Вики становиться конкурентом.

Сообщение отредактировал Andrew771 - 6.9.2011, 15:42

[Pasekov]

Первые люди придут туда, а потом по сарафанному радио и гуглю
Тем более, не собирается же Вики становиться конкурентом.

Где я написал, что Вики может стать конкурентом? Я-то считаю наоборот, но пардон, не все так считают.
Даже не намекаю, кто может так "подумать"...
Сарафанное радио и гугль - это здорово, вот только непонятно как "первые люди придут туда"?

[Andrew771]

вот только непонятно как "первые люди придут туда"?

Через личку можно пригласить, кто отзовется тут.

[yuriytyu]

Не вопрос. Wiki сделать можно. Я и сам немного разберусь.
Проблема в другом. Как отсюда перекинуть ресурсы готовых писать на Wiki? Как им сообщить об этом?
Не реально писать всем в почту. А общее объявление на форуме будет воспринято как реклама другого ресурса со всеми вытекающими неприятностями....

такой вопрос, а нельзя как-то прям на форуме образовать WIKIingenering?
совместить движки или интерфейсы в одном сайте авока, а не делать второй
не разбираюсь в этом, просто спрашиваю

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

если я с другой оперой влез, то извиняюсь, не прочитал тему полностью

Где я написал, что Вики может стать конкурентом? Я-то считаю наоборот, но пардон, не все так считают.
Даже не намекаю, кто может так "подумать"...
Сарафанное радио и гугль - это здорово, вот только непонятно как "первые люди придут туда"?

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

Сообщение отредактировал yuriytyu - 16.9.2011, 13:35

[Andrew771]

надо бы как-то тогда обсужденные здесь вопросы подытоживать, делать сводку - потом выкладывать,
с годами справочник вырастет

да, это наверно даже лучше, чем просто Вики.

[nukanaka]

Всем здрасти! Авторы, так держать!
Очень полезное дело вы задумали! Думаю что не только я буду благодарен, но и тысячи тысяч людей!
Интересует как обстоят дела с ресурсом? или с книгой? ссылки какие-нибудь есть?

[Aurelius Marcus]

...... как обстоят дела с ресурсом? или с книгой?

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

[Ludvig]

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

Книга на примерах в области цифровой обработки сигналов, радиоэлектроники, компьютерных измерений и автоматизации эксперимента, электродинамики и распространения радиоволн демонстрирует возможности LabVIEW как среды программирования. Большая часть примеров в книге строится по принципу «от простого к сложному», который уже доказал свою эффективность на курсах изучения LabVIEW.

Разделы книги:
Введение
Работа в среде LabVIEW
Цифровая обработка и генерация сигналов в среде LabVIEW
Автоматизация процессов измерения, контроля и управления. Аппаратные и программные средства ввода-вывода данных
Дистанционный учебный и научный эксперимент с использованием LabVIEW
Виртуальный практикум в лаборатории электродинамики
Виртуальный практикум в лаборатории распространения радиоволн
Научные исследования и эксперимент в среде LabVIEW
Список литературы

качать по ссылке тут
Висеть будет до 6 августа + 5 дней за каждое скачивание. Кто не успел, тот качает в другом месте.

Сообщение отредактировал Ludvig - 1.8.2013, 22:50

[Andrew771]

На сегодняшний день лучшей современной книгой по автоматизации для меня является - Е.С.Бондарь, А.С.Гордиенко, В.А.Михайлов, Г.В.Нимич. Автоматизация систем вентиляции и кондиционирования воздуха. 2005. Жалко, что она только по вентиляции и кондиционированию.
А по оформлению проектов автоматизации - Клюев, Глазов, Дубровский, Клюев. Проектирование систем автоматизации технологических процессов. 1990.

Лучше уже и не напишешь. Если только скрестить их вместе и добавить автоматизацию других инженерных систем: тепловые пункты, холодильные центры и т.д.

[zova]

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

[Quasar]

...а никак не обстоят, нет Пасекова, и не будет уже никогда..

Сергей, не могли бы Вы пояснить это сообщение? Я правильно понял про "ТАМ"?...

[Nomen]

Сергей, не могли бы Вы пояснить это сообщение? Я правильно понял про "ТАМ"?...

Умер Владимир Пасеков. Уж 4 года тому. Вся надежда на его брата - Михаила!..

Алексей К.

[Dmr]

Вот такую штуку сделали для 68 ИТП жилых домов и 1 котельная в системе. Очень много чего еще предстоит сделать, но работает уже с 2015 года.
http://npu-scart.ru/images/АРМ_17.06.2019_H.mp4

[GURU_RU]

Not Found
The requested URL /images/АРМ_17.06.2019_H.mp4 was not found on this server.

[Dmr]

Not Found
The requested URL /images/АРМ_17.06.2019_H.mp4 was not found on this server.

Вот новая ссылка: http://npu-scart.ru/index.php/software-dev.../remote-control