Русский
Русский
English
Статистика
Реклама

Блог компании гетмобит

Назад к BLE или способ автоматизировать рутинные операции

21.10.2020 18:15:40 | Автор: admin

Кадр из фильма Назад в будущее (1985 год)

Стандарт Bluetooth 5.0 вышел в 2016 году, 2019-м появилась версия 5.2. За последнее время Apple провела две конференции WWDC 2017, WWDC 2019 посвященных CoreBluetooth. Активно развивается технология построения mesh сетей. Все стало еще лучше, быстрее и эффективнее. Интерес к этому направлению только растет. Выстроены целые системы управления на этой технологии.
Мы же задались целью автоматизировать рутинные операции и повысить безопасность доступа пользователей на свое рабочее место. В статье разберем, что было решено предложить пользователям, поговорим немного о технологии BLE (хотя, как тут кратко?) на примере небольшого проекта, который запускается на двух смартфонах и позволяет передавать данные в обе стороны, ну а в конце познакомлю с нашим приложением GM MOBILE ASSISTANT.



Я работаю swift-разработчиком в компании Гетмобит. Мы создаем ИТ-инфраструктуру а-персональных рабочих мест, которая позволит изменить традиционное восприятие рабочей среды, станет более гибкой и независимой от локации, где много внимания уделяется вопросам обеспечения безопасности. Наша экосистема называется GM SMART SYSTEM, ее ключевой элемент устройство GM-Box, сочетающее тонкий клиент и VOIP телефонию. Более подробно, с нашей инфраструктурой, можно ознакомиться в статьях моего коллеги.



Что нам захотелось улучшить?


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

Мы решили избавиться от этих проблем, сделав доступной авторизацию через мобильный телефон. Решение основано на том, что пользователь однажды ввел свои учетные данные в приложении на смартфоне и может забыть про ручной ввод. Мобильный телефон есть у каждого пользователя, приложение доступно в AppStore и Google Play и является частью GM SMART SYSTEM, т.е. работает из коробки, не требует затрат на поддержку. Данные хранятся в защищенной области, доступ к приложению закрыт пин-кодом или биометрией, передаваемые данные шифруются. Мы понимаем, что любую систему можно взломать, но всегда встает вопрос целесообразности.



Работа над решением


Определив смартфон, как средство для авторизации в нашей инфраструктуре, встал вопрос выбора кроссплатформенного решения iOS/Android. Не во всех компаниях разрешено использование WI-FI, USB API не доступно для iOS без дополнительной головной боли, Bluetooth порезан до BLE опять же в iOS. Была даже идея использовать звук но это отдельная история. По итогу, из всего того, что можно, наиболее практичным показался BLE. Пошли изучать матчасть.



Исследования


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

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

На схеме пунктиром выделены несколько Peripheral (GATT server), которые ожидают входящие подключения и что бы заявить о себе в радиоэфире, после инициализации, Peripheral, запускает процесс вещания Advertising пакетов с заданной частотой, чем чаще, тем выше вероятность обнаружения. Central (GATT client) запускает процесс поиска (как правило, запускается на несколько секунд) и пытается найти все устройства в радиусе 10-1500 (Bluetooth 5) метров. Дистанция, конечно, сильно зависит от преград и помех. После обнаружения получаем возможность подключиться, прочитать профиль устройства, подписаться на характеристики (тип NOTIFY), передать данные (WRITE). Любой атрибут имеет уникальный uuid идентификатор.





GATT (Generic Attribute Profile) профиль является общей спецификацией для отправки и получения коротких фрагментов данных, строится на основе протокола атрибутов АТТ. Intro to Bluetooth Generic Attribute Profile.
ATT (Attribute Protocol) протокол атрибутов, оптимизированный для работы на BLE-устройствах. Использует настолько мало байт, насколько это возможно. Каждый атрибут идентифицируется уникальным универсальным идентификатором UUID.
Service совокупность характеристик.
Characteristic по сути, это канал для передачи данных, ограниченного заданной функциональностью:

  • READ после подключения можно прочесть предварительно заданное значение.
  • WRITE клиент использует характеристику такого типа для передачи данных на сервер, однонаправленный канал.
  • NOTIFY используется для асинхронного приема данных от сервера, клиент должен подписаться на получение.
  • INDICATE используется для получения данных, не требует подписки, но необходимо запросить значение.

Descriptor используется для описания характеристики, необязательный атрибут.
UUID стандартизированный 128-битный строковый идентификатор, используемый для однозначной идентификации информации. Может быть задан в сокращенном виде, например 180A информация об устройстве. Обнаружив сервис с таким идентификатором, мы должны предположить, что имеющиеся характеристики будут выдавать нам информацию об этом устройстве. Подробнее в этой статье. Можно воспользоваться генератором uuid.
Adveritising короткие пакеты, необходимы для обнаружения BLE Peripherals. Частота появления в радиоэфире зависит от выставленного значения, минимально от нескольких мс. Дополнения в bluetooth 5.
Перечень зарезервированных профилей. Перечень зарезервированных
16 бит идентификаторов.


Пробуем на практике


Чтобы лучше понять приведенную выше схему, написал небольшое приложение. В проекте используется Core Bluetooth фреймворк. Запускать нужно на 2-х телефонах. На первом выбираем GATT сервер, на втором GATT клиент. После подключения можно пересылать текстовые сообщения. Ниже, разберем по порядку ключевые моменты создания профилей.


Настройка проекта


После создания нового проекта в Xcode добавляем ключ в info.plist

<key>NSBluetoothAlwaysUsageDescription</key><string> Описание для чего будет использоваться bluetooth в приложении</string>


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



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




Создаем профиль GATT сервер


Для управления профилем нам потребуются два класса: CBPeripheralManager, CBPeripheralManagerDelegate. Атрибуты задаются с помощью: CBMutableService, CBMutableCharacteristic, CBMutableDescriptor. Причем созданные атрибуты вкладываются один в другой по цепочке дескриптор, характеристика, сервис.



В начале создадим UUID для каждого атрибута планируемого профиля.



static let primaryServiceUUID =CBUUID(string: "bf52e2d6-ff52-43cb-99a0-872fa3dde94f")static let readCharacteristicUUID =CBUUID(string: "f438775d-e605-42b8-abe7-6e31ed52ea87")static let transferCharacteristicUUID =CBUUID(string: "a82ae020-e171-42f8-a31c-5f612926f041")

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



var readCharacteristic =CBMutableCharacteristic(type: UUIDs.readCharacteristicUUID,properties:[.read],value:"some identificator".data(using: .utf8),permissions:[.readable])

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



var transferCharacteristic =CBMutableCharacteristic(type: UUIDs.transferCharacteristicUUID,properties:[.notify, .writeWithoutResponse],value:nil,permissions:[.readable, .writeable])

Теперь создаем сервис. Ставим primary=true, чтобы он был добавлен в перечень сервисов в advertising пакете.



var primaryService = CBMutableService(type:UUIDs.primaryServiceUUID, primary:true)

Добавляем характеристики.



primaryService.characteristics = [readCharacteristic, transferCharacteristic]

Созданные атрибуты передаем в CBPeripheralManager.



manager = CBPeripheralManager(delegate: self, queue: nil)for service in gattProfile.services {manager.add(service)}

При создании CBPeripheralManager необходимо указать делегат CBPeripheralManagerDelegate. Если после инициализации peripheral manager функция



(void)peripheralManagerDidUpdateState:(CBPeripheralManager *)peripheral

возвращает состояние peripheral.state = .poweredOn, значит manager готов к работе.

GATT профиль заполнен. Осталось собрать Advertising пакет и можно запускать передачу в радиоэфир. Структура пакета это массив [String:Any] значений. Основной параметр, который нам нужно задать идентификатор primary сервиса.



struct Advertisment {var value = [CBAdvertisementDataServiceUUIDsKey:[UUIDs.primaryServiceUUID]]}


Можно было бы еще добавить параметр CBAdvertisementDataLocalNameKey, но в данном случае это не имеет значения. Наши данные для advertising пакета объединяются с advertising данными смартфона. Этот параметр перезаписывается и как правило localName мы видим как iPhone 7.



Для запуска Advertising достаточно выполнить команду.

manager.startAdvertising(Advertisment().value)


Создаем профиль GATT клиент


Для реализации клиентского профиля нам потребуются классы: CBCentralManager, CBCentralManagerDelegate, CBPeripheralDelegate. Последний нужен для работы с найденным GATT сервером, т.к. получаем экземпляр CBPeripheral.
Для того, чтобы найти сервер нам нужно создать экземпляр менеджера CBCentralManager и запустить поиск.



var manager = CBCentralManager(delegate: self, queue: nil)manager.scanForPeripherals(withServices: [UUIDs.primaryServiceUUID],options: managerOptions)

В качестве параметра withServices: передаем массив uuids по этим идентификаторам будет осуществляться автоматическая фильтрация, будут возвращены только те peripherals, идентификаторы которых заданы в массиве. Передавая nil можно обнаружить все активные BLE устройства поблизости. В нашем случае был создан только один сервис, его uuid и передаем в качестве параметра. Параметр options: не обязателен, я передаю туда:



private let managerOptions = [CBCentralManagerScanOptionAllowDuplicatesKey:false,CBCentralManagerOptionShowPowerAlertKey:false]

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



Если устройство с указанным uuid сервисом было обнаружено, то метод didDiscoverPeripheral:



- (void)centralManager:(CBCentralManager *)centraldidDiscoverPeripheral:(CBPeripheral *)peripheraladvertisementData:(NSDictionary<NSString *, id> *)advertisementDataRSSI:(NSNumber *)RSSI;

вернет объект (CBPeripheral *)peripheral. Обязательно нужно сохранить на него ссылку.



var device:CBPeripheral = peripheral 


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



manager.connect(device, options: nil) 

Подключением и отключением управляет CBCentralManager. Отключиться можно командой:


 manager.cancelPeripheralConnection(cancelingDevice) 


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



device?.discoverServices(nil) 

В качестве параметра можем передать массив uuids сервисов, которые хотели бы прочитать. В данном случае стоит nil значит peripheral вернет все имеющиеся.


Чтение характеристик происходит схожим образом, только отправить запрос нужно индивидуального для каждого сервиса. Метод didDiscoverServices возвращает массив найденных сервисов и дальше, выбрав нужный делаем запрос на характеристики. Я не стал запрашивать для всех, т.к. у iPhone параллельно запущено еще несколько служебных, для понимания процесса это только запутает.



guard let services = device?.services else { return }let filterServices = services.filter { (service) -> Bool inservice.uuid == UUIDs.primaryServiceUUID}for service in filterServices {device?.discoverCharacteristics(nil, for: service)}

Найденные характеристики возвращает метод didDiscoverCharacteristicsFor service:, т.е. последовательно для каждого сервиса. Необходимо подписаться на характеристику c идентификатором transferCharacteristicUUID.



if (characteristic.uuid == UUIDs.transferCharacteristicUUID) {device?.setNotifyValue(true, for: characteristic)}

Теперь можно передавать данные между созданными профилями GATT клиент/сервер.



Клиент отправляет данные таким образом:



device?.writeValue(text.data(using: .utf8)!,for: transferCharacteristic,type: .withoutResponse)

Принимает методом делегата CBPeripheralDelegate:



- (void)peripheral:(CBPeripheral *)peripheraldidUpdateValueForCharacteristic:(CBCharacteristic *)characteristicerror:(nullable NSError *)error;

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



MTU. Особенности передачи данных


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

let mtu = device?.maximumWriteValueLength (for: .withoutResponse)

Если общий объем превышает MTU, то нужно разбить данные на соответствующие порции.
Для Peripheral MTU определяется так:

let mtu = connectedCentral?.maximumUpdateValueLength

Ссылку на подключенный Central нужно сохранить предварительно, когда делегат CBPeripheralManagerDelegate обрабатывает запрос подписи на характеристику.

- (void)peripheralManager:(CBPeripheralManager *)peripheralcentral:(CBCentral *)centraldidSubscribeToCharacteristic:(CBCharacteristic *)characteristic;

Передача данных между Central и Peripheral осуществляется без проверок, достаточно прогнать в цикле несколько раз запись в характеристику и все. Когда передаем наоборот от Peripheral к Central, то алгоритм гораздо хитрее. Вначале нужно разделить имеющиеся данные на порции, затем начать отправку. Причем функция updateValue может вернуть false.

func updateValue(_ value: Data,for characteristic: CBMutableCharacteristic,onSubscribedCentrals centrals: [CBCentral]?) -> Bool

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

- (void)peripheralManagerIsReadyToUpdateSubscribers:(CBPeripheralManager *)peripheral;

В приложении есть полный алгоритм передачи данных между Central и Peripheral. По нажатию кнопки Send long text отправляется строка чуть больше 4000 байт.

Что в итоге получилось


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

Теперь предлагаю пройтись по основным возможностям нашего приложения.



Поиск устройств


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

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

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


На практике мы убедились, что вызов метода:

manager.scanForPeripherals(withServices: [UUIDs.primaryServiceUUID],options: managerOptions)

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

Подключение к GM-Box


Если приложение только установлено, то после ввода идентификатора GM-Box, необходимо ввести свои учетные данные. С этого же экрана происходит переподключение, если данные были введены некорректно и проверка прошла с ошибкой.


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

Завершение сессии


В любой момент пользователь может завершить сессию. Стандартный способ вызвать диалог и подтвердить завершение.


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

Защита приложения


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




Послесловие


Подробнее с функционалом приложения можно ознакомиться на AppStore или Google Play.
Дальнейшее развитие приложения будет связано с добавлением новых возможностей. В том числе, планируется ввести автоматический вход в рабочую сессию при поднесении смартфона на достаточно близкое расстояние к GM-Box. Также, по результатам проведенных пилотов, некоторые заказчики хотели бы получить функционал не использующий алгоритм хранения учётных данных на телефоне, несмотря на все предпринятые меры по обеспечению безопасности хранения и передачи данных на смартфонах. Кроме этого, анализ обратной связи от пользователей показал, что была бы удобна функция быстрого блокирования рабочей сессии, если сотруднику
необходимо отойти или переключиться на разговор с коллегой эту опцию мы тоже рассматриваем.



Подробнее..

Гибрид компьютера и IP-телефона. Анатомия аппаратной платформы GM-Box. Часть 3 тестирование и производство

24.11.2020 12:18:29 | Автор: admin

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

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

Качество

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

  • повысить удовлетворенность пользователей и как следствие - иметь новые заказы и позитивную репутацию;

  • в перспективе - снижение издержек на сервисное обслуживание;

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

Фантазия об идеальном рабочем местеФантазия об идеальном рабочем месте

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

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

Цена ошибокЦена ошибок

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

Тестирование

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

  • Подготовка технических требований к изделию. Формализовано в Product Requirement Document (PRD, техническое задание).

  • Сбор требований регуляторов. В нашем случае это EAС (Eurasian Conformity) и CE (Conformit Europenne). Тоже формализовано в PRD.

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

  • EVT (Engineering Validation) - опытные образцы технического проекта для отработки технических решений. Проверяли основной функционал и ОСНОВНЕ технические характеристики на предварительных испытаниях.

  • DVT (DesignValidation) - опытные образцы, собранные по рабочей технической документации (РКД). Проверяли полный функционал и ВСЕ технические характеристики на предварительных испытаниях.

  • PVT (Production Validation) - образцы установочной партии. Повторно проверяли полный функционал и все технические характеристики на приемочных испытаниях. Кроме того, сертифицировали соответствие требованиям регуляторов: CE и EAC.

  • MP (Mass Production) - образцы серийной продукции. Повторная проверка полного функционала и основных технических характеристик в рамках приемо-сдаточных испытаний.

Испытательная лаборатория: ресурсные испытанияИспытательная лаборатория: ресурсные испытанияИспытательная лаборатория: климатические испытанияИспытательная лаборатория: климатические испытанияИспытания на электромагнитную совместимостьИспытания на электромагнитную совместимость

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

Ресурсные испытанияРесурсные испытания

Для тестирования железа использовали комплект софта:

  • BurnInTest. Причем купили комплект донглы + софт. Оказалось очень полезно, т. к. смогли протестировать обмен данными с eMMC SSD, DDR, USB 2.0\3.0 портами на самом низком уровне;

  • CPUZ для стресс теста;

  • HWI для сбора информации о железе;

  • IDPT от Интел для теста платформы, в том числе - стресс теста.

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

Меню программы тестирования GM-BoxМеню программы тестирования GM-Box

Постановка на производство в Азии

Часть работ по разработке GM-Box G1 мы выполняли с Азиатским ODM (Original Design and Manufacturing) производителем. У нас появилась хорошая возможность иметь лояльного партнера в Азии. К тому же он хорошо знает продукт и может помогать нам сопровождать его в серийном производстве. Итого, от ODM партнера у нас были следующие ожидания:

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

  • сборка электронных узлов, например системных плат;

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

  • поставка нашего продукта в другие страны.

Постановка на производство началась с подготовительных работ у ODM партнера. У них этот этап называется PVT (Production Validation) и заключается в организации производственных операций изделия таким образом, чтобы получилось качественно и максимально эффективно. В процессе разработали и изготовили специальную оснастку (стенды) для межоперационного контроля.

Стенд межоперационного тестирования электронных узлов GM-BoxСтенд межоперационного тестирования электронных узлов GM-Box

Сборочные процессы обкатали на боевом конвейере, и технологи подготовили инструкции по сборке SOP (Standard Operating Procedures).

SOP для GM-BoxSOP для GM-Box

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

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

Постановка на производство в России

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

Ключевые требования к площадке:

  • номинальная производительность от 10000 до 20000 единиц изделий;

  • адекватная стоимость аренды помещения без выкупа в частную собственность;

  • удобная логистика больших объемов комплектующих и готовой продукции;

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

Дорожная карта включала вот такие шаги:

  • подготовка требований к производству, в частности по производительности;

  • описание технологического процесса сборки изделия;

  • разработка методики тестирования;

  • подготовка спецификаций рабочих мест;

  • разработка схемы логистики;

  • подготовка предварительного плана производственной площадки;

  • поиск и аренда помещений (у нас оно уже было);

  • адаптация плана производственной площадки под реальное помещение;

  • подготовка технологической документации;

  • закупка оборудования, инструментов, материалов и т.п.;

  • строительно-ремонтные работы на производственной площадке;

  • организация хранения компонентов и готовых изделий;

  • организация входного контроля;

  • сборка рабочих мест, стендового оборудования;

  • организация ремонтного участка;

  • развертывание информационной системы управления производством;

  • подготовка нормативной документации для производственной площадки;

  • сборка установочной партии;

  • сертификация производства продукции по ТР ТС;

Всего-то: начать и закончить!

Сборка GM-Box в РоссииСборка GM-Box в РоссииТехнологическая документацияТехнологическая документацияРемонтный участокРемонтный участок

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

В процессе организации производственного цикла поняли, что нужна хотя бы минимальная автоматизация и маршрутизация производственного процесса, связка с бухгалтерией и системой Service Desk. Бухгалтерия уже работала на 1С и мы решились сделать автоматизацию\маршрутизацию на базе 1С ERP. К счастью, у нас есть крутой архитектор 1С, который это реализовал в жизнь.

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

Заключение

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

Эпилог

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

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

Разговор двух инженеров по мотивам фильма Трудности переводаРазговор двух инженеров по мотивам фильма Трудности перевода

Полезные ссылки

1. Сообщество приборостроителей. Канал в телеграмм: https://t.me/konveerum

2. Конвеерум #28: Внедрение продуктов в производство. Здесь я рассказываю о постановке на производство GM-Box G1 в России. Презентация доклада доступна для скачивания.

Подробнее..

Привет, Habr! Давай знакомиться мы Getmobit и мы здесь новенькие

16.09.2020 08:18:44 | Автор: admin
Get a bit more
Конструкторская мысль не может стоять на месте. Это закон развития общества.
Аркадий и Борис Стругацкие, Понедельник начинается в субботу


TLDR
Getmobit Российский разработчик и производитель ПО и аппаратных решений для реализации концепции Smart Workspace.
/TLDR

Да, никогда такого не было и вот опять, очередной российский производитель, подумают многие. Но шутки в сторону! Давайте действительно познакомимся расскажем, кто мы и что мы делаем. Расскажем, что такое Smart Workspace в нашем понимании и как его сделать. Насколько тернист путь продуктовой компании, которая не переклеивает наклейки, а создаёт что-то новое. Обо этом всём подробнее под катом.

Итак, Getmobit это российская технологическая компания, возникшая как стартап в 2016 году. И, несмотря на то, что нам уже 4 года и команда успела за это время вырасти до 40 человек, обзавестись собственной производственной площадкой в Дубне, дух стартапа (который про создавать новое, полезное и не стоять на месте) нам всё так же близок. Наше решение это платформа для реализации концепции Smart Workspace простого и гибкого способа объединения всех основных информационных сервисов заказчика в понятном и удобном для конечного пользователя устройстве. Решение, не побоюсь этого слова, уникальное и прямых аналогов ему ни мы, ни наши партнёры, ни заказчики пока не нашли. Платформа называется Getmobit Smart System и позволяет обеспечить унифицированный доступ к инфраструктуре VDI, UC, web сервисам всему тому, что сейчас есть во многих крупных компаниях и активно проникает в малый и средний бизнес благодаря развитию направления DaaS.

Компоненты платформы GM Smart System
Компоненты платформы GM Smart System

Платформенный подход был выбран сознательно в конце концов, рынку нужен продукт, решающий задачу в комплексе, а не набор со скотчем (который клейкая лента) и палками внутри. Если вкратце (потому что подробнее тема для отдельной статьи), платформа GM Smart System включает в себя нашу материально ощущаемую красоту и гордость док-станцию GM-Box, систему управления GM Management Suite, мобильное приложение GM Mobile Assistant и сервис удалённой инициализации док-станций Global Discovery Service (GDS). Реализация платформенного подхода позволяет создавать удобные в использовании и администрировании рабочие места, снижая совокупную стоимость владения (в т.ч. по сравнению с решениями на базе классических тонких клиентов) и повышая эффективность работы и использования рабочих мест.
GM-Box на рабочем месте в Москва-Сити
Вот так выглядит GM-Box. Не путайте с телефоном.

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

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

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

PS Если же вам не терпится узнать, как создать а-персональное рабочее место, которое может быть подключено к существующей инфраструктуре предприятия буквально за 15-20 минут из коробки мы с радостью можем провести демо (по зуму или в офисе).

Василий Шубин
Системный архитектор интеграционных проектов Getmobit.
Подробнее..

Гибрид компьютера и IP-телефона. Анатомия аппаратной платформы GM-Box. Часть 1 прототипирование

08.10.2020 18:22:32 | Автор: admin

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

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

Наш продукт это программно-аппаратный комплекс (ПАК), его центральная часть гибридная док-станция GM-Box G1. Это устройство нового поколения все в одном (all-in-one) объединяет в себе: тонкий клиент, IP-телефон, безопасную авторизацию с использованием смартфона, считыватель бесконтактных карт, набор основных модулей беспроводной связи и даже несколько видов зарядки для смартфона.

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

Продукт

Концепция GM-Box претерпела много трансформаций, прежде чем обрести свою физическую аппаратно-программную оболочку. Зачастую обычное офисное рабочее место со стационарным компьютером выглядит громоздко, неудобно и не мобильно: ящик системного блока, периферия, множество кабелей. А еще куча разного софта и лицензий, которые нужно устанавливать, настраивать, и без которых нельзя нормально работать. Вот это все мы собрали в единое устройство все в одном (all-in-one), и получилось не просто устройство, а целая программно-аппаратная платформа, позволяющая перекомпилировать офисное рабочее место в более удобное и отвечающее современным реалиям. Важной частью концепции продукта является смартфон. Его сервисы могут использоваться для совместной работы с Gm-Box. Например, для аутентификации пользователя при подключении к удаленному рабочему столу.

Итого, в серийное производство вышла универсальная док-станция GM-Box G1 - гибрид mini PC и IP телефона в форм-факторе настольного телефона для работы с удаленным рабочим столом (VDI, RDP). А еще устройство нашпиговано интерфейсами, популярными среди пользователей гаджетов и ПК: Wi-Fi, Bluetooth, LTE, Qi, RFID, NFC.

 Живое фото GM-Box G1 (это не рендер) Живое фото GM-Box G1 (это не рендер)Суть GM-Box одной картинкойСуть GM-Box одной картинкой

Методология разработки

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

Этапы создания продуктаЭтапы создания продукта

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

  • создание на каждом этапе разработки продукта задела для следующих шагов;

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

  • много визуализации (скетчи, фото, 3D модели).

Нам это очень помогло, потому что цена изменений\исправлений в железе вот такая, как на схеме (только в жизни еще дороже, потому что расплачиваться приходится еще и временем с нервами):

Цена измененийЦена изменений

Наши ключевые инструменты для управления работой и ее артефактами:

  • Confluence в качестве базы знаний, механизма отчетов и хранилища истории;

  • JIRA трекер задач для Scrum команды;

  • GitLab храним все исходники;

  • MinIO специализированный репозиторий для бинарников (дистрибутивов);

  • И много-много личного и виртуального общения.

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

Проверка гипотезы, разработка прототипов

Путь от идеи к продукту начался с проверки гипотезы, что пользователю действительно необходимо устройство в концепции all-in-one (все в одном), что он готов перейти к работе с виртуальным рабочим столом и может (и хочет) использовать свой смартфон как часть офисного рабочего места. Попутно мы должны были оценить техническую возможность воплотить нашу идею в жизнь. Для этого позарез нужно было что-то для демонстрации продукта и технологий. И это что-то - прототипы. Всего на этапе проверки концепции мы разработали и изготовили 5 версий прототипов, которые мы называли Демонстрационными Образцами (ДО). Вот так выглядел один из скетчей:

Скетч прототипа в черновикеСкетч прототипа в черновике

В процессе подготовки к проверке гипотезы мы определились с обязательными компонентами нашего изделия. Некоторые компоненты отмечены на скетче:

  1. корпус док-станции;

  2. полка парковки с расположением интерфейса взаимодействия\подключения;

  3. зоны расположения клавиатуры;

  4. зоны расположения клавиатуры;

  5. парковка смартфона;

  6. и 6а - телефония;

  7. кабельное подключение смартфона к док-станции;

  8. интерфейсы для подключения периферийных устройств к док-станции.

Остальные компоненты:

  • вычислитель + ПО;

  • подключение к монитору;

  • дополнительные средства телефонии.

Прототип - ДО1

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

Прототип ДО1Прототип ДО13D blow up модель3D blow up модель

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

Raspberry Pi 1 Model ARaspberry Pi 1 Model A

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

  • недостаточная производительность вычислительной системы для работы в web-режиме;

  • неудобный интерфейс установки\подключения смартфона;

  • низкое качество акустики телефонии;

  • работа только в режиме гарнитуры для смартфона;

  • неудобная для сборки конструкция корпуса;

  • низкое качество корпуса и кнопок (3D принтер).

Прототип ДО2\3

Образец ДО2\3Образец ДО2\3

Опыт, полученный при разработке ДО1, мы усвоили и сделали достаточно подробное внутреннее ТЗ, переработали конструкцию и изготовили новые образы по технологии литья в силикон. Конечно, это дороже чем 3D печать, но и внешний вид совсем другой. Уже можно было выносить нас свет божий, чтобы показывать инвесторам и клиентам. После печати пластик покрасили, на прозрачные кнопки нанесли пиктограммы методом УФ-печати, чтобы не истирались. Электронику реализовали на базе одноплатного ПК Odroid-XU4, потому что это был оптимальный выбор из существующих на тот момент на рынке считалок.

Внутреннее устройство ДО2\3Внутреннее устройство ДО2\3

Модификация ДО3 по сравнению с ДО2 устроена была почти так же, за исключением установки некоторых периферий модулей: Qi, NFC, громкая связь. Основные замечания к этой версии:

  • невозможность реализовать в продукте поддержку VDI из-за отсутствия в публичном доступе клиента под ARM CPU;

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

  • нестабильная работа USB Hub на плате расширения;

  • низкое качество акустики, реализованной на плате расширения;

  • низкое качество акустики телефонии;

  • плохая работа клавиатуры.

Прототип ДО4

Образец ДО4Образец ДО4

К этому этапу мы прокачались до разработчиков, что называется, 80-го уровня, и правильные решения нам уже снились. Архитектурно мы сделали резкий поворот в сторону x86 платформы и это было одним из важнейших решений в продукте. О претензиях к ARM я упомянул выше. Немного повторю и добавлю причины перехода на x86:

  • большое разнообразие VDI клиентов под платформу x86;

  • наличие свободных драйверов под GPU;

  • большое разнообразие качественной периферии + бинарные драйвера x86;

  • легкий доступ к телу вендора процессора (Intel);

  • большое разнообразие софта под x86.

Мы применили Wintel-CXW8-Pro на базе Intel Atom x5-Z8300 Cherry Trail, потому что:

  • производительность, как минимум, не хуже, чем у проверенного нами Odroid-XU4;

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

  • наличие на рынке готовых устройств mini PC в качестве доноров системной платы;

  • низкая стоимость.

Системная плата Wintel-CXW8-ProСистемная плата Wintel-CXW8-Pro

Для проверки релевантности такого решения, еще на этапе ДО2\3, мы собрали один опытный образец и протестировали совместно с одним из потенциальных заказчиков.

У нас возникла идея продемонстрировать реальным пользователям нашу технологию в деле. И тут появилась уникальная возможность реализовать пилотный проект на выборах в Ярославле. Счетчик времени запустился. Предстояла проверка нашей гипотезы о замене обычного ПК на GM-BOX в реальной жизни. Сборка 40 устройств представлялась нам непростой задачей, и вот почему:

  • конструкция корпуса требовала доработки;

  • некоторые электронные узлы еще не были разработаны;

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

  • Firmware не разработано;

  • не обкатанный сборочный процесс, отсутствие нормировки времени сборки;

  • дата готовности, которую нельзя сдвинуть;

  • отсутствие собственного, хотя бы, опытного производства;

  • другие, параллельные задачи по разработке серийной версии GM-Box.

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

Power-Hub Board, схема структурнаяPower-Hub Board, схема структурная

Периферию рисовали в САПР AltiumDesigner и развели на 4-х слоях. На проект электроники в САПР ушло 10 дней. Все компоненты платы создавали в 3D, чтобы гарантированно состыковаться с корпусом. Платы сделали на Резоните, остальные компоненты закупили в РФ. Сложную плату Power-Hub Board собрали на срочном контрактном производстве. Ценник получился ~8000 руб. за плату с учетом количества 40 штук, срочности и монтажа на автоматической линии SMT\THT на партию.

Power-Hub Board 3D модель (Altium Designer)Power-Hub Board 3D модель (Altium Designer)Рабочие образцы Power-Hub Board и Button BoardРабочие образцы Power-Hub Board и Button Board

И вот началась сборка. На фронт призвали почти всех сотрудников от офис-менеджера до технического директора.

Полуфабрикаты ДО4Полуфабрикаты ДО4Опытная партия ДО4Опытная партия ДО4

Пилот на выборах в Ярославле прошел на ура. Развернули 30 рабочих мест, и бинго (!) - не было ни единого сбоя.

Рабочее место члена избирательной комиссии, оборудованное GM-BOXРабочее место члена избирательной комиссии, оборудованное GM-BOX

Прототип ДО5 по кличке горбатый

Образец ДО5 по кличке ГорбатыйОбразец ДО5 по кличке Горбатый

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

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

Анатомия ДО5Анатомия ДО5

Заключение

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

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

Полезные ссылки

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

Подробнее..

Bare-Metal Provisioning инфраструктура с нуля

29.10.2020 20:09:21 | Автор: admin
Процесс заливки прошивки

Приветствую, Хабр. Меня зовут Роман, я разработчик встраиваемых систем в Getmobit. Хочу поделиться кейсом по развёртыванию программного обеспечения на большом количестве устройств на производственной линии с нуля. Заставлять людей на производстве бегать вдоль конвейера с флешкой не хотелось, а для автоматизации мне необходимо было четко понимать: на какие шаги можно поделить этот процесс, что на каждом этапе должно происходить, а главное как модифицировать стандартный процесс, чтобы в итоге выполнять специфичные для нашего продукта операции. Основой для решения этой задачи стала технология загрузки устройств по сети (PXE). Об этом и расскажу.

На чем разворачиваем?


Bare Metal частью является устройство GM-Box в том виде, в котором его увидят пользователи.
GM-Box

В зависимости от модификации, в состав устройства могут входить разные подключаемые модули (Wi-Fi, LTE и др).
В процессе производства устройства должны пройти функциональные тесты подключенных блоков: например, Wi-Fi находит точки доступа и обеспечивает номинальную скорость, кнопки на устройстве нажимаются и работают, Bluetooth модуль находит устройство с контрольным MAC-адресом и тому подобное.
На всех экземплярах, прошедших тесты, должно оказаться конечное ПО (прошивка).

Немного теории


Preboot eXecution Environment (PXE)


Технология PXE позволяет загружать операционную систему на устройстве с помощью сетевой карты, а в нашем случае загрузку через сеть будет инициировать UEFI.
При этом можно получить информацию о загрузчике (pxelinux, grub и подобные) с помощью DHCP-опций. Это в свою очередь дает гибкость в управлении конфигурациями операционных систем для целевых устройств.
С точки зрения инфраструктуры типовой процесс загрузки с помощью PXE будет выглядеть, как на схеме:
Диаграмма последовательности загрузки

где Device целевое устройство для развертывания ОС и настройки, Provisioning host инфраструктура или отдельно-стоящая машина.
На схеме, Device после включения питания и первоначальной загрузки UEFI запрашивает по DHCP параметры, в которых будет указано имя файла Zero image и где его найти (адрес TFTP-сервера). И далее передает на исполнение полученный образ (например, pxelinux).

Далее происходит загрузка программы из минимального образа (Zero image). С указанного ранее TFTP-сервера программа читает конфигурацию загрузки и исполняет ее. В нашем случае он автоматически загружает Provision agent для дальнейшей установки и передает ему параметры, полученные на предыдущем этапе. Сам агент представляет из себя ядро Linux и initial RAM disk и выполняет сценарий установки. Состав сценария зависит от задачи. В минимальном виде он выполняет следующие операции:
  • определяет оборудование загруженного устройства
  • производит разметку диска
  • производит настройку операционной системы
  • устанавливает необходимые пакеты

Агентами, например, могут быть preseed, kickstart или самостоятельно собранный дистрибутив со скриптами для развертывания.
После выполнения сценариев развертывания Provision agent автоматически перезагружает устройство.

PXE-less загрузка


Для систем без функции PXE, по классике, можно использовать готовый live-образ на внешнем носителе. Но если вам, например, требуется удаленный мониторинг процесса развертывания или есть зависимость от ресурсов в инфраструктуре, то вместо PXE в схему загрузки может быть добавлен discovery image, который также как live-образ загружается со внешнего носителя, но выполняет лишь функцию доставки provision-агента и далее цепочка загрузки будет идентична схеме.

Подготовка инфраструктуры


Подготовка выглядит достаточно просто для обеспечения каждого этапа необходимыми данными со стороны инфраструктуры потребуются следующие компоненты:
  1. Устройства, поддерживающие PXE
  2. DHCP сервер (например, isc-dhcp-server)
  3. TFTP сервер (например, tftp-hpa)
  4. Хранилище (например, репозиторий Ubuntu или python-пакетов)
  5. Zero image (например, озвученный ранее, pxelinux.0)
  6. Provision agent (ядро Linux и initrd)

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

Примеры конфигурационных файлов
Конфигурация DHCP /etc/dhcp/dhcpd.conf
option domain-name "provisioner";option domain-name-servers 8.8.8.8;default-lease-time 600;max-lease-time 7200;log-facility local7;authoritative;subnet 192.168.30.0 netmask 255.255.255.0 {  range 192.168.30.100 192.168.30.200;  option subnet-mask 255.255.255.0;  option domain-name-servers 192.168.30.1;  option domain-name "prod.provisioner";  option domain-search "prod.provisioner";  option broadcast-address 192.168.30.255;  # Имя файла-загрузчика  filename "pxelinux.0";  # Адрес сервера, откуда будет браться загрузчик  next-server 192.168.30.1;}


Конфигурация TFTP /etc/xinetd.d/tftp
service tftp{   protocol     = udp   port         = 69   socket_type  = dgram   wait         = yes   user         = user   server       = /usr/sbin/in.tftpd   server_args  = /var/lib/tftpboot   disable      = no}


Получить pxelinux для Preseed 5 и 6 можно здесь и далее расположить его в директории доступной по tftp (в нашем случае /var/lib/tftpboot).
Согласно этим конфигурациям, целевое устройство загрузит pxelinux.0 и далее развернет Provision agent для установки.
Пример настройки для pxelinux
DEFAULT linuxLABEL linux    KERNEL boot/vmlinuz    APPEND initrd=boot/initrd.gz ramdisk_size=10800 root=/dev/rd/0 rw auto console-setup/ask_detect=false console-setup/layout=USA console-setup/variant=USA keyboard-configuration/layoutcode=us localechooser/translation/warn-light=true localechooser/translation/warn-severe=true locale=en_US    IPAPPEND 2


Здесь ядру Linux можно передать дополнительные параметры, указав ссылки на локальные ресурсы и конфигурацию для preseed.

Наконец, как мы это применили


Итак, для решения исходной задачи нам потребуется модифицировать provision agent, ведь перед развертыванием ПО должно быть произведено тестирование аппаратных модулей. Тестирование, в свою очередь, не имеет фиксированного сценария и может варьироваться.
В нашем случае provision agent представляет из себя самостоятельно собранный live-образ со специализированным ПО для тестирования и функцией установки GM Soft Kit в память устройства. Сценарий тестирования текущей конфигурации берется со специального http-сервера.
Используя описанную инфраструктуру, мы можем выстроить производственный процесс, как показано на схеме:
Схема процессов производства устройств

В эту схему хорошо встраивается процесс обновление на производственной линии ПО для установки (continuous delivery), но это отдельная тема.

Подводные камни


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

На первой итерации мы пробовали размещать ядро Linux и initrd на простом http-сервере и сохраняли ссылки на них в pxelinux.cfg при такой конфигурации загрузчик периодически не загружал ядро и намертво зависал. Помогло размещении файлов на том же tftp-сервере, где лежит сам pxelinux.

Вывод


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

Дополнительные материалы


  1. Как один из сценариев развития специальное EFI-приложение wiki.archlinux.org/index.php/Systemd-boot#Preparing_a_unified_kernel_image. Оно может выполнять функции zero image и provision agent одновременно.
  2. О том как настроить PXE-инфраструктуру и как подготовить образ описано здесь habr.com/ru/company/X5RetailGroup/blog/493124
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru