Платформа

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

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

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

Проектирование начинается с понимания задачи.

Кто пользуется устройством? Какое оборудование к нему подключено? Какие функции должны оставаться доступными постоянно? Сколько ресурсов можно использовать и что произойдёт при отказе?

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

Эти требования определяют устройство системы и критерии её проверки.

Каждый компонент требует ресурсов, настройки, обновлений и сопровождения.

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

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

Состав системы должен быть известен, зафиксирован и воспроизводим.

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

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

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

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

Производительность важна в конкретном сценарии.

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

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

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

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

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

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

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

Потеря питания, заполнение накопителя, недоступность датчика и разрыв связи должны учитываться при проектировании.

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

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

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

У работающей системы есть конкретная версия и известный состав.

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

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

Обновление должно проходить установленный путь от разработки до целевого устройства.

Платформе нужны инструменты, с которыми инженер может собрать образ, подключить оборудование и проверить результат.

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

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

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

Готовность определяется результатами испытаний.

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

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

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

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

Мы строим подход к RUS OS вокруг этой ответственности: понимать состав системы, проверять её поведение и сохранять возможность управлять ею на протяжении всего срока службы.

Чтобы инженер мог обосновать решение, специалист мог его обслужить, а оператор мог выполнять свою работу.