Прошивка. Логика работы

АПК Синапс v1.0. ПО. Спецификации на разработку

Последнее изменение: 22.12.2025, 12:24 МСК

1. Назначение документа

Дать разработчику исчерпывающее понимание логики работы прошивки контроллера АПК Синапс.

2. Базовые документы

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

• SynapsePDS_FW — описание прошивки контроллера
• SynapsePDS_FW_DB — структура базы данных прошивки
• SynapsePDS_USML — протокол обмена данными

3. Дочерние документы

Подробное описание логики работы прошивки разделено на следующие документы:

• SynapsePDS_FW_Logic_Phone — Взаимодействие с телефоном
• SynapsePDS_FW_Logic_PNR — Пуско-наладочные работы
• SynapsePDS_FW_Logic_Settings — Настройка
• SynapsePDS_FW_Logic_Control — Оперативное управление
• SynapsePDS_FW_Logic_Buttons — Управление настенными кнопками
• SynapsePDS_FW_Logic_Sensors — Автоматическая работа по датчикам
• SynapsePDS_FW_Logic_Schedule — Работа по расписанию
• SynapsePDS_FW_Logic_Case — Корпус контроллера

4. Термины и определения

4.1. FW-USM (Unit System Model прошивки) — виртуальная модель системы освещения в прошивке. Представляет собой набор массивов структур языка С, хранящих состояние всех устройств DALI-линии, настройки локаций, групп, действия, расписание и другие данные. Структура описана в SynapsePDS_FW_DB.

4.2. APP-USM — виртуальная модель системы освещения в приложении (SQLite). Является кэшем FW-USM для оперативного доступа UI и LLM к данным контроллера.

4.3. USML (Unit System Model Language) — бинарный протокол передачи данных между прошивкой и приложением.

4.4. Телеграмма (телега) — команда в формате USML, содержащая изменения USM.

4.5. Рабочие данные — данные для организации работы освещения (яркость светильников, адреса DALI, действия датчиков и т.п.). Хранятся в прошивке в виде массивов структур C.

4.6. Интерфейсные данные (IDATA) — данные для UI приложения (названия, номера иконок, координаты). В прошивке хранятся единым блоком размером 50000 байт.

4.7. ACTION — действие, состоящее из одного или нескольких поддействий (SUBACTION).

4.8. SUBACTION — элементарное изменение системы освещения (включение сцены у светильника/группы/локации, установка температуры TW, переключение режима АВТО).

5. Базовые принципы

5.1. Режимы работы контроллера

5.1.1. Прошивка в контроллере может работать в двух режимах:

• Автономный режим — контроллер обрабатывает сигналы от настенных кнопок, датчиков присутствия, датчиков освещённости, обеспечивает работу по расписанию.
• Режим с подключением телефонов — дополнительно к автономному режиму осуществляется ПНР, настройка и оперативное управление системой освещения.

5.1.2. К контроллеру одновременно могут быть подключены до 4 телефонов.

5.2. Управление через изменение данных

5.2.1. Все команды на выполнение действий передаются от телефонов контроллеру телегами об изменении данных USM.

5.2.2. Нет команд типа "запустить инициализацию". Вместо этого приложение изменяет поле CONTROLLERS.STATUS = I, что должно запускать соответствующую логику в прошивке.

5.2.3. То, какой код отработает в прошивке, определяется тем, какие данные в FW-USM меняются.

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

5.2.5. Стандартный процесс получения, обработки и ответа прошивки на команду приложения:

• Получение телеги с изменениями USM;
• Дешифровка изменений; понимание, какой код должен отработать;
• Возможные манипуляции линией DALI (могут отсутствовать; например, при переименовании светильника);
• Внесение изменений по результатам в свою FW-USM;
• Отправка телеги приложению с изменениями в FW-USM.

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

5.3. Синхронизация данных

5.3.1. После любого изменения FW-USM прошивка отправляет телегу об этом всем подключённым телефонам (до 4 шт). Тем самым обеспечивается синхронизация FW-USM и APP-USM всех телефонов.

5.3.2. В телеграммах передаются только изменившиеся данные, а не весь FW-USM целиком.

5.3.3. Пример: включение светильника. Приложение отправляет команду на включение светильника 3 с яркостью 55:

1. Телеграмма с изменением LUMINAIRES[3].VAL_BRIGHT = 55 приходит в контроллер.
2. Контроллер видит изменение яркости и отправляет DALI-команду светильнику с адресом LUMINAIRES[3].DALI_ADDR.
3. Контроллер обновляет LUMINAIRES[3].VAL_BRIGHT = 55 в своём FW-USM.
4. Это изменение широковещательно отправляется телеграммой всем подключённым телефонам.

5.4. Блок IDATA

5.4.1. Блок интерфейсных данных IDATA хранится в энергонезависимой памяти контроллера. Он хранит все редко изменяемые ПНР-данные кроме ПНР-данных, требующихся в линии DALI и полей в таблице CONTROLLERS (эти данные входят в состав рабочих).

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

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

5.4.4. Часть телеграмм от приложения содержит и рабочие изменённые данные, и интерфейсные (в IDATA).

5.4.5. При сбросе долгим нажатием кнопки на корпусе контроллера и инициализации линии DALI блок IDATA сбрасывается в 0.

5.5. Действия, поддействия и наборы действий

5.5.1. Поддействие (таблица SUBACTIONS) — элементарное изменение системы освещения:

• Включение сцены у светильника/группы/локации/контроллера;
• Установка температуры белого света (TW);
• Переключение режима АВТО и т.п.

Со стороны пользователя: поддействия создаются внутри действий и при удалении последних вместе с ними же и удаляются.

5.5.2. Действие (таблица ACTIONS) — состоит из одного или нескольких поддействий, выполняемых одним пакетом. Например, действие "Вечерний свет" может включать:

• Включение сцены 2 в гостиной;
• Включение сцены 1 в коридоре;
• Установка температуры 2700K во всех светильниках.

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

5.5.3. Набор действий (отдельной таблицы нет) — группа действий, объединённых для перебора. Используется для привязки к кнопке нескольких действий, которые переключаются последовательно при каждом КОРОТКОМ нажатии на кнопку. Например:

• Действие 1: "Яркий свет" (позиция 1);
• Действие 2: "Средний свет" (позиция 2);
• Действие 3: "Тусклый свет" (позиция 3).

Навешиваются ТОЛЬКО на короткие нажатия кнопок. Специальной таблицы в БД с этими наборами нет. В поле ACTIONS.BUTTON_SHORT_ID нескольких действий записывается ссылка на одну и ту же кнопку. Все действия с одинаковым BUTTON_SHORT_ID образуют набор для этой кнопки. Порядок действий в этом наборе определяется полем ACTIONS.POS.