Тестування успіху оновлень Over the Air [закрито]

10

Яка найкраща практика для успішного оновлення пристрою IoT?

Що потрібно зробити для тестування оновлень OTA та аутентифікації пристроїв? Зробивши крок далі, як можна відстежувати / керувати версіями програмного забезпечення (оновленнями) парку пристроїв IoT?

testing authentication over-the-air-updates

— Ноам Хакер
джерело

1

Це занадто широко, як і ваше інше питання. І це багато залежатиме від типу пристрою та режиму розгортання.

— Жил "ТАК - перестань бути злим"

1

Коли ви говорите "флот", ви маєте на увазі автопарк? Якщо так, то я вважаю, що зв’язок здійснюється за допомогою (зашифрованого) SMS або HTTPS через GPRS або супутник події, використовуючи щось на зразок модему SkyWave. якщо ви можете відредагувати своє запитання для уточнення, я впевнений, що воно буде відновлено.

— Мауг каже, що повернути Моніку

10

У мене є програмне забезпечення (Windows Server - трохи інше, ніж "речі", але головне - те саме), яке телефонує кожні 24 години - воно надсилає назад різні метадані про себе:

ім'я клієнта (або унікальний ідентифікатор)
версія програмного забезпечення
мітка часу дзвінка / запиту
тип продукту / ід

Веб-сервіс аналізує дані та вставляє (або оновлює, якщо у клієнта наявний рядок) рядок у базі даних.

Таким чином, новий клієнт автоматично додається до БД, існуючі клієнти оновлюють часові позначки "останніх побачень", і ми завжди маємо останню версію програмного забезпечення. Я можу запускати запити БД, які повідомляють мені, які клієнти старіші версії та / або які клієнти не зателефонували протягом певного часу.

Нещодавно ми також впровадили автоматичне оновлення (думаю, оновлення OTA), і тому, що це критичний процес, ми реалізували для цього конкретну телеметрію - що записує:

Поточна версія.
Версія для оновлення.
Хто / коли це санкціонував (якщо вимагається прийняття клієнта).
Часові позначки та коди статусу для кожного з основних кроків.

Це дозволяє нам визначити, чи певні аспекти автоматичного оновлення не вдається, і в багатьох випадках дозволяє нам дзвонити клієнту часто, перш ніж вони навіть помітять, що щось не так.

Велика різниця із "речами" полягає в тому, що ти, як правило, обмежена пам'яттю, тому для оновлення xxx Kbпрошивки потрібна xxx Kb * 2пам'ять OTA (наявна прошивка + достатня пам'ять для зберігання нової мікропрограми перед початком оновлення фактичної прошивки)

— KennetRunner
джерело

1

Дякую, що поділились. Використання пам'яті є важливим моментом. Як ви ставитесь до авторизації та прийняття клієнта, коли це застосовується? Вам потрібен пароль, щоб прийняти оновлення?

— Ноам Хакер

2

Це інший випадок використання (тому що це Windows Server), але у нас є інтерфейс користувача, який спливає попередження, коли завантажується оновлення OTA - попередження запитує клієнта, чи хоче він оновити (і включає посилання для випуску нотаток тощо). Про один thingя б , ймовірно , блимає світлодіод або що - то , щоб попередити користувача (якщо ви хочете, щоб користувач «Дозволити» оновлення) і потім їх «довге натискання» кнопку , щоб запустити його ...

— KennetRunner

5

Наприклад, ви можете робити запит кожні X тижнів / днів / години ... на сервер із поточним номером версії програмного забезпечення. Ви зможете використовувати аналітику, щоб побачити поточний відсоток та кількість оновлених пристроїв.

— WayToDoor
джерело

1

Чи враховується це для пристроїв, які були закладені в цегли або не вдалося завершити оновлення (можливо, застряг у перезавантаженні, завантаженні, циклі аварій?)

— Шон Хуліхане

1

Певним чином, так. Якщо у вас на 1 день є 100 пристроїв, ви 2 дні натискаєте оновлення, а на 3 день ви отримали лише 25 пристроїв для аналітики, це означає, що трапилося щось погане

— WayToDoor

1

це цікаво. чи є спосіб розмежувати типи відмов?

— Noam Hacker

1

розділити оновлення на окремі кроки (наприклад , додати нові значення конфігурації , перезавантаження GPS , набір ідентифікатор пристрою , перезапис прошивки і т.д.) , з кожен з яких має починаючи .. виклику «додому» і завершується зі статусом хх виклику відісланий додому. Таким чином, ви можете сказати (приблизно), де він не вдався, і (сподіваємось), який був код статусу.

— KennetRunner

4

Вся справа в політиці розумної синхронізації

Вам потрібна розумна політика синхронізації, яка працює в тандемі з підходом до оновлення вашого оновлення. Найбільш очевидний момент, коли пристрій IoT повинен синхронізувати свою версію, - це безпосередньо після оновлення . Решта графіка синхронізації сильно залежить від типу пристрою.

Чи завжди він увімкнений та підключений через кабельне з'єднання, коли одна синхронізація не коштує (багато), має сенс синхронізувати досить періодично, щоб зберегти ваші дані про пристрій поточним.

Якщо пристрій десь був, кожен біт коштує дорого, оскільки ви використовуєте дорогі супутникові з'єднання, графік синхронізації повинен враховувати цю обставину.

Перевірка синхронізації

У досить вдосконаленому пристрої (прочитайте ціновий діапазон або область експлуатації, що це виправдовує) кожен пристрій міг бути забезпечений клієнтським сертифікатом, який дозволяє перевірити справжність синхронізації.

У будь-якому разі з пристроями кінцевих клієнтів у вас завжди будуть падати радіолокаційні пристрої через вимкнення акумуляторів, пристрій, який випадає з роботи або просто замовник змінює свій пароль бездротового зв'язку та не повідомляє про пристрій IoT. Їм, можливо, не доведеться нічого робити з вашим оновленням, навіть якщо вони збігаються в часі.

— Гельмар
джерело

Я не думаю, що це дає вирішення питання про ОП.

— WayToDoor

@WayToDoor мій перший абзац радить синхронізувати безпосередньо після оновлення. Це дає інформацію, якщо нова версія була успішно досягнута. Можливі зустрічні заходи, якщо цього не було, занадто широкі (і не вимагаються). Решта моєї відповіді стосується моніторингу версій у цій галузі. Яке питання я пропустив?

— Гельмар