Notatka
Dostęp do tej strony wymaga autoryzacji. Może spróbować zalogować się lub zmienić katalogi.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Azure Sphere urządzenia mogą uruchamiać dwa typy aplikacji:
- Aplikacje wysokiego poziomu są uruchamiane w kontenerach w systemie operacyjnym Azure Sphere
- Aplikacje przystosowane do pracy w czasie rzeczywistym (RTApps) działają bezpośrednio na sprzęcie lub pod kontrolą systemu operacyjnego czasu rzeczywistego (RTOS) na rdzeniach czasu rzeczywistego
Aplikacja wysokiego poziomu jest wymagana dla każdego urządzenia Azure Sphere; Aplikacje RTApps są opcjonalne.
Aplikacje wysokiego poziomu
Każde urządzenie Azure Sphere ma aplikację wysokiego poziomu, która działa w systemie operacyjnym Azure Sphere i może korzystać z bibliotek aplikacji. Aplikacja wysokiego poziomu może:
Konfigurowanie i interakcja z urządzeniami peryferyjnymi Azure Sphere, takimi jak wyprowadzenia wejściowe/wyjściowe ogólnego przeznaczenia (GPIO), uniwersalne asynchroniczne odbiorniki/nadajniki (UART) i inne interfejsy
Komunikacja z aplikacjami RTApps
Komunikacja z internetem i usługami opartymi na chmurze
Relacje zaufania brokera z innymi urządzeniami i usługami za pośrednictwem uwierzytelniania opartego na certyfikatach
Aplikacja wysokiego poziomu działa w kontenerze w trybie użytkownika Normal World, jak opisano w Czym jest Azure Sphere?. Kontener aplikacji obsługuje podzestaw środowiska POSIX i zestaw bibliotek aplikacji (Applibs), które są specyficzne dla systemu operacyjnego Azure Sphere. Biblioteki i funkcje dostępne dla aplikacji wysokiego poziomu są ograniczone, aby zapewnić bezpieczeństwo platformy i można ją łatwo zaktualizować. Aplikacje mogą uzyskiwać dostęp wyłącznie do bibliotek i usług środowiska uruchomieniowego udostępnianych przez firmę Microsoft; wśród innych ograniczeń nie są dostępne ani bezpośrednie operacje wejścia/wyjścia na plikach, ani dostęp do powłoki. Development environment opisuje podstawowy zestaw interfejsów API i wprowadza biblioteki aplikacji Azure Sphere, które obsługują funkcje specyficzne dla urządzenia.
Aplikacje wysokiego poziomu powinny działać w sposób ciągły i są automatycznie uruchamiane ponownie, jeśli zostaną zatrzymane lub zakończą się niepowodzeniem.
Tworzenie aplikacji wysokiego poziomu zawiera więcej informacji o funkcjach.
Aplikacje działające w czasie rzeczywistym
Urządzenie Azure Sphere może również mieć co najmniej jedną aplikację obsługną w czasie rzeczywistym oprócz aplikacji wysokiego poziomu. Aplikacja RTApp może wykonywać następujące czynności:
- Konfigurowanie i interakcja z urządzeniami peryferyjnymi zintegrowanymi z Azure Sphere MCU, takimi jak wyprowadzenia GPIO i UARTs
- Komunikacja z aplikacjami wysokiego poziomu
Usługa RTApps może działać na komputerze bez systemu operacyjnego lub w systemie operacyjnym czasu rzeczywistego (RTOS). Repozytorium przykładów Azure Sphere w serwisie GitHub zawiera zarówno przykład typu bare-metal HelloWorld, jak i przykład demonstrujący komunikację między rdzeniami między aplikacjami wysokiego poziomu a aplikacjami RT. Repozytorium przykładów Azure w GitHub zawiera przykład pokazujący jak używać Azure Sphere z Azure RTOS.
Dodatkowe sterowniki i przykłady dla aplikacji RTApps, przeznaczonych dla rdzeni czasu rzeczywistego M4 w układzie MT3620, są dostępne w serwisie GitHub u partnerów Azure Sphere: MediaTek i Codethink.
Każda aplikacja RTApp działa w izolacji na określonym rdzeniu wejścia/wyjścia (I/O) i może komunikować się wyłącznie z aplikacją wysokopoziomową; nie może korzystać z internetu, bibliotek applibs platformy Azure Sphere ani z innych funkcji systemu operacyjnego Azure Sphere.
Tworzenie aplikacji obsługującej czas rzeczywistym zawiera więcej informacji na temat funkcji i procesu programowania dla aplikacji RTApps.
Funkcje wspólne dla wszystkich aplikacji
Pomimo znaczących różnic między aplikacjami wysokiego poziomu i aplikacjami RTApps wszystkie aplikacje Azure Sphere mają pewne typowe elementy. Za pomocą interfejsu wiersza polecenia można tworzyć, kompilować i debugować oba typy aplikacji przy użyciu Visual Studio lub Visual Studio Code albo wywołać narzędzia CMake i Ninja.
Ponadto następujące funkcje zabezpieczeń mają zastosowanie zarówno do aplikacji wysokiego poziomu, jak i RTApps:
Możliwości aplikacji
Niezależnie od tego, gdzie działa, każda aplikacja Azure Sphere musi określić usługi zewnętrzne i interfejsy, których wymaga — na przykład wymagania dotyczące operacji we/wy i sieci — aby zapobiec nieautoryzowanemu lub nieoczekiwanemu użyciu.
Możliwości aplikacji to zasoby wymagane przez aplikację. Możliwości aplikacji obejmują urządzenia peryferyjne używane przez aplikację, hosty internetowe, z którymi łączy się aplikacja wysokiego poziomu, oraz uprawnienia do zmiany konfiguracji sieci, między innymi. Każda aplikacja musi mieć manifest aplikacji , który identyfikuje te zasoby.
Możliwości urządzenia
Funkcja urządzenia umożliwia działanie specyficzne dla urządzenia. Możliwości urządzeń są przyznawane przez usługę zabezpieczeń Azure Sphere. Domyślnie mikroukłady Azure Sphere nie mają możliwości urządzenia. Istnieją dwa główne typy funkcji urządzenia: funkcja urządzenia appDevelopment i funkcja urządzenia fieldServicing.
Możliwość urządzenia appDevelopment zmienia typ podpisywania, któremu ufa urządzenie. Domyślnie urządzenia Azure Sphere ufają pakietom obrazów podpisanych w środowisku produkcyjnym, ale nie ufają pakietom obrazów podpisanych za pomocą zestawu SDK. W związku z tym nie można załadować bezpośrednio pakietu obrazu podpisanego przez zestaw SDK do urządzenia Azure Sphere, które nie ma tej możliwości. Gdy jednak funkcja appDevelopment jest obecna, urządzenie ufa pakietom obrazów podpisanych za pomocą zestawu SDK. Ponadto umożliwia uruchamianie, zatrzymywanie, debugowanie lub usuwanie aplikacji z urządzenia. Podsumowując, możliwości tworzenia aplikacji muszą być obecne na urządzeniu, zanim będzie można:
- Załaduj lokalnie pakiet obrazu utworzony za pomocą programu Visual Studio lub polecenia azsphere image-package.
- Uruchamianie, zatrzymywanie, debugowanie lub usuwanie pakietu obrazów z urządzenia Azure Sphere bez względu na sposób podpisania pakietu obrazów.
Polecenie az sphere device enable-development tworzy i stosuje funkcję appDevelopment i uniemożliwia urządzeniu otrzymywanie aktualizacji aplikacji w chmurze.
Funkcja fieldServicing umożliwia komunikację urządzenia-komputer na urządzeniach, które znajdują się w stanie produkcji DeviceComplete. Dzięki tej funkcji można wgrywać obrazy podpisane kluczem produkcyjnym, ale nie można ich usuwać. Możesz uruchamiać i zatrzymywać aplikacje, ale nie debugować ich. Można również wykonywać rutynowe zadania konserwacji, takie jak konfigurowanie sieci Wi-Fi. Jest przeznaczone do krótkotrwałego użycia podczas sesji serwisowej, czyli w ograniczonym czasie, w którym dostęp do urządzenia jest przyznawany oddzielnie dla każdej operacji.
Wymagania dotyczące podpisywania i wdrażania
Wszystkie pakiety obrazów wdrożone na urządzeniu Azure Sphere muszą być podpisane. Zestaw SDK Azure Sphere oraz polecenie az sphere image-package podpisują pakiety obrazów na potrzeby testów przy użyciu klucza podpisywania zestawu SDK. Urządzenia Azure Sphere ufają temu kluczowi tylko wtedy, gdy dostępna jest również możliwość urządzenia appDevelopment.
Usługa Azure Sphere Security Service podpisuje produkcyjnie pakiety obrazów podczas ich przekazywania do chmury. Pakiety obrazów z podpisem produkcyjnym mogą być ładowane bezpośrednio lub ładowane z chmury.
Aby zapobiec instalacji nieautoryzowanych oprogramowania, aplikacje można załadować na urządzenie Azure Sphere tylko na dwa sposoby:
Ładowanie bezpośrednie, które może służyć zarówno do tworzenia oprogramowania, jak i testowania oraz do obsługi urządzeń w terenie. Ładowanie bezpośrednie na potrzeby tworzenia i testowania oprogramowania wymaga możliwości urządzenia appDevelopment. Ładowanie boczne na potrzeby serwisowania w terenie wymaga funkcji urządzenia fieldServicing oraz pakietów obrazów systemu podpisanych podpisem produkcyjnym. Zarówno program Visual Studio, jak i Visual Studio Code umożliwiają instalowanie aplikacji metodą sideload podczas programowania i debugowania; aplikacje można też instalować ręcznie przy użyciu narzędzia Azure CLI.
Aktualizacja w chmurze, którą może przeprowadzić wyłącznie usługa zabezpieczeń Azure Sphere. Użyj Azure CLI do tworzenia wdrożeń w chmurze i zarządzania nimi.
Aplikacje partnerskie
Aplikacje, które współpracują ze sobą, można traktować jako aplikacje partnerskie , a następnie ładować je oddzielnie. Jeśli zainstalujesz aplikację metodą sideloading, a ma ona aplikację partnerską, ta aplikacja partnerska pozostanie na urządzeniu Azure Sphere, jeśli została już wcześniej wdrożona. Każda aplikacja deklaruje listę swoich partnerów w konfiguracji projektu.
Aby dodać partnerów do konfiguracji projektu CMake, określ identyfikator składnika aplikacji partnera w polu partnerComponents sekcji konfiguracji launch.vs.json lub pliku .vscode/launch.json:
"partnerComponents": [ "25025d2c-66da-4448-bae1-ac26fcdd3627" ]
Aplikacje wysokiego poziomu i aplikacje RTApps komunikujące się ze sobą muszą być identyfikowane jako partnerzy. Azure Sphere nie obsługuje komunikacji między parami aplikacji wysokiego poziomu ani parami aplikacji RTApps.