Приборы учета

Добро пожаловать в эпоху RISC-V!

Решения на базе открытого стандарта системы команд RISC-V всё чаще появляются на рынке. Уже в серийном производстве микроконтроллеры от китайских коллег, интересные решения предлагает Microchip с FPGA на борту. Растет экосистема ПО и средств разработки для данной архитектуры. Кажущиеся ранее непоколебимыми лидеры все чаще встречаются в объявлениях о перепродаже, а молодые стартапы привлекают многомиллионные инвестиции. Компания Миландр так же ввязалась в эту гонку и сегодня начала поставку заинтересованным предприятиям инженерных образцов своего нового микроконтроллера К1986ВК025 на базе процессорного ядра RISC-V для приборов учета электроэнергии. В общем картинки, характеристики и прочая информация, а также немного хайпа под катом.



Что такое RISC-V? Слава великому Хабру и его пользователям, которые уже написали много статей по данной теме, и избавили меня от этой участи. Посмотрите RISC-V с нуля. Так же можно ознакомиться с уже серийными изделиями от GigaDevice. А также с критикой и описанием недостатков RISC-V архитектуры со стороны сотрудников ARM.

Микроконтроллер К1986ВК025 на базе ядра RISC-V это второе поколение Миландровских микроконтроллеров для счетчиков электроэнергии. Первое поколение микросхемы К1986ВК2x разработаны на базе процессорного ядра ARM Cortex-M0 и выпускаются уже более 5 лет. На их основе сейчас выпускаются счетчики Милур.

Но время не стоит на месте и новые правила рынка диктуют новые требования к микросхемам. Нужно сделать больше функций новые требования по минимальному функционалу приборов учета. Нужно попасть в требуемую цену, так как конкурировать придется с монстрами типа TI и NXP. Также, если вы следите за этим направлением, то знаете, что новые интеллектуальные счетчики электроэнергии могут отключать электричество ограничивать потребление электроэнергии. А это значит новая система должна обеспечивать и информационную безопасность, чтобы злоумышленники не могли отключить или наоборот включить электричество по своему усмотрению. Все это привело к появлению новой микросхемы К1986ВК025, о которой сейчас и расскажем.

1. Основные характеристики К1986ВК025

Процессорное ядро RISC-V (BМ-310S CloudBEAR)
Тактовая частота 60 МГц
Напряжение питания (основное) 2,2...3,6В
Напряжение питания (АЦП) 3,0...3,6В
Напряжение питание (батарейное) 1,8...3,6В
Объем памяти программ Flash 256+8 Кбайт
Объем памяти ОЗУ 112 Кбайт
Объем однократно-программируемой ПЗУ 16 Кбайт
Метрологический измерительный АЦП сигма-дельта 24 бита, 7 каналов
Аппаратный блок вычисления показаний потребляемой энергии
Инструментальный АЦП 10 бит с датчиком температуры
Интерфейсы 5xUART, 3xSPI, 1хI2C
Число пользовательских выводов 55
Батарейный домен объемом 512 байт с часами реального времени и детектором фиксации проникновения
4 блока 32-разрядных таймеров с 4 каналами захвата событий и ШИМ
Сторожевой таймер
Блок подсчета CRC с изменяемым полиномом
Блок поддержки вычисления симметричных криптографических алгоритмов
Блок генератора случайных чисел
Блок детектора изменения тактовой частоты
Блок детектора изменения напряжения питания (основного и батарейного)
Блок оптического детектора
Блок генерации шума в цепи питания
Защитная экранная сетка
Интерфейс отладки JTAG
Тип корпуса QFN88 (10 х 10 мм)
Рабочая температура от минус 50С до +85С

Структурная схема

2. Процессорное ядро

Как уже было отмечено, сердцем микросхемы является 32 битное процессорное ядро RISC-V (в конфигурации RV32IMC) с обозначением BM-310, которое было разработано нашими хорошими друзьями из компании CloudBEAR. Это не единственное их процессорное ядро. Ребята предлагают целую линейку ядер, начиная от небольших микроконтроллерных ядер и заканчивая высокопроизводительными 64 битными многопроцессорными кластерами.



Компания Миландр ведет разработку новых продуктов на базе ядер из всех весовых категорий портфолио CloudBEAR. В кремнии сейчас доступны только К1986ВК025 на базе ядра BM-310. Но и другие продукты, в том числе на базе 64 битных ядер скоро увидят свет. Ядро BM-310 это 32 битное RISC-V ядро с трехстадийным конвейером, с возможностью выполнения операции умножения за два такта. Поддержка операций с плавающей запятой в данной версии микросхемы не была реализована (хотя ядро позволяет это реализовать). Производительность ядра BM-310 на тесте CoreMark составляет 3,0 CoreMark/МГц. Таким образом его можно сравнить с ARM Cortex-M3. При этом ядро в новой микросхеме занимает всего 0,3 мм2. А с учетом того, что большинство задач по вычислению параметров потребления электроэнергии выполняются аппаратно контроллером метрологического АЦП, то основная вычислительная мощность ядра может использоваться для коммуникационных задач в приборе учета.

3. Цена

Цена один из основных критериев для микросхемы. Основной вклад в стоимость микросхемы вносит кристалл. Чем больше его площадь тем дороже, чем более сложная технология изготовления тем он тоже дороже. Но при этом, чем более сложная технология, тем на меньшей площади можно реализовать требуемый функционал, а значит будет дешевле. В общем выбор технологии не всегда очевиден. Микросхемы первого поколения К1986ВК2x были разработаны на 180 нм. Примерно треть кристалла относилось к аналоговой части (собственно сами сигма-дельта АЦП, питание, IO) и при переходе на более тонкие процессы эта часть практически не уменьшается. Но в соответствии с новыми требованиям объем функционала должен быть увеличен практически в 4 раза. В новой микросхеме реализовано 256 Кбайт Flash против 64К, ОЗУ 112Кбайт против 16К, 5 блоков UART против 2, 3 блока SPI против 1 и еще криптография В общем, после долгих прикидок и расчетов было принято решение, что если уделить особое внимание площади, то на технологии 90 нм можно попасть в требуемый коридор стоимости, на технологиях 65 нм или ниже было бы легче, но бОльшие затраты на разработку в целом сделали бы проект более рискованным по финансам.

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

4. Метрологический АЦП

Если процессорное ядро это сердце микроконтроллера, то метрологическое АЦП это его мозг, так как именно он определяет предназначение микросхемы. В микроконтроллере реализован блок из 7 каналов 24 битных АЦП. Все каналы разбиты на три пары F0-F2 (канал напряжения и канал тока) для 3-х фазной сети и еще одного независимого канала тока (отнесен к F0). Каждый из 7 каналов оцифровывает входной сигнал с выходной частотой отсчетов до 16 кГц. Кроме этого, в каждой паре каналов F0-F2 реализована возможность рассчитывать среднеквадратические значения тока/напряжения, вычислять активную и реактивную мощности, вычислять потребленную активную и реактивную энергию, частоту сигнала в каналах напряжения, превышение пикового значения, падение сигнала ниже установленного уровня. Эти дополнительные блоки позволяют снизить нагрузку на процессор, что в свою очередь снижает потребляемую мощность всего кристалла. Так же каждый АЦП имеет независимый канал DMA, обеспечивая возможность сохранения данных в ОЗУ без участия процессора.

Список основных параметров и возможностей блока сигма-дельта АЦП:
7 независимых АЦП с выходной частотой отсчетов 4/8/16 кГц (4 канала тока и 3 канала напряжения). Эти каналы образуют 3 блока для измерения параметров каждой фазы F0-F2.
В блоке каналов F0 реализуем автоматический выбор канала тока (который имеет максимальное значение) для последующих расчетов мощностных характеристик. Если разница токов превышает 6%, то формируется прерывание. Кроме этой функции в остальном блоки F0-F2 идентичны.
Все каналы АЦП имеют независимые калибровочные коэффициенты наклона характеристики.
Каждый канал тока имеет независимый интегратор.
В каждом блоке АЦП (F0-F2) независимо рассчитывается период сигнала по каналу напряжения. Количество периодов, в течение которого рассчитывается эта величина, можно задавать равным 1/2/4/8/16/32/64/128 периодам.
В каждом блоке есть проверка на пропадание периодического сигнала в канале напряжения.
В каждом блоке проверяется просадка напряжения ниже заданного уровня, а также превышения сигнала в каналах тока и напряжения установленного лимита.
Есть возможность скорректировать фазы сигналов в каналах напряжения с точностью до 0,02%.
Вычисляются среднеквадратические, квадрат среднеквадратических значений токов и напряжений, а также их независимая калибровка.
При вычислении активной и реактивной энергии значение накопленной энергии в течение периода сохраняется в отдельных регистрах (для положительной и отрицательной энергии).
Вычисляются полная мощность и полная энергия.
Вычисляется сдвиг фаз по отношению к фазе 0.

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

5. Информационная безопасность

Как уже было отмечено ранее новые интеллектуальные счетчики электроэнергии должны уметь отключать потребителя от сети по соответствующей команде. Так же передача показаний потребленной энергии осуществляется автоматически по различным каналам связи. А это значит что вопросы информационной безопасности будут стоять особенно остро. В Постановление Правительства РФ от 19.06.2020 N 890 "О порядке предоставления доступа к минимальному набору функций интеллектуальных систем учета электрической энергии (мощности)" (вместе с Правилами предоставления доступа к минимальному набору функций интеллектуальных систем учета электрической энергии (мощности)) сформулированы минимальные функциональные требования для приборов учета электроэнергии. Но в части информационной безопасности они пока не сформулированы (ожидаются до конца 2020 года). Поэтому при разработке микросхемы мы опирались на требования ФСБ к средствам криптографической зашиты информации для некорректируемых регистраторов (СКЗИ НР). Реализованный функционал на наш взгляд избыточен, а если где-то и что-то и не предусмотрели, то можно реализовать это программно. Но в любом случае в части обеспечения специальных требований микросхема находится на уровне карточных и паспортных чипов. Поэтому в данной микросхеме реализуются все требования необходимые для бытовых электросчетчиков как в части собственно задач измерения,, она может найти свое применение и в других областях тахографах, электронных пломбах, идентификации и аутентификации элементов IoT. Всю спецуху в микросхеме можно разделить на две части криптография и инженерная защита.

5.1. Криптография

На микросхеме реализовано всё для защиты информации по ГОСТ Р 58940-2020 (СПОДЭС), в том числе:
Блоки сопроцессоров для поддержки блочных шифров Кузнечик, Магма и AES;
Блок генератора случайных чисел;
Блок вычисления CRC по произвольному полиному;
Блок специальной энергозависимой памяти ключевой информации с батарейным питанием
Однократно программируемая ПЗУ первоначального загрузчика, в которой реализуется уникальная идентификация каждой микросхемы.
Симметричная криптография реализуется на базе сопроцессоров, которые ускоряет самые тяжёлые операции. Это позволяет получить скорость шифрования с пиковой производительностью до 10 Мбит/с. При необходимости алгоритмы ассиметричной криптографии реализуется программным путем. В общем про идентификацию, аутентификацию шифрование, обновление прошивок нужно писать отдельную статью, что и сделаем потом.

5.2. Инженерная защита

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

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



Или чуть поближе



Для сравнения как защитная сетка выглядит в чипе для карточек от ST (серия ST23).


В случае физического нарушения целостности сетки так же формируется сигнал тревоги. Программное обеспечение должно контролировать все сигналы тревоги и в случае их возникновения фиксировать факт атаки. Так же микросхемы может быть настроена так, что бы криптографическая ключевая информация была автоматически стерта, при обнаружении фактов атаки. Все это требует обеспечения доверенности ПО. Для пользовательской программы в микросхеме реализовано 16 Кбайт однократно программируемой ПЗУ (по принципу анти-фьюз) и 256+8 Кбайт перепрограммируемой Flash. Запуск микросхемы происходить из встроенной однократно программируемой памяти. Изначально при изготовлении микросхем, данная память чистая, и для серийный изделий загрузка стартового доверенного загрузчика будет происходит при тестировании и отбраковке. Это позволяет обеспечить уникальную идентификацию каждой микросхемы, гарантировать целостность метрологического и криптографического ПО и являющаяся корнем доверия для пользовательской программы. А так же при необходимости обеспечить защиту от считывания пользовательской программы во Flash. На время исследования для инженерных образцов в стартовую память записан типовой загрузчик для серии 1986ВЕ. При необходимости может быть выпущена отдельная партия микросхем с стартовым загрузчиком адаптированым под задачи потребителя.

6. Средства разработки и документация

Предварительный вариант спецификации доступен по ссылке.

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

Это плата предназначена для прототипирования приборов учета, большое число ВЧ разъемов предназначено для подключения измерительных трансформаторов. Это позволяет не завязываться на какой-то конкретный их тип, и легко подключить именно те трансформаторы или шунты, которые применяют разработчики приборов учета. Так же это позволяет подключить различные измерительные приборы для снятия точностных характеристик АЦП. Кроме того отсутствие высокого напряжения (220В) на плате снимает с нас ответственность, если кого то стукнет. Для более массового продвижения микросхемы ведется разработка миниатюрной тестовой платы в формате arduino uno или mega.

6.1. Eclipse+GCC

Разработка программ может осуществляться в среде на базе Eclipce с компилятором GCC и отладкой через OpenOCD, GDB. Для отладки в среде Eclipse подходят классические отладчики J-Link и их клоны. Так же подходят отладчики производства компании Миландр.

6.2. IAR

Так же разработку можно осуществлять в более привычной для многих среде IAR Embedded Workbench, которая включает средства отладки, компиляции и оптимизации. Для отладки используются либо фирменный шнурок I-JET for RISC-V, либо если заказать Evaluation Kit for RISC-V, то вместе с ним вы получите I-jet Lite debug probe (который поддерживает в том числе и ARM), а так же 30 дневную лицензию на саму среду.

Более подробную информацию по настройке и запуску сред IAR и Eclipse для работы с микроконтроллером К1986ВК025 можно найти тут.

7. Что нужно для получения образцов

Это посылочки, тем кто ждет эти микросхемы, а так же тем, кто наоборот


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

Заключение

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

Добро пожаловать в эпоху RISC-V!

Введение

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

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

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

Дома строили большие по 20-25 этажей в среднем по 280-300 квартир в секции. Таких домов у застройщика на тот момент было порядка 10.

Приступив к работе, первым делом, я стал разбираться как же работают две системы, уже реализованные на строительных площадках заказчика. Это были две абсолютно разные системы: от протоколов передачи между сервером и полевым оборудованием (у одних CAN-bus, у вторых Modbus RTU и TCP), до самой архитектурой приложений (у одних самописное ПО раскатанное в облаке, у вторых СКАДА для каждого объекта с локальными компьютерами).

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

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

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

Первые решения и договоренности

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

1. Меня никто не знал, и никто толком не могу понять мои способности, я для них был вроде умный малый, но не самостоятельный и очень активный.
2. Если проект выгорает то я и разраб бэка и его собака в шоколаде! Все будет, как говорил мне директор 1.
3. Классная возможность попробовать свои силы.
4. Спасти Леху, он тогда гнил охранником на промышленном объекте.
5. У нас горели глаза от одной мысли, что мы можем создать нечто подобное.

Первый MVP

На радостях мы покупаем первый контроллер Siemens Modicon MT221 с ModBus TCP на борту, дня четыре писали на него программу на языке Ladder Diagram, в которой при замыкании контактов регистр меняется с 0 на 1, протестили с помощью программки Modbus Poll (грубо говоря Modbus TCP клиент), и тут Леха говорит:
На кафедре нас учили, что такие задачи решаются с помощью SCADA систем
На что я в ответ:
Леха, ты должен был бороться со злом, а не примкнуть к нему.
Мы решили сделать так Леха пробует найти СКАДУ и вытаскивать данные с контроллера и хранить их где то, а я попробую написать программу на Java, я как раз в тот момент проходил курсы Java Elementary (знал бы мой препод с курсов, что я буду пробовать кодить).

И по итогу Леха получил данные с контроллера по ModBus TCP первым, но сложил свой комп с синим экраном из за 4-6 СКАД на компе. А я при помощи Java и 5 строчек кода вытянул данные, Леше понравилось это и он погрузился в мир Java и я с гордостью могу сказать, что он стал очень хорошим специалистом.

Как сейчас помню, 10 марта 2018 года, мы приступили к первому объекту. У нас было 6 месяцев для написания программы, создания дизайна, выпуска проектной документации, монтажа и пуска.

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

Многие не верили в наш успех и не ставили нам конкретных задач, звучало это примерно так:

• вытащите данные из счётчиков
• отобразите где-нибудь

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

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

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

• нету аутентификации с разделением прав
• отсутствует возможность создать защищенный API к собранным данным
• дизайн из 90-х
• низкая производительность
• низкий уровень кастомизации backend логики
• неприемлемое ценообразование для решения выбранной задачи

Внутреннее чутьё подсказывало, что если мы будем использовать одну из этих систем, то мы будем ничем не лучше наших конкурентов. Что повело нас по другому пути, прекрасному пути. Мы пошли по пути написания своей системы и продукта на лучшем языке в мире Java и либы EasyModbus. А когда мы немного модифицировали код и заставили консоль сообщать о нажатии кнопки нашим радостям тогда просто не было предела. По дороге домой мы не могли успокоится и обсуждали, сколько нам это может дать возможностей! Мы создадим свою СКАДУ с красивым вэб приложением и умным домом. В тот вечер, мы нарисовали себе планов на год вперед. Но всё было еще впереди

Мы начали с малого, и месяц спустя у нас было готово ПО для контроллера управляющего температурой написанное на FBD. Нашим backend стэком были Java 8 + MySQL. Вскоре, были готовы классы для работы с нашими свободно программируемыми контроллерами. Еще через месяц мы успешно обкатали связку нашего backend'а и шлюза, который опрашивал тепловые счётчики по протоколу M-BUS. Научились работать с MySQL. Начали писать все полученные данные в базу. Для считывания показаний с электросчётчиков по RS-485 интерфейсу (PLC нам не подошел) мы сделали реверс-инжиниринг протокол из исходных данных с монитора USB порта.

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

Для того, чтобы показать начальству серьёзность наших намерений мы собрали стенд, который продемонстрировал работу нашей системы в масштабах всего дома. У нас было 20 контроллеров управления температурой, 150 датчиков температур, 60 тепловых счётчиков (сколько смогли раздобыть), 2 шлюза MBus, роутер и 16 маршрутизаторов. Мы 2 дня только обжимали FTP кабеля. В итоге стенд собран, ПО сконфигурировано, mock вебинтерфейса запущен директор едет к нам смотреть работу.


Первый стенд

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

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

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

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

Первый успех и сразу кастрюлей по лицу

Итак на первых парах успеха, уже реализуем 3 объект (на данный момент в системе крутится 2 котельные, 4 тепловых пункта, 4452 ед. различных приборов учета, данные с 1164 квартир), все хорошо, приложения не валяться, оборудование ведет себя очень хорошо, монтаж на высоте все круто, я и команда ждем премий и бонусовно, вместо этого просто Эгегей парни, молодцы, СПАСИБО!.


Пожал мне руку директор, сел в свой новый Х5 и уехал

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

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

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

Знакомлюсь с директором 2, и понимаю, что что-то не то, ну как могло быть по другому. Пару проведенных встреч и я понял, что директор 2 в 90-ые был программистом в армии и очень хотел реализоваться в этой области, он начинает нам рисовать схемы с местом диспетчера, с сервером 1С, кидать красивые слова, везде вставлять слово API, заказывать так необходимые в этот момент брендинги и бренд буки.

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

Продержались мы так месяц, точнее я продержался. Общался с директорами 1,2 только я, потому что моя цель была оградить мою команду от их постоянных встреч, постоянных попыток накидать каких то задач и прочей бюрократии. Вечно я слышал от директора 2: Чем занимаетесь? Что делаете?, мы в ответ: доменную модель пилим, тестим LoRa Wan, исследуем рынок в части лидеров мнений и канал реализации продуктов, делаем дизайн дашбордов для аварий и предупреждений, никаких конструктивных вопросов в ответ далее не поступало. Вечное недоверие и чувство дискомфорта, ну как тут продолжать создавать классный продукт.

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

Чувства и остаток

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

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

Выводы и советы

Выводы которые я сделал:

• Не зная броду не лезь в воду, особенно когда вопрос денежный. Все проверь, посчитай, прикинь cash flow, не ошибись в объеме работы и самое главное в технологии и целесообразности ее применения. Как бы не странно говори с командой, и не забывай про стратегию, пусть она будет сырая, не объемная, но она нужна.
• Страх неудачи постоянен, даже когда ты попробовал и у ты получил положительный результат. Нужно просто научится жить с ним, топить его чем то. Но всегда надо помнить, земля круглая, сегодня прет, завтра может быть картина другая.
• Семья это главное. Верьте своей семье.
• Не будет у вас на пути честных искренних людей, особенно в вопросах денежных. Ну хорошо будут, но мало.
• Если у вас есть возможность собираться в крутые команды и делать, что то что кому то нужно и вам это нравится, то делайте это, веселясь, радуясь, эмоционально споря, только так рождаются лучшие продукты.
• Учитесь работать с людьми бизнеса, нужно учится говорить с ними, понимать их, чувствовать их. Успех в деле зависит на 90% от отношений.
• Весь старый бизнес работает по каскадной методологии развития продукта, взять даже директоров 1 и 2, они строители и для них была дикость быстрее зарелизится с сайтом без нового брендинга, собрать фидбэк, аналитику и потом быстро внести правки в сайт. Нет, они давили, что сначала все надо проработать, точное ТЗ, и сидим потом кодим на протяжении 5 лет, как в СССР. Они не понимали, что время был тот фактор, который решал все (как раз в тот момент при общении с многими застройщиками я слышал, что они сами приступали разрабатывать свое ПО). Строители программисты это хуже скайнета из терминатора.
• Сразу договаривайтесь и оговаривайте все условия.

Что же дальше

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

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

Всем мира и успехов!