Platformy
- SoC z serii Nordic nRF
- Mikrokontrolery STM32
Jak pracujemy
Podejście inżynierskie
Standardy firmware, przebieg pracy od wymagań do dostarczenia i sposób integracji z Twoim stosem technologicznym.
Wymagania techniczne
Stosujemy spójny standard inżynierski, który zapewnia skalowalność, łatwość utrzymania i bezpieczeństwo na poziomie produkcyjnym.
RTOS i architektura
- Zephyr / FreeRTOS
- Modułowa architektura oparta na RTOS
- Współbieżność i izolacja komponentów bezpieczeństwa
Projekty bare-metal zwykle nie są dobrym wyborem. Rekomendujemy wprowadzenie RTOS, które umożliwia właściwą strukturę systemu i mechanizmy bezpieczeństwa.
Języki
- C++ (główny)
- C (gdy wymagają tego ograniczenia platformy)
Te wymagania pozwalają poprawnie wdrażać, audytować i utrzymywać mechanizmy bezpieczeństwa w systemach produkcyjnych.
Przebieg projektu
Ekspercka inżynieria i integracja bezpieczeństwa
1. Definicja wymagań
Określamy cele i ograniczenia projektu – jasny opis oczekiwanego rezultatu. Na tym etapie wspólnie doprecyzowujemy wymagania i identyfikujemy kluczowe decyzje techniczne.
2. Modelowanie zagrożeń
Analizujemy realne wektory ataku, takie jak wyodrębnienie firmware, klonowanie urządzenia, dostęp przez debug czy podszywanie się pod backend. To wyznacza zakres i priorytety bezpieczeństwa systemu.
3. Definicja architektury bezpieczeństwa
Na podstawie modelu zagrożeń projektujemy architekturę bezpieczeństwa urządzenia – w tym tożsamość, provisioning, uwierzytelnianie, aktualizacje firmware i komunikację.
4. Specyfikacja systemu
Przygotowujemy szczegółową specyfikację opisującą zachowanie systemu, interfejsy, protokoły i mechanizmy bezpieczeństwa. Ten dokument staje się podstawą implementacji.
5. Przegląd specyfikacji
Specyfikację omawiamy z klientem i w razie potrzeby dopracowujemy. Stanowi uzgodnioną podstawę rozwoju.
6. Wycena projektu
Szacujemy harmonogram i budżet na podstawie zatwierdzonej specyfikacji. Rozwój rozpoczyna się po uzgodnieniu.
7. Faza rozwoju
Implementacja przebiega zgodnie ze specyfikacją, z ciągłym testowaniem wewnętrznym. Rezultaty mogą obejmować firmware, narzędzia i usługi wspierające.
8. Testy po stronie klienta
Klient weryfikuje rozwiązanie w rzeczywistym środowisku produktu. Na tym etapie wprowadzamy ostatnie poprawki i poprawki integracyjne.
9. Zakończenie projektu
Po rozwiązaniu wszystkich problemów projekt zostaje sfinalizowany i dostarczony, wraz z zaktualizowaną dokumentacją odzwierciedlającą ostateczną implementację.
Integracja z backendem
Bezpieczny cykl życia urządzenia wymaga systemów backendowych do produkcji, provisioningu, podpisywania firmware i aktualizacji.
Możemy zintegrować nasz firmware i architekturę bezpieczeństwa z Twoim istniejącym backendem, dostosowując protokoły i procesy do Twojej infrastruktury.
Możemy też dostarczyć własną platformę backendową, wraz z kodem źródłowym i dopasowaną do wymagań projektu.
Nasza platforma jest zbudowana w .NET i zaprojektowana do wdrożenia w Microsoft Azure; obsługuje provisioning urządzeń, podpisywanie firmware, zarządzanie tożsamością i operacje w cyklu życia.
Aplikacje towarzyszące i protokoły
Urządzenia sieciowe zwykle wymagają aplikacji towarzyszących do konfiguracji, testowania i codziennej obsługi.
Projektujemy protokoły komunikacji między urządzeniami a aplikacjami (BLE, USB lub własne kanały transmisji) z myślą o bezpieczeństwie i niezawodności.
Możemy też dostarczyć referencyjne aplikacje mobilne lub desktopowe, które implementują te protokoły i pokazują pełną interakcję z urządzeniem.
Dostarczamy również dedykowane narzędzia do debugowania i testowania, które pozwalają inżynierom badać zachowanie urządzenia, weryfikować przepływy komunikacji i rozwiązywać problemy podczas rozwoju i produkcji.
Te aplikacje i narzędzia mogą posłużyć jako podstawa rozwoju Twojego produktu, skracając czas wejścia na rynek i zapewniając poprawną implementację protokołów.
Najczęściej zadawane pytania
Praktyczne pytania o to, jak działa nasz proces inżynierski.
Czy harmonogram i budżet szacujecie przed specyfikacją techniczną, czy po niej?
Po. Wycena następuje, gdy specyfikacja systemu zostanie przejrzana i zatwierdzona – wycena projektu to 6. krok naszego procesu, po definicji wymagań, modelowaniu zagrożeń, architekturze bezpieczeństwa, specyfikacji i przeglądzie specyfikacji. Szacujemy na podstawie uzgodnionej specyfikacji, a nie ogólnego pomysłu.
Czy tylko projektujecie bezpieczeństwo, czy budujecie cały firmware?
To zależy od zakresu, określanego na etapie definicji wymagań. Rezultaty mogą obejmować pełny firmware, wybrane komponenty bezpieczeństwa zintegrowane z Twoim istniejącym kodem albo jedno i drugie, wraz z narzędziami i usługami wspierającymi.
Czy możecie dodać bezpieczeństwo do urządzenia, które już zbudowaliśmy, czy tylko projektujecie je od zera?
Jedno i drugie. Dodanie bezpieczeństwa do istniejącego systemu embedded to jeden z najczęstszych powodów, dla których klienci się do nas zgłaszają – nie tylko nowe projekty.
Jaki jest najczęstszy błąd w istniejących implementacjach bezpieczeństwa embedded?
Prawie zawsze to wczesna decyzja architektoniczna, a nie błąd implementacji: brak silnej tożsamości urządzenia od początku, słaby lub brakujący provisioning podczas produkcji, sekrety przechowywane w firmware lub dostępne przez interfejsy debugowania albo brak mechanizmu bezpiecznych aktualizacji. Poprawne podjęcie tych decyzji na początku jest tanie, a ich naprawa po wdrożeniu floty – kosztowna.
Czy pracujecie w ramach NDA?
Większość naszych projektów realizujemy w ramach NDA. Warunki poufności są częścią ustalania zakresu projektu i zwykle uzgadniamy je przed rozpoczęciem etapu definicji wymagań.
Podsumowanie
Każdy projekt traktujemy jako kompletny ekosystem urządzeń embedded i IoT – łącząc firmware, architekturę bezpieczeństwa, integrację z backendem i aplikacje towarzyszące w spójny system.
Dzięki temu urządzenia są nie tylko funkcjonalne, ale też bezpieczne, weryfikowalne i łatwe w utrzymaniu przez cały cykl życia.
Takie podejście pomaga też dostosować architekturę urządzeń do nowoczesnych oczekiwań regulacyjnych, w tym do ram takich jak akt w sprawie cyberodporności (CRA).
Zobacz, jak to podejście przekłada się na projekt, na stronie Usługi.