И снова интеллект

• А все-таки, зачем и как?
• Есть ли у вас план?
• Архитектура сети контроллеров
• Заключение

А все-таки, зачем и как?

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

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

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

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

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

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

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

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

Как мы уже отметили, с технической точки зрения все три задачи связаны между собой (cм. Рисунок 1). В то же время с организационной точки зрения они могут в определенной степени вступать в противоречие друг с другом. Например, обеспечение режима безопасности в здании может вступать в конфликт с требованием простоты перемещений сотрудников внутри него. Таким образом, заказчику необходимо взвесить все "за" и "против" для нахождения разумного баланса между требованиями к зданию.

Начать анализ следует с первой сформулированной нами задачи — сокращения затрат на эксплуатацию, потому как именно она является экономическим обоснованием для реализации сложного и дорогостоящего (с точки зрения начальной стоимости) проекта.

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

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

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

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

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

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

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

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

Всего существует три основные модели: ДЕЛЬТА - однофазный счетчик для потребительского сектора (ориентировочная стоимость около 200 долларов), трехфазный счетчик АЛЬФА, предназначенный для зданий (ориентировочная стоимость около 500 долларов), и ЕвроАЛЬФА - устройство уровня подстанции. (Любопытно, что первые два счетчика даже имеют характерные для России размеры - они выполнены в форм-факторе блока пакетников и традиционном круглом соответственно.) Счетчики ABB снабжены цифровым выходом, а также имеют собственную память для хранения графика нагрузки за определенный период, что обеспечивает сохранность информации в случае потери связи, а также сохранение содержимого оперативной памяти при перебоях в электропитании. Счетчики не являются просто электронными аналогами установленных в наших щитках устройств, так как помимо расходуемых киловатт они учитывают и все особенности потребления энергии, в частности такие параметры, как активная и реактивная энергия. Новые версии устройств, выпуск которых намечен на эту осень, должны будут предоставлять пользователям максимально полную информацию о параметрах потребляемой энергии, включая колебания напряжения, тока, частоты и сдвига фазы. Знание полной картины потребления энергии позволит как делать организационные выводы в отношении принимаемых внутри компании мер, так и вести аргументированный диалог с энергетиками, если вы считаете, что платите больше, чем следует.

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

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

Есть ли у вас план?

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

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

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

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

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

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

Технически такая ситуация обрабатывается просто - системе задается период длительности события, например 10–15 минут, и если оно завершается раньше, чем он истечет, то система на него никак не реагирует, т. е. событие считается как бы и не произошедшим. Соответственно, как-то надо оценить время, в течение которого систему не стоит выводить из режима энергосбережения, а также каким-то образом знать, что человек засидится. С другой стороны, у помещения есть тепловая инерция, поэтому переход на энергосберегающий режим можно начать и до того, как человек уйдет.

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

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

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

Архитектура сети контроллеров

В предыдущем обзоре, в разделе, посвященном техническим решениям для ИЗ, мы рассказывали о концепции интеллектуальных контроллеров. Поскольку обзор был достаточно общий, мы не затрагивали сути различных современных архитектур сетей интеллектуальных контроллеров. Пробел этот следует восполнить, тем более что все акценты тогда не были расставлены.

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

Такой взгляд демонстрирует, как инерция человеческого мышления может привести к неправильному решению. Замыкая весь процесс обработки информации и принятия решений на один компьютер, мы заметно снижаем надежность системы (cм. Рисунок 2а), так как в случае отказа компьютера или обрыва сетевого соединения она полностью выходит из-под контроля. В лучшем случае это приведет к изрядным неудобствам, в худшем - к аварийной ситуации.

Интеллектуальные контроллеры носят такое название не только потому, что они могут быть настроены на работу с самыми разными датчиками и исполнительными устройствами, а также предоставляют возможность доступа «внутрь себя» из компьютера или сети, но и потому, что способны самостоятельно обрабатывать получаемую от датчиков или других контроллеров информацию. Надежность всей системы, таким образом, заметно повышается, так как выход из строя любого отдельного узла сети контроллеров мало влияет на работу (точнее, на работоспособность) всех остальных систем. При надлежащем мониторинге и обслуживании сети такая единичная авария не должна привести к каким-либо серьезным последствиям (cм. Рисунок 2б).

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

Завершая разговор на тему о правильных и неправильных решениях, хотелось бы остановиться на роли корпоративной сети передачи данных в системе ИЗ. То, что она должна использоваться, сомнению не подлежит, вопрос только - как? Если сеть служит для обмена данными между управляющим компьютером (или компьютерами) и отдельной сетью интеллектуальных контроллеров, то никаких проблем нет.

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

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

Мы не будем, впрочем, пугать вас картинами того, что произойдет, если вдруг сигналы от противопожарной сигнализации потеряются в сети, потому что такого не может быть никогда. Подобная уверенность объясняется тем, что если здание после строительства или ремонта (реконструкции) было сдано по всем правилам, то интегрировать пожарную сигнализацию «внутрь» других систем никто не разрешит. Причина заключается в том, что, по правилам противопожарной безопасности, система должна быть стопроцентно прогнозируема. В принципе, если модернизация не снижает прогнозируемость, то принципиальных противопоказаний быть не должно, но существующие нормативные акты не вникают в нюансы, а просто запрещают все, что не разрешено.

Согласно отечественным нормативным актам, пожарная сигнализация должна быть построена совершенно определенным образом и подключения к ней других устройств не допускается. Этот порядок воспринимается отечественными интеграторами как данность, с которой приходится мириться; бороться же с ним в силу очевидной бесполезности подобных попыток никто не собирается. (В силе пожарной инспекции можно убедиться хотя бы на примере недавнего инцидента с издательством "КоммерсантЪ".)

Это, впрочем, не означает, что сигнализация остается полностью изолированной, так как правила запрещают только передачу по ее шлейфам сигналов от каких-либо других устройств, кроме предписанных, но получать эти сигналы от системы (с главного пульта) они не запрещают. Заметим также, что нормативные акты явно не запрещают интеллектуализацию других подсистем противопожарной безопасности (пожаротушения, дымоудаления и проч.), так как их функции являются по отношению к сигнализации дополнительными c точки зрения обязательности реализации.

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

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

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

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

Заключение

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

Источник: Александр Авдуевский, LAN N 10/1999