основные задачи и интерфейсы

ЧАСТЬ 3 – 10.

В этой ЧАСТИ мы проанализируем основные задачи и интерфейсы, попробуем сделать выбор для нашей разработки.

Часть 3.

Вступление.

Собственно, почему надо заниматься разработкой нового интерфейса? Для глупых – ответ простой и краткий – потому что! Для умных попробую обосновать:

  1. Системы ушли далеко вперёд. Это как с электрикой в квартирах, помните, 50 лет назад, когда в дома вводили электрику, мало того, что выделялось всего 3 КВА на квартиру, так ещё и без заземления. По крайней мере, в моей старой квартире, было именно так.
  2. Количество электроуправляемых и электродвижимых устройств в жилищах выросло многократно. Это естественно с переходом от газовых плит к электрическим, повсеместному развитию дополнительных устройств, например, кондиционеров. Простое сравнение количества электро-устройств в 1960-е – 1970-е годы с нынешнем временем даст коэффициент более 10-ти. О чём говорить, если даже швейные машинки тогда были механические! А бытовых кондиционеров не было как класс!!! По крайней мере массово.
  3. Количество функций у электроустройств выросло многократно. Сравните стиральные машины того периода (3 передачи, не считая отжима J), и сегодня.
  4. Ещё множество устройств надо разработать: медицинские анализаторы, садовые, фермерские или сельско-хозяйственные роботы, системы анализа качества жизни (анализ качества воды, воздуха, …) и многое, многое другое.
  5. Реальное количество протоколов, возможных для использования в быту множество. Но все они изначально разрабатывались коммерческими организациями для коммерции. А в быту много не заработаешь, и потому все они имеют корпоративно-офисный уклон в лучшем случае. У нас же изначально разработка получает статус «бытовой» и «народной», что должно наложить свой отпечаток на видение системы.

 

Для начала просто фантазии.

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

– управление нагрузками (свет, дверь, ворота, жалюзи).

– дистанционное управление замками помещений с ограничением доступа (папа-контроль).

– управление RGB-освещением (внешним или внутренним).

– управление климатом. (подогрев/охлаждение воздуха)

– подача свежего воздуха. (в коттедже рекуперацией).

– поставить датчики газа, огня, дыма.

– поставить датчики на проникновение – на окна и двери.

– поставить датчики на присутствие в помещении.

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

– поставить датчики на качество воздуха.

– поставить датчики на температуру воздуха внутри и снаружи помещения.

– поставить датчики на свет.

– поставить датчики на температуру поступающей воды.

– датчики анализаторы звука (мама-контроль младенцев).

– дистанционный запуск в работу роботов уборщиков или поливщиков.

– кормление животных (сухой корм).

– автоматизация поилки для животных.

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

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

– поставить станцию с датчиками анализа жизнедеятельности человека. (сон, бодрствование, активная ходьба, ритм, давление, моча, кровь).

Не устали? Это первый набросок.

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

 

Часть 4.

Обязательный минимум датчиков.

 

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

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

  1. Энергетика. Наша страна Россия, у нас принят за стандарт напряжения в магистральной сети или 220 Вольт 50 Гц с мощностью до 15 КВт, или 380 Вольт 3 фазы 50 Гц с мощностью более 15 КВт. Качество напряжение должно соответствовать принятым техническим нормативам. На вводе ставится распределительный щит с защитными автоматами разных систем. Наше оборудование будет запитываться после силового распределительного щита и так же после силового щита мы будем управлять всеми системами.
  2. Газ. Подача газа в дома городские и загородные так же производится по определённым стандартам. Стандартное подключение подразумевает внешний запорный клапан, счётчик и насос. Наше оборудование будет ставиться после и управлять насосом и клапаном перекрытия подачи газа.
  3. Датчики. Пока вольные фантазии. НО!
    • На кухне и в котельной дома (квартиры) минимум по датчику газа.
    • В каждом помещении дома (квартиры) минимум по два датчика огня и дыма. Количество датчиков огня и дыма определяется нормативами пожарной безопасности.
    • В каждом помещении дома (квартиры) минимум два датчика температуры.
    • В каждом помещении минимум два датчика освещённости.
    • В каждом помещении дома (квартиры) по два датчика качества воздуха.
    • В каждом помещении дома (квартиры) по два датчика температуры теплоносителя.
    • В каждом помещении дома (квартиры) по одному датчику протекания теплоносителя под каждой батареей отопления.
    • В каждом помещении дома (квартиры) на каждом окне по два датчика на проникновение. (изменение положения, угол открытия).
    • В каждом помещении дома (квартиры) на каждой двери по одному датчику на открытие. (изменение положения, угол открытия).
    • В каждом помещении дома (квартиры) на каждом управляемом замке датчик состояния замка.
    • В каждом помещении дома (квартиры) по два датчика на присутствие.
    • По два датчика температуры и освещённости, установленные по разные стороны дома.
    • Входы внешнего аналогового сигнала диапазона 0-10 Вольт от датчиков.
  4. Электрически управляемые клапаны на перекрытие:
    • Подачи газа в помещение.
    • Подачи холодной и горячей воды в помещение.
    • Подачи электроэнергии в помещение, кроме дежурных систем.
  5. Электрически управляемые клапаны на регулировку температуры в помещениях.
  6. Командно-информационные конвертеры для управления кондиционерами.
  7. Командно-информационные конвертеры для управления котлами обогрева.
  8. Реле управления нагрузками разной мощности.
  9. Диммеры управления нагрузками разной мощности.
  10. Аналоговые сигналы управления внешними регуляторами нагрузки.

Продолжать можно до бесконечности … .

 

Часть 5.

Сказ о точности.

 

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

Идя по пути максимального упрощения системы, для начала, я бы предложил точность оцифровки в 1%, что вполне может обеспечить обычный 8-ми битный АЦП. Да и в плане передачи – одного байта как раз хватило бы.

Достаточно ли измерять температуру в диапазоне 100 градусов с точностью в 1 градус?

Достаточно ли измерять напряжение в сети 220 Вольт с точностью в 2 Вольта?

Достаточно ли измерять пульс с точностью в 1 удар в минуту.

Мне кажется, что для простой бытовой системы вполне!

Но вернусь к ранее сказанному – мы обеспечиваем будущее. Хватит ли 1% точности? А ведь при обработке двух данных, например, при расчёте мощности мы используем данные по напряжению и току с точностью 1%, после обработки общая точность ухудшается, как минимум в два раза. Если осмотреться для аналогии и примера – далеко ходить не надо – ваттметры старых типов, с точностью измерения 1,5-2,0 % запретили к употреблению.

Поэтому сразу принимаем, что оцифровка будет минимум 10-ти битная, оптимально 12-ти, максимально 14-ти. Для передачи такого объёма данных уже потребуется 1,5 байта, т.е. не полных 2.

Для ещё большего расширения диапазона обрабатываемых сигналов нужно предложить информирование системы об изменение диапазона измерения, кратное 10-ти. Мы помним, что расширение диапазона измерения кратно 1000 эквивалентно использованию 20-ти и более битному использованию АЦП. Поскольку мы понимаем в каком диапазоне происходят измерения, мы информируем об этом систему, сами же ничего не меняем.

Для измерения напряжений, максимальное значение может быть таким:

– 1000 Вольт – при измерении напряжений 380, 220, 110 Вольт. Сетевое напряжение.

– 100 Вольт – при измерении напряжений 12, 27, 30, 48 Вольт. Альтернативная энергетика.

– 10 Вольт – при измерении напряжений на платах управления, прочей технике.

– 1 Вольт – сами придумайте, у меня фантазия закончилась. 😉

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

– 100 Ампер – при измерении токов в регуляторах мощностью до 40 КВт.

– 10 Ампер – при измерении токов в регуляторах мощностью до 4 КВт.

– 1 Ампер – при измерении токов в регуляторах мощностью до 400 Вт.

– 0,1 Ампер – при измерении токов в регуляторах мощностью до 40 Вт.

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

Окончательно: внешние данные будут оцифровываться с точностью минимум 10 бит, максимум 14, с предоставлением 2 бит на указание диапазона измерения.

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

Если только на предоставление аналоговых данных нам требуется передать или принять как минимум 2 байта информации, сколько же всего информации нужно передавать?

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

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

Пример 1.

Мы измерили с 12 битной точностью напряжение 380 Вольт. Для того, чтобы передать результат с 12-ти битной точностью, нам придётся потратить 2 байта. С другой стороны, мы можем сузить диапазон передаваемых данных. Как известно напряжение в сети не должно отличаться более чем на 10%, т.е. для 380 Вольт разброс составит от 340 до 420 Вольт действующего значения напряжения. Получается мы можем передавать данные в диапазоне 420-340=80 единиц. Передавая 80 единиц в объёме одного байта, т.е. 256 бит, мы получим точность не хуже 0,33 Вольт (80/256=0,31), что гораздо лучше 1%. Для сравнения, напряжение до 1000 Вольт оцифрованные с точностью в 12 бит (4096 уровней квантования) дают разрешение 0,24 В (1000/4096=0,24), а с оцифровкой тех же 1000 Вольт с точностью в 1% – дают разрешение в 10 Вольт!!!

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

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

Пример 2.

То же самое, но напряжение 220В и разброс +/-15%.

Передаваемый одним байтом диапазон напряжений в рамках 260-180=80 Вольт.

Точность оцифровки та же – 0,24 Вольт, фактически 0,1%.

Пример 3.

Возьмём пример ну совсем из другой области – замер температуры человека.

Поставим рамки: верхняя 42 градуса по цельсию, нижняя 34 градуса по цельсию.

Предположим цифруем с верхней границей 100 и точность характерная для 12-ти битного квантования. Тогда оцифровка у нас будет происходить с точностью в 0,024 градуса (100/4096=0,024). Дикая точность, но пока это опустим.

Если мы будем температуру передавать в объёме 1-го байта и с диапазоном 42-34=8 градусов, итоговая точность при передаче окажется на уровне 8/256=0,03.

Снова цифры сопоставимы!!!

 

Решено! Для оперативной передачи информации будем использовать:

  1. Предварительно обработанную информацию, зажатую в определённые нами рамки.
  2. Использовать для передачи только один байт информации.
  3. Использовать для передачи информацию в полном, необработанном виде, только по требованию, или при выходе за указанные нами рамки.

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

Пример 4.

Передача информации об уличной температуре. Диапазон +/-50 градусов по цельсию! Т.е. полный диапазон 100 градусов. При передаче в одном байте мы не сможем получить точность лучше 0,39 (100/256=0,39) градусов по Цельсию. И у меня почему-то подозрение, что нам вполне для наших целей хватит точности в 0,5 градуса!

Пример 5.

Оцифровка и передача информации об атмосферном давлении. Давление меняется в диапазоне от 715 до 795 мм. ртутного столба. Если мы будем цифровать с потолком в 1000 и точностью в 12 бит, мы получим результат с точностью в 0,24 единицы и объёмом для передачи в 2 байта.

Используя уже наработанное решение, мы получим к передаче 80 единиц, для передачи в одном байте с сопоставимой точностью!

Почему это важно?

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

 

Часть 6.

На чём поедем?

 

В общем надо двигаться вперёд.

В ЧАСТИ 3 мы рассмотрели возможности передачи команд в интерфейсе Х10. Напомню из чего состоит информационный «паровозик»:

– 4 бита – СТАРТ

– 4 бита на передачу «код дома»

– 4 бита на передачу «код устройства»

– 4 бита на передачу «команды»

Напомню, что комбинации 4 бита нам дают 16 отдельных точек – не важно, это указатель адреса или команды. Как итог, учитывая «код дома» и «код устройства», мы можем обратиться максимум к 256 различным устройствам (16Х16=256), которым можем дать 16 различных команд.

Вопрос: на сегодняшний день хватит ли нам такого ограничения? Ответ однозначен: нет!

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

Рассматривая Х10 можно предположить, что надо как минимум удвоить количество бит, не только для выбора «кода дома», но и для «кода устройства». То же самое можно сказать и о количестве «команд», предлагается также количество бит увеличить с 4 до 8. При этом можно будет диммером установить уровень яркости при 256 градациях (8 бит) гораздо точнее, чем при 16-ти градациях (4 бит). Соответственно, при запросе состояния устройства – информация так же пойдёт в более информативном – 8-ми битном представлении.

Могло бы получиться:

– 8 бит – СТАРТ

– 8 бит на передачу «код дома»

– 8 бит на передачу «код устройства»

– 8 бит на передачу «команды»

И вроде всё идёт не плохо, но только до той поры, как только встанет первый вопрос: передача аналоговых сигналов управления. А это сразу добавляет минимум 8 бит. Как пример: команда «повернуть по часовой стрелке», величина 135 градусов. Буйная фантазия добавит ещё проблем и вопросов, а соответственно байт в посылке.

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

Хватит ли нам адресации на 256 устройств. В пределах одной квартиры – ДА! В пределах коттеджа – НЕТ. Для коттеджа вполне должно хватить 1000 – устройств. Это 4 системы по 256 устройств – в связке.

Х10 отпадает. Есть ли что-то похожее из известных систем, которое бы нас, хоть в чём-то, удовлетворило? Конечно есть. Каждый из специалистов, освоивших до этого какую-либо систему, ответит утвердительно. Мне, например, проще предложить C-Bus. И действительно (далее технические данные системы C-Bus):

100 устройств в сети.

255 сетей в одной системе.

25.500 устройств в системе.

Достойные цифры! И уже гораздо ближе к тому, что нам требуется. Но снова мы упрёмся в проблему скорости. Всего 9600 бит в секунду. Когда на кабеле сидит 100 устройств, теоретически получается 96 бит (12 байт) в секунду на одно устройство в сети. Это в идеале, без коллизий, и без времени ожидания «тишины». Но мир не идеален, и коллизии случаются. Сами поставщики оборудования C-Bus, кулуарно, рекомендовали не более 20 устройств на шине, а это при наличии 255 сетей (255Х20=5100) около 5 тысяч устройств.

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

К тому же, если Вы внимательнее будете читать документацию на RS-485, то Вы найдёте причину использования скорости 9600 бит в секунду. Оказывается, именно на этой скорости, сигнал можно с минимальными искажениями передавать на максимальную длину, практически не используя согласующие сопротивления (резисторы, терминаторы). Т.е. производители пошли по пути наименьшего сопротивления, выбрав рекомендуемые параметры для работы кабеля на максимальное расстояние. Это же позволяет нам сделать вывод о том, что если мы не используем большую длину, а именно это ограничение я хочу наложить, то можно значительно увеличить скорость на шине.

Я предлагаю установить ограничение в 100-200 метров, стандартное для сетей EtherNET, гарантирующее, при согласовании линии, передачу качественного сигнала. При этом скорость на шине можно поднять минимум в 2 раза, найдя компромис между качеством сигнала, и возможности обрабатывания сигнала бюджетными микроконтроллерами (МК).

Когда-то очень давно, я предположил, что всю систему целиком надо строить на интерфейсе EtherNET – 10MBit-Cat5-RJ45, как наиболее доступном и массовом. По условиям, в одной подсети может быть до 65 тысяч устройств, и мы предположили, что каждая кнопка, каждый выключатель, каждое реле, каждый диммер будет отдельным устройством на шине со своим IP-адресом. Скорость в сети известна и гарантирует практически моментальную доставку любых команд к исполнительным устройствам.

Но когда мы, фантазируя по поводу параметров новой сети, сели и подсчитали по максимуму количество командных и исполнительных устройств (контроллеров), стало понятно, что система будет монстроподобной, а соответственно ненадёжной. Т.к. для соединения между собой устройств в сети EtherNET требуются коммутаторы, то для строительства системы потребовалось бы очень много, самых многопортовых из возможных, коммутаторов. Потребление в системе только коммутаторами, сведёт задачу повышения энергоэффективности на нет. Надо признать, что тогда, 15 лет назад, EtherNET коммутаторы потребляли то же весьма не хило, и периодически «подвисали».

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

Мы понимаем, что эти решения, и EtherNET, и RS-485, созданы для выполнения разных задач. Есть понимание, что EtherNET высокоскоростная шина, для работы которой требуются дополнительные обслуживающие устройства – коммутаторы. Т.к. для работы большей части систем автоматики и управления не требуются очень высокие скорости (ну относительно 9600 бит/сек), нам остаётся только свой взор переключить на RS-485.

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

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

– максимально бюджетной.

– максимально простой.

– на низовом уровне возможной в изготовлении буквально в гараже.

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

– легко осваиваемая в управлении и программировании как молодёжью, так и зрелыми пользователями.

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

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

 

Если просмотреть большинство систем «умного дома» – на первом месте везде идёт управление освещением. Поддержим эту бредовую традицию.

  1. Управление освещением. Для этого понадобиться как минимум два устройства: «кнопка» и связанное с кнопкой «реле». Естественно они должны быть связаны между собой.

Представим, что мы решаем задачу на уже существующих системах. Тогда:

– на Х10, Lon, C-Bus, HDL, …, от контроллера, работающего от кнопки, команда пойдёт к контроллеру, который включает лампочку.

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

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

Тогда мы можем задаться вопросом – а надо ли нам всё сажать на одну шину?

Когда мы занимались инсталяцией «умных домов» мы так и делали. Причина этого в экономии! Всё сажали на одну шину. Да и сами установочные комплекты были не такие масштабные, поскольку были дорогие. Всё это приводило к тому, что командный кабель начинался у силового щитка в подвале коттеджа, опоясывал все помещения, выходил из дома, и уходил, куда-то вдаль, то ли к бане, то ли к воротам. Как в старом, пошлом анекдоте про «три разА вокруг ноги, попадаем в сапоги». Сорри!

Можно ли упростить? Работа на шине значительно упрощается, если выполнить всего два условия:

– укоротить длину шины. Не нужен нам этот километр, если мы занимаемся домами/коттеджами/мини-фермами. Это одновременно позволяет повысить скорость. Мы это уже начали обсуждать.

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

Достичь этого можно очень легко, для чего:

– уменьшаем площадь охвата контролируемой одной системы контроллеров. Ограничение на длину интерфейсного кабеля – 100-200 метров!

– увеличиваем степень интеграции контроллеров, для чего повышаем степень выполняемых ими функций. В одном корпусе до 10 (число может отличаться) исполняемых функций!

Единственная сложность вылезает в желании выполнить команду «выключить всё!», поскольку часть управляемых контроллеров оказывается на другой шине. Что бы выполнить и это условие – нужно соединить между собой контроллеры с разными шинами, т.е. одна шина внутренняя, для командно-исполнительных устройств, а другая шина внешняя, для соединения устройств разных сетей в одну единую. Причём если внутренняя сеть может быть низкоскоростной, на основе RS-485, то внешняя может быть любой, в том числе и EtherNET.

 

Часть 7.

Трёхслойный пирог.

 

У нас может получиться пирог с трёхслойной структурой (фантазируем):

 

  1. Первый слой самый низовой. Связь в рамках одной подсети.

Предполагается шина – RS-485.

Максимальное количество физических устройств на шине – 32.

Максимальная длина шины – 100-200 метров.

Физическое исполнение шины – минимум – кабель Cat5.

Конфигурация шины – линия. Возможно дерево с соотношением боковых ветвей к основной шине как не более 1/30.

Скорость шины – до 62,5 КБит/сек.

За счёт высокой интеграции, где каждое устройство может выполнять до 10-ти функций, или управлять 10-тью устройствами, фактически получаем возможность управления минимум 256-тью устройствами. (Не все устройства можно напичкать по полной!).

 

  1. Средний слой, некий промежуточный. Связь между подсетями.

Предполагаемая шина – RS-485.

Максимальное количество объединяемых подсетей – 4.

Максимальная длина шины – 100-200 метров.

Физическое исполнение шины – Cat5.

Конфигурация шины – линия. Возможно дерево с соотношением боковых ветвей к основной шине как не более 1/30.

Скорость шины – до 62,5 КБит/сек.

 

  1. Верхний слой – слой глобального объединения.

Предполагается шина – EtherNET.

Максимальное количество устройств на шине – не ограничено.

Максимальная длина шины (по стандарту) – 100 метров.

Скорость шины – 100 МБит/сек*.

Физическое исполнение шины – Cat5*.

Конфигурация шины – коммутация каждого порта через коммутатор (свич) EtherNET.

 

Маленькая информационная ремарка по поводу низового уровня и максимального количества устройств на шине, и среднего уровня и максимального количества подсетей. Как и в других параметрах, в этих приходится искать компромисс между удобством, компактностью и охватом. Здесь мы отталкиваемся от того, что у нас «адрес» физически представляется байтом информации – т.е. 8 бит, с максимальной адресацией в 256 направлений. Но мы ранее сами себе ввели ограничение, что в первичной, низовой сети у нас будет не более 32-х блоков, на указание чего требуется всего 5 бит. Оставшиеся 3 бита могут организовать адресацию внутри устройств, мы же говорили о плотной компоновке устройств.

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

 

Часть 8.

Начало обсуждения длины посылки.

 

Мы обсудили физический уровень. Попробуем обсудить протокол.

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

Например, посылка может состоять из следующих бит (предварительно):

– 8 бит – СТАРТ

– 8 бит на передачу «код дома», помним, что это 5 бит на код устройства и 3 на код внутри устройства.

– 8 бит на передачу «код устройства»

– 8 бит на передачу «команды»

Пока нам вроде для счастья хватает 8+8+8=24 бит. Без «СТАРТ» бита. Но!!!

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

Разберём подробнее. Если мы используем диммер, то 8-ми битным кодом мы можем однозначно задать один из уровней его 256-ти градаций включения, от 0, т.е. выключено, до 255, т.е. открыт на 100%.

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

Так же мы можем отправлять команду на предоставление данных. Минимум 2 бита.

– Какие команды мы можем давать? Включение/выключение, включая уровень градации.

– Запрос на предоставление данных.

– Переключение режима работы устройства (дистанционное переключение параметров).

– Дистанционный апгрейд ПО.

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

– 8 бит – СТАРТ

– 8 бит на передачу «код дома»

– 8 бит на передачу «код устройства»

– 8 бит на передачу «команды» или «функции»

– 8 бит – величина выполнения функции

– 8 бит – задержка отсроченного выполнения.

В таком достаточно скромном виде, без учета стартового байта и кода «дома», команда занимает 6 байт.

Как и ранее, учитывая будущие потребности, просто увеличим длину до 8-ми, и на время успокоимся. J

К тому же имея длину передаваемой информации в 8 байт, мы не нарушаем возможности лёгкой конвертации сигнала в одну из перспективных для нас шин – CAN.

Окончательная предлагаемая к реализации конфигурация посылки:

1 байт – старт

1 байт – «код дома»

8 байт – содержание посылки

1 байт – код содержания посылки (младшие разряды суммы 8-ми байт содержания посылки).

1 байт – стоп

Всего посылка занимает 12 байт.

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

 

Часть 9.

Скорость. Устройства быстрые и медленные.

 

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

Мы, в самом начале, решили, что система физически может содержать до 32 устройств.

Если бы мы просто использовали работу в режиме Master-Slave, у нас на каждое устройство приходилась бы одна как отправка посылки, так и одно получение. При 32-х устройствах, мы ожидаем циклическое прохождение в обе стороны 64 посылок, т.е. 32-е в одну сторону и 32-е в обратную.

И вопрос не в том, что должно проходить 64 посылки, а в том, насколько быстро они должны проходить? Предположим, что в бытовых условиях, человеку вполне комфортно, если реакция на какое-либо его действие, не составит более 0,1 сек. Самый простой пример – управление освещением. Если реакция на нажатие кнопки будет большой, это может вызвать дискомфорт у пользователя. Поэтому примем как оптимальное время реакции в 0,1 сек.

Если время реакции не должно превышать 0,1 сек, то на одну посылку приходится 0,1/64=0,0015 сек, или 1,5 милисекунды.

Одна посылка состоит из 12 байт, или 96 бит. Тогда на один бит не может приходится более 1,5 милисек / 96 = 15 мксек (приблизительно). Что даёт нам требующуюся скорость передачи 67 Кбит/сек, что превышает расчётные максимальные параметры (62,5 Кбит/сек).

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

«Быстрые» – те устройства, реакция на взаимодействие с человеком у которых настолько быстра, что практически условно малозаметна.

«Медленные» – те устройства, время реакции на взаимодействие с человеком у которых не влияет на состояние системы, не актуально для отклика человека, не вызывает дискомфорт при взаимодействии. Примем время реакции условно не более 10 сек. Как пример: нам не важна скорость получения системой для обработки таких параметров как температура, влажность, освещенность, прочее… . Система делает регулярный опрос, и получение этих данных с задержкой на 10 секунд ни на что не повлияет.

Сделаем предположение, что ¼ устройств у нас относятся к первой категории – «быстрые». А ¾ устройств, относятся ко второй категории – «медленные».

Примем, что быстрые от медленных отличаются только тем, что общение с «быстрыми» происходит постоянно, а общение с «медленными» выстроено в длинную цепочку. Для понимания процесса посмотрим на табличку, отражающую суть происходящего. Изначально принимаем, что из 32-х устройств 1-ое является Master, и в таблице не отражается, остальные 31 Slave. В таблице каждая клетка, это общение Master с соответствующим устройством «Slave», номер которого соответствует цифре, поставленной в клетку, кроме последнего столбца. Он указывает на то, что каждый раз происходит общение с разным «медленным» устройством, в соответствии с заложенным алгоритмом.

 

Slave Slave Slave Slave Slave Slave Slave Slave 9 – 32
2 3 4 5 6 7 8 9/ 17/ 25
2 3 4 5 6 7 8 10/ 18/ 26
2 3 4 5 6 7 8 11/ 19/ 27
2 3 4 5 6 7 8 12/ 20/ 28
2 3 4 5 6 7 8 13/ 21/ 29
2 3 4 5 6 7 8 14/ 22/ 30
2 3 4 5 6 7 8 15/ 23/ 31
2 3 4 5 6 7 8 16/ 24/ 32

 

По табличке видно, что на один полный цикл для «быстрых» устройств составляет 1/8 от полного цикла (от времени прохода одной строки таблицы)

 

Если кому-то не понятно, дам таблицу в развернутом виде, где цикл «медленных» устройств, с номерами 9-32, в последнем столбце, виден не вооружённым взглядом.

 

2 3 4 5 6 7 8 9
2 3 4 5 6 7 8 10
2 3 4 5 6 7 8 11
2 3 4 5 6 7 8 12
2 3 4 5 6 7 8 13
2 3 4 5 6 7 8 14
2 3 4 5 6 7 8 15
2 3 4 5 6 7 8 16
2 3 4 5 6 7 8 17
2 3 4 5 6 7 8 18
2 3 4 5 6 7 8 19
2 3 4 5 6 7 8 20
2 3 4 5 6 7 8 21
2 3 4 5 6 7 8 22
2 3 4 5 6 7 8 23
2 3 4 5 6 7 8 24
2 3 4 5 6 7 8 25
2 3 4 5 6 7 8 26
2 3 4 5 6 7 8 27
2 3 4 5 6 7 8 28
2 3 4 5 6 7 8 29
2 3 4 5 6 7 8 30
2 3 4 5 6 7 8 31
2 3 4 5 6 7 8 32
2 3 4 5 6 7 8 9

 

 

Рассчитаем нужную скорость обмена «быстрыми» посылками, получим (приблизительно):

0,1 сек / 16 = 0,006 сек.

0,006 сек / 96 = 0,065 милисек. Или переведя в частоту приблизительно 20 КГц, фактически должно хватить используемой многими устройствами скорости 19200 Кбит/сек.

Время обмена «медленными» посылками при этом будет хуже в 24 раза, что составит соответственно 0,1 * 24 = 2,4 сек, что тоже укладывается в наши первично заложенные требования.

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

  1. Протокол RS-485
  2. Топология – шлейф, возможность ответвлений с соотношением не хуже 1/30
  3. Скорость не менее – 19,2 кбит/сек
  4. Максимальное количество физических устройств на шине – 32
  5. Физическое исполнение шины – кабель не хуже Cat5
  6. Подача питания на устройства – по интерфейсному кабелю. Предварительно 12В.
  7. Режим Master-Slave с одним Master и множество подчинённых Slave.
  8. Подача питания в шину устройствами, осуществляющими управление силовыми элементами.

Часть 10.

Второй уровень.

 

С низовой часть интерфейса вроде бы всё понятно.

Начнём подниматься выше.

Средний слой, некий промежуточный. Связь между подсетями. Задумывается как:

Предполагаемая шина – RS-485.

Максимальное количество объединяемых подсетей – 4.

Максимальная длина шины – 100-200 метров.

Физическое исполнение шины – Cat5.

Конфигурация шины – линия. Возможно дерево с соотношением боковых ветвей к основной шине как не более 1/30.

Скорость шины не менее – 19,2 кбит/сек.

Фактически это такое же исполнение, как и нижняя часть. Мы снова, для упрощения, отказываемся от сложных интерфейсов, выбираем простой и знакомый RS-485, с режимом Master – Slave. Здесь, вроде бы, единственная сложность – выбор главного, ну самого главного, старшего над остальными главными.

Решение видится в двух вариантах:

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

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

Торможу с дальнейшим описанием, развитие покажет.

Автор: Фонин Павел Николаевич (Besm-2000тм)
Контакт: smart@besm.ru

0

Автор публикации

не в сети 1 месяц

Pavel

0
Комментарии: 0Публикации: 6Регистрация: 26-07-2021

Добавить комментарий