Инженерные системы

Если у вас большой и серьезный ЦОД, то параметрия температурных режимов не является проблемой. Существуют проверенные решения, например, программируемые контроллеры TAC Xenta, которые работают через LonWorks. Именно так мы собираем данные в московском ЦОД Datahouse. Но непосвящённому смертному весьма непросто собрать правильные показатели из этой связки и выводить их в мониторинг в нужном виде. К тому же решение промышленное и достаточно дорогостоящее. Поэтому при строительстве новой гермозоны
в Екатеринбурге мы решили поэкспериментировать и внедрить альтернативное решение по измерению температуры в холодных и горячих коридорах.

Ничто не предвещало беды

Так как множество систем в этом ЦОДе завязано на открытом коммуникационном протоколе Modbus мы решили заказать температурные датчики, работающие поэтой шине, и собирать данные с дальнейшей интерпретацией в интерфейсе мониторинга. Недорогие датчики быстро нашлись на известном китайском сайте и были заказаны партиями в количестве 20 и 40 штук.

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

Из первой партии завелось 15 датчиков. Так как острой потребности в остальных не было, пока работали с ними. К моменту прихода второй партии выявили, что часть уже установленных в шину датчиков имеет поведение новогодней елки: показывают некорректные данные, отдают checksum error или отваливаются по таймауту.

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

Вот так это выглядело:

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

Не ищем легких путей

Вскрыли, посмотрели: микросхемы идентичны. Значит дело в прошивке.

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

Пока разбирались с работоспособностью датчиков поняли, как без особых сложностей обнаружить кривую версию прошивки. Если кроме Modbus работают обычные текстовые команды READ, PARAM, AUTO, STOP значит прошивка хорошая. В мертвых прошивках текст не отдается.

Решили взять прошивку с этих живых 8 датчиков, купили программатор Nu-Link,
но хитрые китайцы заблокировали чтение прошивки. То есть перезалить можно, а считать - нельзя. Запросы правильных прошивок у поставщика потерпели фиаско:
Я продаван, я не разработчик.

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

За основу был взят Keil, пакет С51, позволяющий работать с 8-битными MCU.

В начале я научил читать сенсор SHT 20 (который собственно и снимает температурные данные), потом научил передавать эти данные по Modbus. В виду того, что этот MCU ни что иное как Nuvoton N76E003AT20, то вся база знаний, видимо, сосредоточена в руках наши китайских друзей.

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

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

Так стало:

Если говорить про результаты измерений, то нормальные показания появляются только
в помещении с явной циркуляцией и движением воздуха. Без продува датчик показывает 30С. Это объясняется тем, что внутри установлен стабилизатор напряжения, который преобразует 24В в 3.3В, переводя разность в тепло.

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

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

Программа выложена на GitHub кому интересно, можно забрать и поиграться.
Стоимость датчика всего 300 , правда, нужен программатор.

Резервированные источники питания используются повсеместно. Они обеспечивают бесперебойным электропитанием приборы охранной и пожарной сигнализации, оборудование систем контроля доступа и другие системы. На нашем предприятии в качестве таких источников, как правило, используются приборы от ЗАО НВП Болид. У некоторых из них, как, например, у РИП-12-6/80M3-R-RS, имеется интерфейс RS485, что позволяет включать их в систему мониторинга.

Средства мониторинга

Мы используем Zabbix 5.2. Получать данные от РИП будем по протоколу Modbus RTU over TCP. Поддержка этого протокола реализована в Zabbix с помощью загружаемого модуля libzbxmodbus. Также в процессе мониторинга принимают участие преобразователь протокола C2000-ПП (вер. 1,32) в режиме Master и преобразователь последовательных интерфейсов (RS485 в Ethernet).

Объекты мониторинга

Для начала определимся, что конкретно мы сможем контролировать. Из документации к РИП-12-6/80M3-R-RS и С2000-ПП выяснилось, что рассчитывать мы можем на получение состояния семи зон (ШС) и числовых значений тока и напряжения. В ходе экспериментов мне удалось воспроизвести следующие состояния ШС:

ШС 0 Состояние прибора

ШС 1 Выходное напряжение

ШС 2 Ток нагрузки

ШС 3 и ШС 4 Напряжение на батарее 1 и 2 соответственно

ШС 5 Степень заряда батарей

ШС 6 Напряжение сети

Крайне вероятно, что мной была получена только часть из всех возможных состояний. Например, имеются догадки, что ШС 3 и 4 должны также иметь состояние [204] Необходимо обслуживание, а ШС 0 - состояние [203] Сброс прибора и другие. К сожалению, чтение документации ситуацию не прояснило. В связи с этим нам необходимо следить и реагировать на появление событий, которые мы не предусмотрели.

Конфигурирование устройств

Не будем долго останавливаться на процессе конфигурирования приборов, только коротко рассмотрим перечень необходимых действий. Настройка устройств Болид осуществляется при помощи утилиты UProg и имеет следующий порядок:

1. Назначение сетевых адресов всем устройствам (РИП и С2000-ПП),

2. Конфигурирование интерфейса интеграции С2000-ПП (Modbus RTU),

3. Добавление ШС, описанных выше, в таблицу зон С2000-ПП. Крайне важно, чтобы, во-первых, были добавлены все ШС, а во-вторых, ШС должны следовать друг за другом в порядке возрастания.

При заполнении таблицы зон следует помнить следующее:

• адрес прибора - сетевой адрес РИП, в нашем случае 126,

• номер ШС - номер ШС от 0 до 6,

• тип зоны - тип ШС, для ШС 0 назначаем тип зоны "3 - состояние прибора", для всех остальных - "8-РИП напряжение / ток".

Создаем шаблоны Zabbix

Напомню, что Zabbix с модулем libzbxmodbus выступает в роли Modbus-мастера. Из-за особенностей получения данных от C2000-ПП, о которых речь пойдет в процессе создания шаблонов, мы будем рассматривать два подхода к мониторингу.

• мониторинг состояния ШС.

• мониторинг как состояния, так и числовых параметров РИП.

Мониторинг состояния ШС

Итак, создадим шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS. Шаблон имеет один элемент данных с именем Request и типом "Простая проверка". Ключом элемента является функция: modbus_read[{$MODBUS_PORT},{$MODBUS_SLAVE},{$STATUS_REG},3,7*uint16] . В параметрах функции используются значения макросов, которые позволяют составить корректный modbus запрос к C2000-ПП.

• {MODBUS_PORT} - тип используемого протокола (enc - Modbus RTU over TCP), адрес и порт преобразователя последовательных интерфейсов.

• {MODBUS_SLAVE} - Modbus UID С2000-ПП (настраивается в UProg на вкладке прибор).

• {STATUS_REG} - адрес регистра в котором расположен ШС 0 интересующего нас РИПа. Получить данный адрес можно следующим образом: "Номер зоны в таблице зон С2000-ПП" + 40000 - 1. В нашем примере это: 450+40000-1 = 40449.

Основная задача элемента Request - запросить у С2000-ПП значение всех семи ШС контролируемого РИП и предоставить их в формате JSON. Результирующий JSON содержит объекты, ключами которых являются адресы регистров С2000-ПП, а значениями - содержимое этих регистров:

{  "40449":39115,  "40450":51195,  "40451":50171,  "40452":51963,  "40453":51451,  "40454":50683,  "40455":763}

Зависимые элементы данных

Элемент данных Request имеет 7 зависимых элементов. Основная задача этих элементов - распарсить JSON и получить состояние каждого ШС индивидуально. Вот эти элементы:

• Status - состояние прибора (ШС 0),

• Uout - выходное напряжение (ШС 1),

• Iout - ток нагрузки (ШС 2),

• Ubat1 - напряжение АКБ1 (ШС 3),

• Ubat2 - напряжение АКБ2 (ШС 4),

• Capacity - степень заряда АКБ (ШС 5),

• Uin - напряжение сети (ШС 6).

Предобработка зависимых элементов данных

Чтобы получить состояние ШС 0 (Status), нам достаточно два шага предобработки. На первом шаге мы воспользуемся стандартным функционалом JSONPath, а затем разделим полученное значение на 256, тем самым получим код состояния.

К сожалению, мне не удалось использовать математические операции в параметрах JSONPath. Поэтому для оставшихся элементов данных пришлось использовать javascritpt-предобработку. Например, для элемента данных Iout (ШС 2) javascript-предобработка выглядит так:

function (value){    var reg = parseInt({$STATUS_REG})+2;    var data = JSON.parse(value);    return data[reg];}

Триггеры

После добавления триггеров создание шаблона можно считать завершенным. Перечень созданных триггеров:

1. Взлом корпуса прибора,

2. Перегрузка источника питания,

3. Отключение выходного напряжения,

4. Неисправность батареи АКБ1,

5. Неисправность батареи АКБ2,

6. АКБ1 разряжен,

7. АКБ2 разряжен,

8. Авария сети 220 В,

9. Потеряна связь с прибором,

10. Неизвестное состояние Status,

11. Неизвестное состояние Iout,

12. Неизвестное состояние Uout,

13. Неизвестное состояние АКБ1,

14. Неизвестное состояние АКБ2,

15. Неизвестное состояние Capacity,

16. Неизвестное состояние Uin,

17. Превышено время отсутствия по MODBUS.

Демонстрация и импорт RIP 12 mod 56 RIP 12 6 80 M3 R RS

Ссылки для импорта: Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS, Преобразование значений RIP 12 mod 56 RIP 12 6 80 M3 R RS.

Мониторинг состояния и числовых параметров

Мониторинг числовых параметров имеет свои особенности. Все дело в том, что для получения числового значения нам необходимо сделать два modbus-запроса к С2000-ПП. Первый запрос устанавливает зону для запроса тока или напряжения, второй - непосредственное получение значения. В таком случае мы не имеем возможности использовать функционал libzbxmodbus, т.к. попросту не cможем гарантировать правильную очередность запросов.

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

В связи с вышесказанным, для этих целей было решено отказаться от использования libzbxmodbus и написать скрипт, который сможет предоставлять и числовые параметры РИП и состояния его ШС.

Пишем shell скрипт для внешней проверки

Для того, чтобы синхронизировать доступ к преобразователю последовательных интерфейсов, воспользуемся утилитой flock. Работу с Modbus будем осуществлять при помощи modpoll. В /usr/lib/zabbix/externalscripts создадим скрипт rip_12_mod_56.sh

#!/bin/bash# rip_12_mod_56.sh# $1 - protocol://host:port# $2 - Modbus UID# $3 - Status register# $4 - Offset (0 - 6)# Example of requesting statuses:       ./rip_12_mod_56.sh enc://127.0.0.1:4001 1 40000# Example value request:                ./rip_12_mod_56.sh enc://127.0.0.1:4001 1 40000 3(($# < 3)) && { printf '%s\n' "You have given little data. Command exited with non-zero"; exit 1; }lockfile=$(echo "$1" | awk -F "://" '{print $2}')setzone(){        modpoll -m $1 -a $4 -r 46181 -0 -1 -c 1 -p $3 $2 $5> /dev/null 2>&1    (($? != 0)) && { printf '%s\n' "Command exited with non-zero"; exit 1; }    sleep 0.15}getvalue (){        value=$(modpoll -m $1 -a $4 -r 46328 -0 -1 -c 1 -t 4:hex -p $3 $2 |grep ]: |awk '{print $2}')        printf "%d" $value}getstatus (){        status=$(modpoll -m $1 -a $4 -r $5 -1 -c 7 -t 4:hex -p $3 $2 | grep ]: | awk -F "0x" 'BEGIN { printf"["} NR!=7{printf "\""$2"\","} NR==7 {printf "\""$2"\""} END { printf "]"}')    echo "{ \"status\": $status }"}(        flock -e 200        protocol=$(echo $1 | awk -F "://" '{print $1}');        host=$(echo $1 | awk -F "://" '{print $2}' | awk -F ":" '{print $1}')        port=$(echo $1 | awk -F "://" '{print $2}' | awk -F ":" '{print $2}')        register=$(($3+1))        if (($# >= 4)); then                zone=$(($register+$4-40000))                setzone $protocol $host $port $2 $zone                echo $(getvalue $protocol $host $port $2)                sleep 0.15                exit 0        fi        echo $(getstatus $protocol $host $port $2 $register)        sleep 0.15;) 200> /tmp/$lockfile

Подробности настройки внешних проверок в Zabbix уточняйте в документации.

Создаем RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED

Для получения информации о состоянии ШС шаблон содержит элемент данных Request с типом "Внешняя проверка". Ключом элемента является скрипт: rip_12_mod_56.sh[{$MODBUS_PORT}, {$MODBUS_SLAVE}, {$STATUS_REG}]. Как и в шаблоне RIP 12 mod 56 RIP 12 6 80 M3 R RS, задача элемента Request - сформировать JSON с состояниями всех ШС.

Возвращаемый JSON оптимизирован для использования функционала JSONPath. Для упрощения скрипта значения возвращаются в шестнадцатеричной форме:

{  "status": ["98CB","C7FB","C3FB","CAFB","C8FB","C5FB","02FB"]}

Состояния ШС. Снова зависимые элементы данных.

Как и в предыдущем шаблоне, элемент данных Request имеет 7 зависимых элементов. Задача этих элементов тоже неизменна - распарсить JSON и получить состояние каждого ШС.

Получаем числовые значения

Для получения числовых значений создадим 5 элементов данных с типом "Внешняя проверка".

• Uout_value - значение выходного напряжения, В.

• Iout_value - значение выходного тока, А.

• Ubat1_value - значение напряжения на батарее 1, В.

• Ubat2_value - значение напряжения на батарее 2, В.

• Uin_value -значение напряжения сети, В.

Ключом этих элементов является скрипт: rip_12_mod_56.sh[{$MODBUS_PORT}, {$MODBUS_SLAVE}, {$STATUS_REG}, <НОМЕР ШС>].

Триггеры

Перечень триггеров не отличается от триггеров, созданных в шаблоне RIP 12 mod 56 RIP 12 6 80 M3 R RS.

Демонстрация и импорт RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED

Ссылки для импорта: Шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS EXTENDED, rip_12_mod_56.sh.

Вместо заключения

В своем мониторинге мы используем шаблон RIP 12 mod 56 RIP 12 6 80 M3 R RS. По-большому счету причина такого решения одна - расширяемость системы. Использование загружаемого модуля позволяет включать в одну линию приборы разных типов и модификаций, организовать их мониторинг стандартными средствами. Кроме этого, большой потребности в получении числовых значений у нас пока не возникало.

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

Спасибо за внимание!

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

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

Чтобы повысить безопасность и ускорить время реагирования, как раз и нужна система технологического видеонаблюдения. С её помощью специалист может понять, реальная проблема или нет. Или, например, первым увидеть изменение цвета дыма из трубы, а не дожидаться момента, когда бдительные жители соседнего населенного пункта оценят изменения воздуха в соцсетях и через СМИ.

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

Забудьте всё, чему учили в школе

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

• массасоставляющих, определяющих выбор оборудования и технических решений;

• проведение работ в условиях повышенной опасности;

• взаимодействие с рядом служб предприятия;

• очень много бюрократии.

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

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

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

Противогаз есть? Есть!

Тут сделаю первое отступление и расскажу, что на самом деле нельзя просто так прийти и начать делать свою работу, скажем, на нефтеперерабатывающем предприятии. Сначала мы должны были потратить один день на прохождение инструктажа и получение пропусков. Для этого мы 5 (пять!) часов в компании 100 любезных господ с вахты стояли в очереди на улице, чтобы прослушать важную информацию. Настрой был слегка негативный, но инструктаж на удивление оказался полезным: основные правила ОТ и ТБ мы, естественно, знаем, но на предприятии своя специфика и ее много. В дальнейшем всё это помогло нам сэкономить весьма крупную сумму на штрафах. Правила ТБ на таких предприятиях закон, и словить 50k штрафа вообще не проблема. Поэтому слушаем, расписываемся и бежим за пропуском.

Уже в следующий приезд мы заранее договорились, чтобы нас ждал начальник установки, иначе мы просто рисковали сразу уехать домой. Приехать и пойти на установки нельзя, в лучшем случае просто отберут пропуск. И, кстати, в таких проектах можно не волноваться про полезные для здоровья 20k шагов в день они точно будут. Площадки разбросаны по большой территории, и всё обойти сложно даже за два дня. Ещё и поэтому, кстати, СТВН и нужна: если оператор побежит осматривать установку, на это уйдёт немало времени.

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

Что для меня еще оказалось интересно, так это то, что промышленное предприятие живой и буквально бурлящий организм. Можно, например, столкнуться с ситуацией, когда эстакаду, на которой основывалась половина проекта, снесли, пока шло проектирование. А колонну размером с шестиэтажный дом перенесли в другое место. И да, то единственное здание на площадке, куда вы всё сводили, перестроили к концу проекта. Так что я вывел правило всегда интересоваться планами заказчика не только на текущий, но и на следующий год. Чтобы не получилось так, что при выходе на реализацию мы имеем дело с совсем другой площадкой. Ну и честно скажу, что ещё один из наших таких проектов был изменен в ходе работ по проектированию на 30-40%.

Подготовительный этап

Итак, вернемся к СТВН. Она должна повысить уровень безопасности на предприятии, быстро снять спорные вопросы и дать полную картину, что сейчас происходит на агрегате или узле. Мы помним, что такие системы, как правило, создаются на предприятиях, где безопасность играет ключевую роль. И иногда действительно всё решают минуты.

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

Что еще важно при создании СТВН?

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

• Нужно погружение в объект и много вопросов на месте: А что тут вас? А здесь что храните? А это опасная зона? А почему вы так делаете?. В таком проекте невозможно оградиться от всего, что окружает систему видеонаблюдения, да и камеры могут повлиять на всю среду.

• Третье: надо спрашивать у персонала, что и как они хотят с помощью СТВН мониторить. В случае с обычными проектами мы часто лучше охранников знаем, как и что им нужно смотреть. С технологическим видеонаблюдением так не выйдет, потому что у каждого предприятия и каждой конкретной установки своя специфика: где-то надо смотреть на задвижку, где-то на дверь печи. И не должно быть ситуаций, когда нужная труба в правом верхнем углу на срезе, а выход из неё виден на 2 см. Иногда такое встречается, и как результат персонал просто не хочет с такой системой работать, так как нужно напрягать зрение, а полезной информации минимум.

Тут нужно снова сделать отступление и сказать, что на крупных промышленных комплексах начальник каждой установки это царь, который решает практически всё и нянчится со своей площадкой, как считает нужным. Поэтому он может очень сильно ускорить нашу работу и решить многие вопросы, а может накинуть проблем и мыслей, чтобы подумать. И если ты приедешь к нему, такой клёвый парень, и скажешь: Мне вообще всё равно, что у вас творится. Скажите, куда камеры ставить и как кабель класть, думаю, как минимум возникнет лёгкое недопонимание.

Технологии и решения: что мы использовали

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

В итоге у нас на проекте было:

• 80 камер во взрывозащищенных кожухах типа Ex tb IIIС T80C. Они подбирались по специальным требованиям среды на площадках. Главная опасность пары горючих веществ и взрывоопасный газ. Мы выбрали специальное исполнение кожуха с герметичными вводами, чтобы даже в местах входа кабеля ничего не могло просочиться к нашему оборудованию. При это стоит особое внимание обратить именно на кабельные вводы, так как они отличаются в зависимости от типа используемого кабеля, его оплётки и брони. К каждому кожуху подходят питание и сам информационный кабель.

• 30 взрывозащищенных коммутаторов. Аналогично камерам выбирали и линейное оборудование. Все очень большое и тяжёлое, как мы любим, поэтому заранее требовалось подобрать и места для креплений. Как правило, нужны крепкие металлические или бетонные опоры. Вешали такие коммутаторы втроём. Для сравнения: есть боксовые уличные коммутаторы по сути, герметичная пластиковая коробка весом в 10 кг. Такую легко повесит и один человек. С кабельными вводами ещё интереснее теперь ты уже можешь ошибиться не на один вход в камеру, а на 6-8, так как это оборудование агрегации. И после подбора ещё пару ночей я просыпался в поту, что где-то ошибся на 2 мм, и кабель будет болтаться или не влезет.

• 4 км оптического и 6 км медного кабеля и порядка 1,5 км лотков. Лоток есть лоток бери больше, кидай дальше. Но специфика предприятия в том, что надо всё делать на специальных эстакадах, а кроме нас там ещё 100500 устройств и линий. А поскольку эстакады высокие, нам нужен подъемник + куча согласований, план работ, и всё по ТБ. И да, красную ленточку для ограждения тоже не забываем, а то минус круглая сумма (в некоторые моменты реально задумываешься, что если бы люди знали, сколько штрафов они могли бы получить, то даже не подумали бы там работать. Но зато потом, уже прожжённым (плохое слово для завода) опытом, им ничего не страшно.

• серверы, стойки, АРМ на всех площадках

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

Особенности инсталляции: крутить гайки можно, жечь нельзя

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

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

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

Как решали? Бригадир монтажников очень адекватно подошел к задаче много сам ходил и общался со службами на объекте. Где-то договаривались, где-то делали с нуля, иногда подключали заводское управление.

Что получилось

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

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

Если остались вопросы по теме поста, пишите в комментарии, постараюсь ответить. Моя почта IVoloshin@croc.ru

Всем привет.

Кто пропустил тему про саму идею, создание рамы и установку мотора, высоковольтной батареи и подвески http://personeltest.ru/aways/habr.com/ru/post/551750/часть 1

Установка колес, подключение электрики и модуля заряда PDM Nissan Leafhttp://personeltest.ru/aways/habr.com/ru/post/552888/часть 2

Последний наш пост был 3 недели назад. За это время мы шагнули далеко вперед.

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

Сначала были установлены тормозные суппорта. Далее сделана разводка тормозных трубок и шлангов через блок АБС.

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

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

При первом выезде мы на скорую руку написали программу управления электродвигателем. Суть заключалась в том, что при нажатии газа багги ехал вперед, а при нажатии тормоза включалась рекуперация на 10%. И при остановке багги вместо рекуперации начинал ехать в обратную сторону. Но мощности явно не хватало, да и ехать назад посредством торможения не правильно.

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

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

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

Кто смотрел видео с первым выездом, то видели, что вместо сидения у нас стоял ящик от инструментов. Это дело мы также поправили. Были установлены вот такие самодельные ковши.

Также во время пробной поездки у нас не был закреплен 12В бортовой аккумулятор. И это дело мы исправили. Установили площадку спереди. Это положительно повлияло и на развесовке.

При промежуточных выездах мы заметили, что через какое то время багги терял первоначальную мощность. На форумах некоторые люди катаются без системы охлаждения при этом в полной уверенности, что у них все в порядке. Сначала мы не понимали как это возможно. Но потом все стало ясно. В основном на Leaf катаются не гонщики и так как заряд батареи ограничен, то люди в основном передвигаются в плавном режиме. Мы же ездили "тапка в пол". У лифа существует ошибка P3252 Limits the maximum torque of traction motor to 50%. И выскакивает она при недостаточном охлаждении IGBT ключей. Поэтому далее мы установили систему охлаждения.

Помпа здесь также интересная. Не классическая механическая, а электрическая. Сейчас она просто гоняет антифриз на максимум, но в дальнейшем мы будем управлять помпой по ШИМ сигналу в зависимости от температуры антифриза в системе.

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

Кому интересно более подробная информация, то ее можно увидеть на нашем канале "Время инженеров" ниже.

Будни разработчика. Цели определены, направления выбраны, задачи разжеваны. Нужно просто писать код и жевать кашку. Что может скрасить серость и однообразность существования? Конечно же daily standup - шоу, в котором есть место для каждого! Ну вот эти вот неожиданные я посмотрел архитектуру и там ошибка или вот я добавил новый модуль, который нам может пригодиться в будущем ну и, конечно, я сделал всё проще и быстрей. Мы ведь именно ради этого делаем все церемонии груминга и планирования. Чтоб как бы подготовить почву и дать всем время посидеть молча и подготовить эти панчлайны на конец спринта. А самое обидное, что, потратив столько усилий, на сам стендап вы обычно не попадаете и панчи вам передаёт ваше начальство.

В чём интрига? В самой сцене. В самом начале дня у нас обычно дейли разработчиков. Там все делятся успехами и проблемами. Охотно так делятся. Долго и много. Как раковые клетки. Даже анализы можно делать. Чем больше тем на этом daily, тем больше опухоль в проекте. Потом придётся выжигать и резать. Но команд много, а архитектора мало. Поэтому его не зовут, если не уже дымится.

Дальше отсеиваются разработчики и в следующий тур идут только тимлиды. Они более практичны и рассказывают о своих успехах и как всё по плану, а проблемы выносят в оффлайн. Сухо так и без шуток. С dev. менеджером обычно всё позитивно, если менеджер сам не станет копать или не возникнет подозрение о том, что дедлайн слишком близко к носу. И так как начальник - человек занятой (его каждый раз кто-то занимает, но, как ни странно, каждый раз и отдаёт), команд много и проекты глобальные, то представитель от каждого сайта (ротация среди лидов) подключается к общему митингу, куда обычно и приглашают архитектора. Это самые бесполезные пол часа. Каждый уже пару раз рассказал свою историю и пережевал проблемы (а тут, видимо, как и с шутками: проблема, повторенная дважды, перестаёт быть проблемой). Вдобавок говорить то на английском надо, который для большинства неродной и куча акцентов Короче, каждый chosen one пытается сказать одно-два предложения, так чтоб не дай бог не задали вопросов. Как на приёме в налоговой.

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

В чём же будни архитектора, помимо кофе и рисования? Ведь многие считают, что гнездо архитекторы вьют только из одноразовых стаканчиков в местах большого скопления whiteboard-ов. Конечно же в ловле личинок bug-ов! В первую очередь, конечно, интересуют ошибки проектирования. То есть свои же собственные промахи. До начала разработки архитектуру семь раз замеряли, но когда приходит время отрезать, выясняется, что попасть в метку тяжело, пила не та, то брус не тот. Все стройные теории начинают сползать с вакуумного глобуса. На этапе разработки первичной версии начинают выясняться все детали, которые попали в финальную версию контракта. Самые главные: дата и точный спектр функционала первого демо для клиента.

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

Ад у каждого свой. Мой похож на ежедневные диспуты с начальниками разных отделов, каждый из которых предлагает вместо твоей глупой инфраструктуры, давай сделаем анимированные кнопочки. Случалось же слышать: а юнит тесты точно нужно писать? А может можно как-то без них? или нам же сейчас не нужно это твоё скалкобилити, а красивый интерфейс это лицо продукта. Хорошее лицо тоже важно, но этот орган плохо поглощает кинетическую энергию и при встрече с бетонной реальностью лучше приземлиться на пятую точку. Особенную нишу занимают вот тут 20 дней на безопасность выделено, нужно сделать за 10, чтоб ещё пару фишек втиснуить из бессмертной серии а семь шапок можешь?. Мне всегда сложно объяснить кому-то почему же 2+2 = 4. На сложные вещи аргументация всегда находится, а как объяснить то, что ты считаешь базовым, да еще и когда экспериментально доказать за 5 минут не получится.

Чтобы понизить градус ада приходиться заниматься презентациями, которые бы наглядно показали как у нас всё работает и почему. Хочется, конечно, Босха, но приходится сводить простые зарисовки со стрелочками. Анализировать бэклог, искать пересекающиеся требования и показывать, что кнопочки сейчас по затратам равны кнопочки завтра, а безопасность сейчас намного дешевле безопасность завтра. Строится цепочка требований ведущих или исходящих из кнопочки и такая же для требования безопасности. Так как бизнес-требования обычно не пересекаются, то цепочку таких требований легко двигать в плане вперёд и назад. А значит и цена будет неизменной. Инфраструктура же пронизывает все модули и цепочки, а значит если завтра будет в 10 раз больше модулей, то будет и в 10 раз больше интеграции/внедрения и проверок (важная статья расходов и времени). Кто бы мог подумать!? И обязательно гуглите что-то из серии цена ошибки безопасности в своём промышленном/деловом секторе. Для производства всегда хорошо работает пример Иранских центрифуг. В финтехе или ритейле примеров полным-полно. Хорошая страшилка лучше любых формул. Детей пугают сказкой про волка, а не расчётами семейного бюджета (хотя последнее может быть намного страшней).

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

Мой know-how в этом процессе направляемый мозговой штурм. У вас есть готовый вариант архитектуры модуля. В моём случае это значит, что определена модель (абстракции) и контракты (данные) и есть сопутствующая диаграмма взаимодействий или сущностей. Так вот эту диаграмму я начинаю строить с разработчиком, скармливая ему требования и проблемные аспекты так, чтоб он посмотрел в конце на моё решение и сказал классно мы с тобой придумали!. Ну ещё бы.

Работает это примерно так:

Нужен модуль, который получает пакет цифровых документов и мапит их в базу. Разработчик сразу предлагает какой-нибудь pub-sub, асинхронные (так почему-то 80% людей называют параллельные процессы) таски и пару микросервисов. Куда же без них.

Теперь надо подхватить его под руку и вести туда, куда хотите вы. Закидывается проблема и предлагается решение, которое у вас прописано в архитектуре. Как-то так: Хорошее решение, но если у нас будет асинхронный маппинг, то возникнут проблемы совместного доступа. А что, если вместо параллельности мы сделаем последовательность?.

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

За шага 3-4 мы уже достигаем желаемого результата. В отличии от варианта, когда вы просто объясняете почему стоит сделать именно так, вы не лишаете человека самого важного поиска решения. Разработчик не стенографист и не стал экспертом потому, что просто быстро записывал за кем-то построчно. Если лишить его загадки, то работа может вызвать протест и кучу отрицательных эмоций. С другой стороны, он не знает всей картины. Ни того, что и как будут делать в других командах, ни того, что запланировано на полгода вперёд. В этом основная причина существования должности архитектора широкий и далекий взгляд на проект. Но ничего не получится, если ваша архитектура не обоснована требованиями. Нечем будет вести разработчика, да и незачем. В таком случае лучше честно партбилет на стол. У нас с этим строго. Это по утрам я Винни-Пух, а к концу дня я свинья с ружжом!

И стрелять всегда есть в кого. Пока все усердно пишут код нужно следить, что б всё неусерднулось. Тут на помощь нам всякие индикаторы и статические анализаторы кода. Делать метрики для программистов удел менеджеров. Я лично озабочен метриками кода. Индикаторы здоровья проекта:

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

• Длинные функции и классы не плохой индикатор поспешной работы и костылей. На начальном этапе такого быть не должно.

• Сложность кода можно отследить по количеству юнит тестов при высоком покрытые. Много тестов значит много веток, а значит опять что-то попахивает.

• Нарушение конвенций тоже стоит заавтоматить и следить. Закладывается фундамент дома, в котором нам всем жить долго.

• Много статики (классов, методов, полей), обычно, проявления антипаттернов.

• И, конечно, проверки безопасности на вшитые пароли и вшивые референсы на какие-нибудь опенсорсы с уязвимостями или сложными лицензиями.

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

Для подготовки к следующему этапу необходимо выстроить хороший механизм логирования. Желательно на два уровня один с понятной историей для бизнеса, а второй для технического анализа, что же всё-таки навернулось. Когда со стадии демо мы шагнём, пусть и в ограниченный, но production, то там будут первые кострища и охота на ведьм. Наблюдать в полнолуние как кто-то седеющими руками набирает код прям в проде плохая примета. По возможности старайтесь избегать этого. Так что одним стримом пишем: пользователь ****341 запросил функцию Поиск Заказа с аргументом 3480-4341-1334. Результат: не найдено. На этот лог сядет саппорт, когда процесс встанет. А второй стрим со стеком, сервисами и всеми деталями (опять-таки, кроме тех, что нужно замазать ради безопасности или для сохранения личных и коммерческих секретов). Тут уже пойдут разработчики, когда процесс ляжет. Логи делать необходимо с самого начала. Они всегда нужны вчера, когда всё случилось, а вот завтра от них будет мало толку. Клиент как-то не любит слышать: У вас тут вчера производство встало, а мы не знаем почему. Но когда встанет в следующий раз у нас будет больше данных для анализа!. Хотя в некоторых компаниях лишь под угрозой штрафов начинают понимать, что стоило вложиться сразу в аудит и мониторинг да начинают чесать головы (те в которые едят и те на которых сидят).

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

На Хабре часто пишут о квартирной вентиляции и её автоматизации. Такие кейсы интересны необходимостью достигать результатов, используя достаточно простые и не затратные компоненты. А в данной статье хотелось бы рассказать о другом конце спектра климатики и автоматизации - построении системы отопления в сильно-историческом здании. Работе, которая начиналась даже не с проектирования, а с математического моделирования...

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

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

Разумеется, в историческом соборе никто бы не дал прокладывать воздуховоды "под потолком" :)
Поэтому проработка решения началась не со стандартного инженерного проектирования, а математического моделирования движения воздушных масс и распределения температур внутри собора. Расчёты показали и низкие температуры со сквозняком у входных дверей; и низкую температуру воздуха в алтаре; и эффект стекания холодного воздуха из алтаря. Таким образом, было объективно подтверждено то, что ранее ощущалось просто как недостаток комфорта. Для исправления ситуации было предложено установить более мощные воздушно-тепловые завесы на входе и рассчитано дополнительное количество тепла для алтаря. Моделирование охлаждения собора в летний период показало, что при подаче охлажденного воздуха, в нижней части основного объема собора образуется холодная воздушная подушка. Воздушная подушка оказалась склонна к вытеканию из собора через открытые двери, для предотвращения этого было рекомендовано использовать воздушно-тепловые завесы в режиме отсечки. Кроме того, была проработана технология использования "воздуховодов 19 века", проложенных внутри кирпичных стен во время строительства собора.

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

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

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

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

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

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

Четыре приточно-рециркуляционные установки и приточно-вытяжная установка подвальных помещений оборудованы щитами управления, каждая со своим контроллером автоматики, тепловые завесы и конвекторы в алтаре управляются еще двумя щитами, также установлен щит управления в ИТП. Контроллеры в щитах автоматики и контроллеры холодильных машин соединены сетью Bacnet/IP со SCADA системой на 5000 точек данных.

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

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

Авторы: Аржаников Ростислав, к.т.н.; Осовский Кирилл

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

Во время первой мировой, как нам всем известно, авиация не только получила огромных размеров взрыв в развитии, так еще и впервые получила настоящее применение, помимо тестов и показательных полетов. До войны еще никто не верил в удивительные возможности самолетов, однако война всем доказала обратное, и, что самое для нас главное, не только как средство убиения себе подобных. В 1917 году, в синайской пустыне, один из солдат получил серьезное ранение вражеская пуля пробила и полностью раскрошила ему колено. Санитары, которые его спохватили, предлагали обычный способ взять верблюда и на верблюде чапать до ближайшей ж/д, где его уже подхватит поезд и он спокойно себе доедет до госпиталя. Однако такой путь бы занял 2.5-3 дня, ибо до ближайшей железной магистрали было идти около 120км. А потому было предложено одним из санитаров гениальное и, что самое главное, новаторское решение перевезти его на бомбардировщике. Самолет DH.9, который находился поблизости, имел два места одно место для пилота, и второе место для наблюдателя (так как самолет выполнял также и разведывательную функцию). А поэтому имелась возможность поместить там второго человека хоть и в сидячем положении, но все же лучше чем на верблюде. И, ко всеобщему удивлению, так и сделали. Поместили нашего бесколенного товарища на сидячее место наблюдателя и полетели к своим в госпиталь. Весь путь от места подбора военными докторами до госпиталя занял около часа и оставил солдата в целости, хоть и не в полной сохранности (увы, простреленное колено лишило его ноги; зато хоть жизни не лишило) путь по привычной земле занял бы в 60 раз дольше, с огромной вероятностью оставляя бойца мертвым.

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

После этого, санитарная авиация, наравне и со всей остальной авиацией в мире, начала бурно развиваться: многие транспортные и пассажирские самолеты модифицировались в медицинские, даже строились отдельные модели, предназначенные исключительно для перевозки раненых по воздуху. К примеру датский самолет SAI KZ III, созданный в 1944 году, имел у себя в корпусе уже не просто носилки, а полноценную койку.

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

Однако, конечно, модели и история это хорошо, но

Чем же он, этот ваш спасатель в небе, оснащен?

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

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

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

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

Цена такого удовольствия

Многие страны, как ни странно, не имеют официальных государственных систем для экстренного спасения людей, обладающих воздушным флотом. Вся эта задача лежит в руках частных компаний. К нашему с вами счастью, таких компаний по миру не так то и мало, зачастую 5+ на страну. Однако, даже несмотря на то, что большая часть этих компаний является некоммерческими, все же их вылет стоит круглую копеечку. К примеру, в США в 2008 году вылет вертолета из государственной клиники стоил 1500-1800$. В Великобритании в то же время до 2000 фунтов (у частной, но некоммерческой компании). И при этом всем, это еще не дорого, в сравнении с тем, что многие коммерческие компании требовали в то же время до 15000$ за вылет. Так что для нас с вами это далеко не дешевая вещица. Оно и понятно, ведь, помимо того, что стоимость часа полета у таких самолетов/вертолетов ни капли не ниже, чем у обычных моделей, так еще и оборудование стоит очень даже нехилых денег, да и еще нужно флот держать в готовности 24 часа в сутки, 365 дней в году. Ах да, еще же нужно вылетать в нелетную погоду, и после этого обслуживание возрастает в цене раза в полтора.

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

Автор: Алексей Борзенков

Использование блоков считается у проектировщиков хорошим тоном. А применение собственной библиотеки блоков признаком мастерства при работе в САПР. Как создать свою библиотеку блоков? Зачем использовать атрибуты в блоках? Разберем подробнее эти и другие интересные вопросы.

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

Нередки случаи, когда для оформления электрических схем проектировщики выбирают сторонние программы. Попробуем сформировать свою библиотеку блоков электрической схемы H-моста для управления коллекторным двигателем постоянного тока.

Выглядит схема так, как показано на рис.1.

Как и все электрические схемы, она состоит из повторяющихся элементов: резистора, диодов, транзисторов и т.д. Каждому элементу соответствуют одна или две текстовые части. Где-то текст варьируется в зависимости от элемента (порядковый номер R1, R2), а где-то остается неизменным (наименования диодов).

Начнем с черчения резистора по размерам (рис.2).

Создание блока

Все команды, необходимые для работы с блоками, находятся на вкладке Вставка группы Блок и Определение блока (рис.3).

• Выделаем начерченный резистор

• Вызываем команду БЛОК (Создание блока). Открывается диалоговое окно Определение блока (рис.4).

• Устанавливаем флажки Одинаковый масштаб, Разрешить разбиение и Указать на экране базовую точку.

• В качестве точки вставки блока указываем левый провод (рис.5).

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

Создание атрибутов блока

Прежде всего определимся с порядковым номером резистора.

• Вызываем команду ДИАЛАТОП Задание атрибутов. Появляется диалоговое окно Определение атрибута (рис.6).

• Заполняем для атрибута графы Имя, Подсказка и По умолчанию (рис.7).

• В параметрах текста выбираем выравнивание Середина по центру, чтобы после создания блока текст в атрибуте располагался точно посередине резистора (диалоговое окно Редактирование определения атрибута вызывается двойным щелчком по готовому атрибуту).

Отдельно рассмотрим опции режима в этом диалоговом окне (рис.8).

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

• Нажимаем Ok, указываем точку вставки атрибута. Полученный результат показан на рис.9.

Попробуйте самостоятельно создать атрибут для номинала резистора, а затем пойдем дальше. Теперь мы знаем, как создавать атрибут, но он все еще не связан с блоком.

Переопределение блока и связь атрибута с блоком

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

• Воспользуемся разбивкой блока Резистор1. Выделяем все объекты, включая атрибуты (рис.10).

• В поле Имя выбираем из выпадающего списка Резистор1 и нажимаем Ok (рис.11).

• Во всплывающем диалоговом окне нажимаем Да (рис.12).

• После указания точки вставки указываем левый провод, в диалоговом окне записываем порядковый номер R8 и нажимаем Ok (рис.13).

В результате мы создали готовый блок с привязанными атрибутами (рис.14).

Создав остальные блоки и атрибуты к ним, мы получим список элементов, необходимых для создания H-моста (рис.15).

Вставка блоков

Теперь, используя вставку блоков, мы сможем с легкостью воспроизвести схему H-моста. Воспользуемся командой ВСТАВИТЬ (рис.16).

• Из выпадающего списка выбираем необходимый блок.

• Нажимаем Ok.

• Записываем атрибуты (рис.17).

Палитры nanoCAD

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

• Сохраняем документ по следующему адресу: %AppData%\Nanosoft\nanoCAD x64 21.0\ToolPalette

• Создаем набор инструментов (перед этим на панели Инструменты следует щелкнуть правой кнопкой мыши (ПКМ) по строке Мои палитры) рис.18.

• Зажав ЛКМ, перетаскиваем блоки в созданный набор инструментов (рис.19).

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

Продолжим сборку схемы. Она состоит их четырех одинаковых частей, для начала сделаем одну (рис.21).

Далее скопируем выполненную часть вниз (рис.22).

Воспользуемся командой ЗЕРКАЛО и отобразим часть схемы вправо (рис.23).

Заметим, что вместе с блоками скопированы значения атрибутов, а атрибуты порядкового номера каждого элемента схемы изменились. Для их редактирования воспользуемся командой АТРЕДАКТ (EATTEDIT) или, дважды щелкнув по блоку, откроем Редактор атрибутов. А также добавим недостающие элементы схемы (рис.24).

Диспетчер атрибутов блоков

Если вы обнаружили в атрибуте ошибку и хотите изменить его во всех вхождениях, значит, схеме нужен новый герой. Воспользуемся командой BATTMAN (Диспетчер атрибутов блоков). К примеру, мне не нужна пометка с цифрой 0 у земли (GND_analog).

• В диалоговом окне выбираем из выпадающего списка блок GND_analog (рис.25).

• Нажимаем кнопку Редактировать.

• Во вкладке Атрибут устанавливаем флажок напротив режима Скрытый (рис.26).

В результате атрибут блока GND_analog не отображается на чертеже (рис.27).

Удаление блоков

Чтобы не засорять чертеж ненужными блоками, увеличивая при этом размер файла, воспользуемся командой БЛОКИ. В диалоговом окне появится их перечень и количество вхождений в чертеж (рис.28).

Так как у блока GND ноль вхождений, удалим его нажатием соответствующей кнопки в правом верхнем углу.

В завершение проведем исследование. Несколько раз растиражируем схему и воспользуемся командой РАСЧЛЕНИТЬ для всего чертежа. Сравним вес файлов (рис.29).

Размер файла с использованием блоков на 68 Кбайт меньше. При увеличении количества блоков и их вхождений в чертеж увеличится и разница в весе файлов. Это еще одно преимущество использования блоков.

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

Удачного проектирования!

Александр Горюнов,
технический специалист
по Платформе nanoCAD
ООО Нанософт разработка
E-mail: goryunov@nanocad.ru

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

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

Для чего нам Zabbix

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

Взаимодействие с OPC серверами

Самой сложной задачей, которая стоит перед нами, является организация взаимодействия с OPC-серверами. В ходе поисков готового решения такого взаимодействия стало понятно, что подходящих нам вариантов не так много. Из того, что было найдено, наиболее пригодным к использованию оказался консольный клиент OpenOPC.

Установка OpenOPC

Как было сказано ранее, речь идет о стандарте OPC DA, а значит, о технологии DCOM и, соответственно, ОС Windows. В нашем случае установка OpenOPC производилась на машину с Windows XP, где и находится проприетарный OPC сервер. После завершения установки необходимо добавить путь до opc.exe в системную переменную среды PATH.

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

C:\Users\Администратор> opc.exe -qMerz.OPC_SAIA_S-BUS.1C:\Users\Администратор>

Теперь попробуем получить теги в удобном нам формате - csv:

C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP.Register.OAT,197,Good,05/24/21 07:16:15C:\Users\Администратор>opc.exe -o csv -s Merz.OPC_SAIA_S-BUS.1 ATP.Register.OAT ATP5.Register.T_inlet ATP5.Register.T_outletATP.Register.OAT,198,Good,05/24/21 07:16:41ATP5.Register.T_inlet,627,Good,05/24/21 07:16:41ATP5.Register.T_outlet,654,Good,05/24/21 07:16:41C:\Users\Администратор>

Если что-то пошло не так

В ходе экспериментов с opc.exe выяснились некоторые моменты. Первое: каждый OPC клиент запускал новую копию OPC сервера, а их параллельная работа невозможна. Так как запустить используемый нами OPC сервер как службу не получилось, то через DCOM был настроен запуск OPC сервера от определенного пользователя. Все OPC клиенты - SCADA и агент Zabbix - были также настроены на запуск от этого пользователя. Второе: выявлены некоторые недостатки в работе самого OpenOPC. Например, клиент не вычитывает теги, в названии которых присутствуют символы, отличающиеся от латинских. С этим пока пришлось смириться и решать такие проблемы путем переименования тегов в OPC сервере.

Установка Zabbix агента

На ту же машину установим Zabbix агент, который сможет работать под Windows XP, например, zabbix_agent-5.2.0-windows-i386-openssl.msi. Агент будет выполнять активные проверки. Чтобы облегчить дальнейшую конфигурация агента, во время установки заполним следующие поля:

• Ноst name - уникальное имя хоста, совпадающее с именем узла сети на Zabbix сервере.

• Zabbix server IP/DNS - IP-адреса Zabbix сервера.

• Server or Proxy for active checks - IP-адрес Zabbix сервера для активных проверок.

Конфигурирование Zabbix агента

В конфигурационный файл C:\Program Files\Zabbix Agent\zabbix_agentd.conf были внесены некоторые изменения.

1. Увеличено время выполнения скрипта.

   ### Option: Timeout#Spend no more than Timeout seconds on processing.## Mandatory: no# Range: 1-30# Default:# Timeout=3Timeout=30
   

2. Создан параметр для мониторинга.

   #User-defined parameter to monitor. There can be several user-defined parameters.#Format: UserParameter=<key>,<shell command>## Mandatory: no# Default:# UserParameter=UserParameter=opc[*],opc.exe -o csv -s $1 $2
   

Узел сети и элементы данных на сервере Zabbix

На Zabbix сервере создадим узел сети. Имя узла сети должно совпадать с Ноst name, указанном при установке агента, интерфейс - IP-адрес агента.

Далее к созданному узлу сети добавим элемент данных c типом Zabbix агент (активный). Ключом должна являться конструкция типа: opc[<ИМЯ OPC СЕРВЕРА>, <ЗАПРАШИВАЕМЕ ТЕГИ ЧЕРЕЗ ПРОБЕЛ>].

Значениями элемента данных будут строки, разделенные запятыми:

ATP2.Register.OAT,273,Good,05/24/21 15:21:33ATP2.Register.GVS.T_inlet_W,501,Good,05/24/21 15:21:33ATP2.Register.GVS.T_outlet_W,445,Good,05/24/21 15:21:33ATP2.Register.T_outlet_w_com,404,Good,05/24/21 15:21:33ATP2.Register.RAD.T_outlet_W,256,Good,05/24/21 15:21:33ATP2.Register.P_in_W_com,39,Good,05/24/21 15:21:33ATP2.Register.P_out_W_com,36,Good,05/24/21 15:21:33ATP2.Register.RAD.P_outlet_W,43,Good,05/24/21 15:21:33ATP2.Register.FIRE.P_gidrant,68,Good,05/24/21 15:21:33

Зависимые элементы данных

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

В предобработке используем JavaScript, который получит необходимую нам строку в CVS, проверит качество тега и вернет результат.

function (value){    var nr_line = 4;    var lines = value.split('\n');    var fields = lines[nr_line].split(',');    if(typeof fields[2] != "undefined" &&  fields[2] == "Good"){    return (typeof fields[1] != "undefined") ? fields[1] : null;    }    return null;}

Пример визуализации полученных данных:

Заключение

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

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

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

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

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

Лонгрид!

2014

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

С самого первого объекта я начал применять темный интерфейс. У специализированных программ (AutoCad, Photoshop), был темно-серый интерфейс, в нем было комфортно работать долгое время и я решил придерживаться их идеологии. К тому же, помещение ИТП было без освещения и очень темным, делать яркий светлый фон на панеле просто издевательство над эксплуатацией. Хотя сейчас у нас в портфолио есть кейсы со светлой темой, все равно, на сегодняшний день предпочтение отдается именно темной.

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

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

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

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

2015

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

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

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

2016

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

На объектах, где есть технология, возникают проблемы в отрисовке из-за использования трехмерной графики. Одно дело показать насосы, клапан, фильтры и заслонки, другое дело показать технологическое оборудование. Найти в интернете подходящие картинки ультрафиолетовых ламп и фильтров очистки крайне сложно, не говоря уже о более сложном оборудовании: флотаторы, жироловки, обезвоживатели и так далее. Это одна из причин, почему мы отказались от 3Д в дальнейшем.

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

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

2017

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

2018

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

Основное отличие подхода к разработке этого интерфейса от предыдущих, это то, как рисуется вся статика. До этого интерфейс собирался по частям в среде разработки для панелей и в Scada системе, это очень усложняет процесс, особенно, выравнивание объектов. Здесь же вся статика делается в графическом редакторе и подгружается одной картинкой PNG на экран. Сверху накладываются только переменные и анимация. Это сразу убивает несколько зайцев: выравнивать и делать отступы можно с большой точностью, скорость загрузки страниц увеличивается, так как нужно меньше информации подгружать из памяти, уменьшается нагрузка на процессор.

С точки зрения дизайна, тут появилось много нового. Появился не стандартный шрифт GothamPro, цвета теперь не рандомные, а подобраны из палитр Material Design, появились кратные отступы и сетка. Объекты теперь выровнены все относительны друг друга. Поля индикации и ввода значения уже стали существенно различаться, к этому быстро привыкаешь и пользоваться становится удобно.

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

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

Первое видео было с панели оператора 7 дюймов, которая установлена на дверце шкафа управления, разработка дизайна интерфейса началась с нее, дальше будут экраны с мониторов системы диспетчеризации.

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

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

У нас есть объекты, которые имеют один этаж и там удобно все карточки систем размещать на планировке здания, привязывая к их реальному местоположению на плане. Есть объекты в 4-5 этажей, и здесь становится сложнее структурировать карточки. Можно разделить экран на 4 равных части и на каждом отобразить свой этаж с системами. Можно сделать 4 экрана, на каждом свой этаж с нанесенным на нем системами, но здесь могут быть нюансы, как правило, большая часть систем располагается на -1 этаже и на последнем или кровле, что приводит к сильному дисбалансу. Мы пробовали разные варианты, расскажу об этом чуть дальше в статье.

2019

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

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

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

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

1. Освобождаем интерфейс от всего лишнего, уменьшаем количество статических элементов, убираем все 3Д. Структурируем содержание по карточкам или вкладкам, оставляем больше места для динамических значение.

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

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

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

Здесь очень удачно планировка ТЦ вписалась в разрешение Scada системы примерно 1920 х 980 рх., это позволило расположить максимум полезной информации с привязкой к физическому местоположению. Так как систем много (около 150 штук) то лучший вариант разбить их по венткамерам, где находятся щиты управления, отобразить системы как название и подкрашивать его в зависимости от состояния. Серый выведен из эксплуатации, белый стоянка, зеленая работает, желтая требует обслуживания, красный авария. Дальше архитектура строится так: при клике на венткамеру открывается табличный вид связанных систем с их основными параметрами. При клике на название системы уже откроется мнемосхема со всеми доступными параметрами и настройками.

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

2020

Так, ну в этом году продолжилось логическое развитие интерфейсов с некоторыми экспериментами. Расскажу по порядку.

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

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

Если вы дочитали до этого места, то скорее всего обратили внимание, что впервые появился светлый интерфейс =). Появилась очень интересная идея сделать универсальный интерфейс с темной и светлой темой и переключать его либо автоматически от времени суток, либо вручную. Реализовали эту идею так: подложки на 95 процентов прозрачные с небольшим оттенком серого, статические элементы имеют цвета не сильно контрастирующие на темном и светлом фоне, переменные имеют подобранный серый цвет, больше контрастирующий на темном и светлом фоне. По сути, мы только меняем цвет фона с белого на темно серый, а все элементы остаются без изменения. С точки зрения работы Scada системы процесс максимально простой, подмена одного фона на другой, без замены других элементов, это не перегружает процесс работы и отрисовки. У такого решения есть минус, сложно подобрать цвета одинаково правильно отображающиеся тут и там, от этого переменные немного теряются на общем фоне. Есть вариант вместе с фоном менять скриптами и цвета переменных и других элементов, но не понятно насколько это может загрузить процесс отрисовки.

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

2021

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

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

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

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

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

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

2022

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

Надеюсь, вы нашли в статье что-то полезное для себя. Буду рад, если оставите свою критику и комментарии, напишите, какой интерфейс больше понравился вам и почему.

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

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

Какие задачи стояли

По итогам формализации пожеланий заказчика мы договорились, что нами, как инженерами, в данном проекте должны быть решены следующие задачи:

1. Поддерживать точный климат температуру и влажность во всех жилых помещениях.

2. Обеспечить единое управление всем и вся с графического интерфейса

3. Построить слаботочные и ИТ системы. В частности WiFi, который работает везде :)

Как решали климат и его автоматика

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

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

Для доведения температуры до желаемой в отдельном помещении установлены радиаторы - для обогрева. И холодные потолки - для охлаждения без резких потоков воздуха. Плюс - тёплые полы - дабы было комфортно ходить босиком.

Система управления ("умный дом", или, если угодно - "умный особняк") в этом проекте была разделена на бэкенд (классическая система автоматизации/диспетчеризации на контроллерах Sauter) и фронт-енд (графический пользовательский интерфейс на базе ориентированных под это контроллеров Crestron; плюс сюда же задачи по управлению мультимедией). Общаются бэкенд и фроненд по сети по протоколу Bacnet/IP.

Более 600 датчиков (температуры, влажности, давления воздуха, движения); порядка 650 устройств, подключенных к выводам контроллеров (реле, приводов, клапанов, ...). Около 1600 переменных в SCADA системе. 53 контроллера автоматики и парочка контроллеров умного дома.

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

Умный дом

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

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

Также управление освещением продублировано с настенных выключателей. Особое внимание было уделено отказоустойчивости системы включение/выключение света будет возможно даже при выходе из строя контроллеров автоматики.

Дополнительной вишенкой на торте является система позиционирования, позволяющая в автоматическом режиме определять, в каком помещение находиться хозяин дома с главным, Master iPadом и выводить на экран планшета соответствующую страницу меню управления. С точки зрения техники, данный функционал реализован на Bluetooth BLE маячках (BLE PinPoint beacons), установленных по дому. При появления iPad в поле их действия, софт на iPadе сигнализирует о событии центральному контроллеру и получает команды на определенные действия. Никакие датчики в пользователя не встраиваются ;)

Изнутри это обеспечивают контроллеры Crestron. На них же возложено общение с мультимедиа устройствами.

ИТ системы

Для обеспечения доступа хозяев дома в интернет, а также для работы системы управления во всём комплексе зданий развёрнута единая сеть WiFi, позволяющая перемещаться по помещениям, сохраняя соединение. В том числе не прерывая разговора по голосовым мессенджерам. Учитывая сложную радиообстановку (толстые стены, крайне высокое затухание сигнала), сеть создана на базе аппаратного контроллера WiFi и нескольких десятков WiFi точек доступа. Штукатурная сетка, появившаяся после радиопланирования и радиообследования объекта - добавила сложностей. Но в итоге всё кончилось хорошо - нас не расстреляли :)

Также на объекте создана проводная сеть Ethernet, обеспечивающая подсоединение всего оборудования: контроллеров автоматики, точек доступа WiFi, аудио-видео оборудования, камер видеонаблюдения. Для увеличения надёжности система разбита на сегменты VLAN.

Система фонового озвучивания обеспечивает простое воспроизведение музыки как с устройств Apple (через беспроводное Wi-Fi подключение, с использованием технологии AirPlay), так и воспроизведение интернет радио, CD, MP3 в зонах бассейна, SPA и веранды.

Что можно было бы сделать лучше.

По итогам эксплуатации считаю, что надо было настоять на использовании специализированных тач-панелей от производителя системы управления. Используемые в качестве сенсорных пультов управления выделенные iPad'ы в долговременной перспективе требуют к себе больше внимания, чем хотелось бы. То, несмотря на все настройки, обновляться соберутся, то ещё что-нибудь придумают :)

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

Заключение

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

Автор Кирилл Осовский, komrus@yandex.ru

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

Начинается всё просто, с уникальных числительных: Один, два, три ... восемнадцать, девятнадцать.

Десятки.

Дальше идёт образование десятков, добавлением к уникальному числительному окончания:

Два - два(дцать), три - три(дцать), четыре - четыре(дцать)? Нет. Сорок! Почему? Не спрашивайте.

Пять - пять(десят). Тут снова поворот. Очередное уникальное окончание для образования десятков, но кажется самое логичное - "десят". Пять десятков - пять(десят). Вроде неплохо звучит и даже логично. И не один я, видимо так подумал, потому что дальше идут: шесть(десят), семь(десят), восемь(десят)... и вот тут опять кто-то отвлёк дядю Фёдора и Шарик дописал - девяносто!

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

Может у кого-то и есть ответ на эти вопросы отличный от "так сложилось исторически", но мне он не известен. Было бы интересно послушать.

Но как бы то ни было, подытожим и обобщим, что мы имеем.

Мы имеем три группы:

1. Уникальное числительное + окончание обозначающее десятки (дцать, десят)

2. Совершенно уникальные названия десятков - сорок, девяносто.

3. Для каждого числа второго десятка используется уникальное название.

Едем дальше.

Сотни.

Сто, двести, три(ста), четыре(ста)... В этом моменте похоже опять вернулся дядя Фёдор и дописал - пять(сот), шесть(сот), семь(сот), восемь(сот), девять(сот).

Складывается впечатление, что работали в паре. Один старался всё сделать получше, пологичней, а второй ОЧЕНЬ креативный! Очень творчески подходил к выдумыванию каждого следующего названия. Не любил повторяться.

Имеем две группы:

1. Уникальное числительное + окончание обозначающее сотни (ста, сот)

2. Уникальные названия сотен - сто, двести.

Итого:

1. 19 (девятнадцать) уникальных числительных.

2. 8 (восемь) уникальных названий десятков. Не смотрите, что кое где окончания повторяются, нам всё равно нужно помнить название каждого десятка.

3. 9 (девять) уникальных названий сотен.

Ну, а если бы меня попросили сделать максимально простую, удобную и логичную систему?

Ну, что ж. Попробуем.

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

Сотни.

Самое массовое у нас окончание, "сот" - пять(сот), шесть(сот), семь(сот), восемь(сот), девять(сот). Оно же и самое логичное, "сот" - сотни. Ок. Значит его и оставим.

Получаем следующее: один(сот), два(сот), три(сот), четыре(сот), пять(сот), шесть(сот), семь(сот), восемь(сот), девять(сот).

Едем дальше.

Десятки.

Опять же, самое массовое, "десят" - пять(десят), шесть(десят), семь(десят), восемь(десят). Оно же, как и в случае с сотнями, самое логичное, "десят" - десятки. Определились. Оставляем его.

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

Получаем следующее: один(десят), два(десят), три(десят), четыре(десят), пять(десят), шесть(десят), семь(десят), восемь(десят), девять(десят).

Итого:

1. 9 (девять) уникальных числительных.

2. 2 (два) уникальных окончания обозначающие десятки и сотни ("десят" и "сот").

Вот и всё.

Мы получаем максимально простую, удобную, логичную систему.

P.S. На всякий случай, я не призываю устраивать революции или реформы. Я всего лишь проанализировал нынешнее положение дел глазами инженера и поразмышлял как бы могла бы быть решена данная задача, если бы за её решение изначально брался инженер.

Всего доброго!

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

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

В зависимости от разрешаемых проблем сейчас сформировались три направления применения накопителей в электрических сетях:

• поддержание нормативного уровня напряжения в распределительной перегруженной сети;

• обеспечение надежности энергоснабжения (резервный источник питания);

• замена протяженных незагруженных линий мобильными накопителями.

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

Поддержание нормативного уровня напряжения в распределительной перегруженной сети

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

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

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

Для решения этой задачи требуется:

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

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

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

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

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

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

Решение задачи тестировалось на трех распределительных сетях с количеством опор более 30. По результатам расчетов получились следующие выводы:

• Установка накопителя на первых опорах (5-10 опор ближайших к питающей подстанции) и последних опорах линии не позволяет поднять напряжение до необходимого уровня;

• Разница между минимально необходимыми для обеспечения заданного напряжения накопителями на разных опорах составила до 30% от энергоемкости выбранных для установки накопителей (в рассмотренных сетях это 15 кВтч или 1,5 млн.рублей при цене накопителей 100 тыс.руб/кВтч).

Обеспечение надежности энергоснабжения

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

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

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

• оценка времени устранения аварий на основании статистических данных в районе установки;

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

• прогнозирование изменения нагрузки резервируемых потребителей за время эксплуатации накопителя.

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

Решение этой задачи тестировалось на пяти потребителях. Расчеты показали, что за календарный год их максимальное потребление в четырехчасовом интервале составило не более 60% от потребления, которое можно было предположить, умножая на 4 часа мощность их технологического присоединения. Это позволило на 40% снизить энергоемкость накопителей.

Замена протяженных незагруженных линий мобильными накопителями

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

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

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

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

В части выбора минимально достаточной емкости, аналогично предыдущему применению, требуется:

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

• прогнозирование изменения нагрузки питаемы потребителей за время эксплуатации накопителя.

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

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

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

Клиент: крупный логистический центр в Московской Области, с которым мы работаем с 2016 года. За это время мы провели уже много работ по диспетчеризации инженерных систем, вывели в единую BMS вентиляцию, котельную, энергетику, отопление, энергоучет и много чего еще. А в этом году решили добавить еще и диспетчеризацию освещения в общую систему.

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

Задача поставлена, начинаем реализацию. Есть несколько способов отследить работу линии освещения. Самый простой способ это использовать свободный или дополнительный контакт модульного контактора. Но конкретно в нашем случае эта схема не сработает, так как питание катушки контактора идет от общего автомата и возможна ситуация, когда на линии освещения контактор будет замкнут, а автомат выключен и питания на линии не будет. Этот способ будет работать только если питание катушки контактора идет из под автомата этого же контактора. Можно было бы поставить дополнительные контакты положения и сработки к автоматам, это даст более полную картину, но в нашем случае места в шкафу не было от слова совсем и раздвинуть автоматы для дополнительных контактов просто не было возможности. Решили пойти самым надежным путем, взять непосредственно фазу, идущую на питание линии и завести ее на контроллер. Так как у нас большая часть автоматики на объекте сделана на отечественных Контарах, то мы просто взяли модули расширения, которые воспринимают 220 вольт на входе. Это не частая опция у контроллеров, поэтому, если бы стоял другой производитель, пришлось бы ставить 45 промежуточных реле. Получился аккуратный и не большой шкаф диспетчеризации, мы повесили его рядом с силовым шкафом и обвязали все аккуратно многожильным кабелем. Расключение шкафа и отключение света согласовали заранее, а на все работы ушло около 1,5 часов.

С физикой все просто и понятно, после всех работ мы имеем 45 булевых переменных, которые мы добавили в скаду, настроили им архивацию и оставили это все работать на неделю.

Дальше разрабатываем интерфейс пользователя.

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

На этом экране можно получить оперативную информацию о состоянии освещения. Есть отдельные окна трендов и настроек.

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

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

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

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

Вторая страница отчета выводит ту же информацию, но в виде диаграмм.

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

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

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

Что такое линия? Это повторяющаяся последовательность штрихов, точек и пробелов, наносимых вдоль прямой или кривой. Но, если заглянуть в ГОСТ, можно заметить, что линии не всегда являются только набором точек и штрихов есть и так называемые сложные типы линий, содержащие в себе текст или формы.

nanoCAD предлагает множество разных типов линий: линии из ГОСТ 2.303 уже предустановлены, есть и файл с линиями стандарта ISO. Кроме того, здесь можно создавать любые, самые нестандартные типы линий, причем это не отнимет много времени и сил. Чтобы в этом убедиться, погрузимся в волшебный мир линий и создадим две довольно сложные линии (рис. 2).

Впрочем, обо всем по порядку.

Все линии, используемые в nanoCAD, хранятся в папке SHX по пути C:\ProgramData\Nanosoft\nanoCAD x64 21.0\SHX и собраны в файлах с расширением *.lin. Открыть файлы можно в любом текстовом редакторе. Каждая линия задается собственным уникальным именем, в описании содержится информация о составляющих (штрихах, формах, символах). В одном lin-файле может храниться достаточно большое количество типов линий. По умолчанию в состав поставки входят следующие файлы:

• GOST 2.303-68.lin (содержит линии, соответствующие ГОСТ. Передавать этот файл следует вместе с файлом форм GOST 2.303-68.shx);

• ncad.lin (содержит линии, соответствующие международному стандарту ISO. Передавать этот файл следует вместе с файлом форм ltypeshp.shx).

Текущая на данный момент линия будет применяться практически во всех инструментах nanoCAD из группы Черчение: окружности, эллипсы, многоугольники, сплайны можно рисовать абсолютно любой линией (рис. 3).

Посмотреть, какая линия является текущей, а также переключиться на другую можно на функциональной панели Свойства, на вкладке Главная в группе Свойства, или в диалоговом окне Типы линий (вкладка Главная группа Оформление Типы линий) рис. 4.

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

Загрузить новую линию в текущий документ можно двумя способами (рис. 5-6):

• через панель свойств, в выпадающем меню Загрузить;

• через диалоговое окно Типы линий.

Важно! Чтобы загрузить сложные линии, нам нужно предварительно не только положить в папку SHX все используемые формы, но и создать текстовые стили, которые прописаны в линии. Узнать о том, какие текстовые стили используются в линии, можно с помощью любого текстового редактора.

Рассмотрим диалоговое окно Типы линий поподробнее. Здесь всё достаточно просто. В правой верхней части окна располагаются кнопки для создания, удаления, редактирования, импорта и экспорта линий.

Центральная часть представляет собой небольшую таблицу из трех столбцов:
Статус отображение текущей линии. Текущую линию можно установить переключением галочки.
Имя отображение имени линии. Здесь имя можно отредактировать, но переименование типа линии изменит его описание только в текущем чертеже в lin-файле название останется прежним.
Пояснение текстовое описание типа и примерное отображение линии.

Типы линий По слою, По блоку, Сплошная удалить или переименовать нельзя. Также нет возможности удалить текущий тип линии.

В графе Подробности (она располагается в нижней части окна) можно настроить работу с масштабами:

• Масштаб в единицах пространства листа полезная опция при использовании нескольких видовых экранов.

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

• Текущий масштаб задание масштабного коэффициента для вновь создаваемых линий. Результирующий коэффициент масштаба будет равен произведению глобального и текущего масштабов.

Создавать линии в nanoCAD можно двумя способами:

1. через встроенный редактор типов линий;

2. через любой текстовый редактор.

Конечно, мы опробуем оба способа. Линию Ньют создадим через встроенный, а линию Нюхль через текстовый редактор.

Рассмотрим, из чего будут состоять линии.

Линия Ньют (рис. 7).

Линия Нюхль (рис. 8).

• Штрих тире любой положительной длины.

• Пробел тире любой отрицательной длины (расстояние между соседними элементами).

• Точка штрих нулевой длины.

Вне зависимости от того, какой способ используется, все формы и шрифты должны быть у нас готовы/установлены, также необходимо заранее создать нужные текстовые стили. Текст Fantastic Lines (имя текстового стиля Fantastic Beasts) набран шрифтом Harry Potter, его можно найти на просторах интернета Создание формы SEGMENT было разобрано в статье Штриховки, файлы форм, или Как прикоснуться к искусству. В линии Нюхль используется шрифт romanc.shx с именем текстового стиля NIFFLER.

Давайте теперь наполним наш чемоданчик нужными формами!

Форма WAND.

Первое, что нужно волшебнику, своя волшебная палочка. Конечно, ее всегда можно одолжить у друзей или взять у автора, но, согласитесь, намного приятнее сделать собственную. Тем, кто уже знаком с формами (см. статью Штриховки, файлы форм, или Как прикоснуться к искусству), создать ее не составит особого труда. Моя волшебная палочка будет выглядеть достаточно просто примерно так же, как у Ньюта Саламандера из Фантастических тварей (рис. 9).

Как видим, она состоит из пяти дуг, двух параллельных и двух пересекающихся отрезков. Код такой формы показан ниже.

*1, 42,WAND00A, (3, 042),               ;дуга радиусом 3мм004, 16,                     ;умножаем длину следующего отрезка на 16080,                         ;отрезок длиной 128 с учетом масштаба003, 16,                     ;делим длину следующего отрезка на 1600A, (1, 064),               ;дуга радиусом 1мм008, (-128, 4),              ;отрезок со смещением00A, (3, 022),               ;дуга радиусом 3мм00A, (3, -042),              ;дуга радиусом 3мм; возвращаемся в предыдущую точку00B, (0, 3, 0,10, -022),     ;дробная дуга  00B, (253, 0, 0, 10, -002),  ;дробная дуга  004, 15,                     ;умножаем длину следующего отрезка на 15040,                         ;отрезок длиной 60мм003, 15,                     ;делим длину следующего отрезка на 16044,                         ;отрезок длиной 4мм04C,                         ;отрезок длиной 4мм; возвращаемся в предыдущую точку030,                         ;отрезок длиной 3мм044,                         ;отрезок длиной 4мм0                            ;конец определения формы

Форма NIFFLER.

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

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

*1, 89,NIFFLER014, 008, (-10,1), 034, 00A, (10, 004), 002, 003, 2, 010, 003, 5, 020, 074, 004, 10, 034, 001, 00C, (-14, -7, 126),02A, 040, 022, 00C, (6,-1,38), 01D, 040, 008, (1, 3), 002,003, 2, 018, 024, 004, 2, 001, 00C, (5, -4, 38), 0F0, 080,                   002, 0E8, 074, 001, 00A, 3, 000, 002, 018, 024, 003, 5, 014, 004, 5, 001, 00C, (-3, -5, 86),               002, 0F8, 0E8, 0F4, 024, 001, 00C, (6, -10, 30), 002, 094, 068, 001,00C, (3,-14,66),0

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

Форма COIN.

Эта форма похожа на монету и достаточно проста в написании (рис. 11).

Код формы представлен ниже.

*1, 21,COIN00A, (6, 000), 002, 028, 001,00A, (4,000),002, 028, 024,001, 048, 008, (2,-4),008, (2,4), 0

Чемодан для путешествий собран. Приступим к созданию линий!

Создание линии Ньют через встроенный редактор.

Чтобы открыть встроенный редактор, необходимо в диалоговом окне Типы линий выбрать линию и нажать кнопку Редактировать (рис. 12).

Строка Тип, расположенная в правой части окна редактора, позволяет выбрать тип элемента линии: штрих/пробел. В строке Длина выставляем + для штриха и - для пробела. В этом же окне указываем, текст это или форма, и задаем параметры элемента. Далее создается новый элемент.

Все параметры раздела Геометрия приведены ниже, в таблице Параметры вставки форм и текста.

В нижней части окна прописывается код линии.

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

Создание линии Нюхль через текстовый редактор.

Для более безболезненного переноса линий в будущие версии nanoCAD, а также для того чтобы избежать декодирования текста, рекомендуется добавлять собственные линии в раздел Пользовательские типы линий файла ncad.lin (файл расположен по пути: C:\ProgramData\Nanosoft\nanoCAD x64 21.0\SHX) (табл. 1).

Таблица 1. Структура содержания файла *.lin

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

Правила внесения элементов линий собраны в таблице 2, а параметры вставки форм и текста приведены в таблице 3.

Таблица 2. Внесение элементов линий

Таблица 3. Параметры вставки форм и текста

Рассмотрим разницу в применении параметров R и U (рис. 14). Попробуйте самостоятельно определить, где применяется параметр R=80, а где U=80?

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

• переключение между разными типами линий;

• загрузку новых типов линий;

• создание собственных линий разными способами.

Удачного проектирования! :)

Все материалы доступны по QR-коду.

Прямая ссылка на скачивание: https://ftp.nanosoft.su/file_57689705760cb43ed6a8d4

Асель Бексултанова,
технический специалист
по Платформе nanoCAD,
Нанософт разработка
E-mail: bexultanova@nanocad.ru