15,6-calowy wbudowany wyświetlacz Android do projektów OEM: RK3568, Kiosk i niestandardowy sprzęt

15,6-calowy ekran dotykowy z systemem Android można zbudować jako tablet, wbudowany wyświetlacz z systemem Android lub komputer panelowy z systemem Android. Chociaż te produkty mogą mieć podobne rozmiary ekranów i platformy Android, służą one różnym poziomom integracji produktu. To rozróżnienie staje się ważne, gdy projekt OEM wykracza poza testowanie aplikacji. Urządzenie wymagające ciągłego zasilania, dedykowanego uruchamiania aplikacji, niestandardowego sprzętu, kontrolowanej konfiguracji systemu Android i instalacji wbudowanej nie jest już zwykłym tabletem z innym obudową.

Niedawno oceniliśmy wymaganie OEM od integratora systemów z Norwegii, które ilustruje tę transformację.

Projekt wymagał 15,6-calowego tabletu z systemem Android RK3568 z 4 GB/32 GB, WiFi, trybem kiosku, bez kamery i mikrofonu, czujnikiem światła otoczenia i instalacją wbudowaną. Klient zażądał również konfiguracji bez aplikacji GMS.

Aplikacja była przeznaczona dla tabletu inteligentnego domu, ale wymagania nie były typowe dla tabletu konsumenckiego. Ekran musiał funkcjonować jako dedykowana część gotowego produktu, z określonym zachowaniem oprogramowania, konfiguracją sprzętu specyficzną dla projektu i stałą metodą instalacji.

Prowadzi to do bardziej użytecznego pytania dla nabywców OEM: Kiedy stały ekran dotykowy z systemem Android musi wyjść poza standardowy tablet i czy automatycznie oznacza to użycie komputera panelowego?

Kiedy tablet przestaje być odpowiednim punktem wyjścia

Tablet jest często najefektywniejszym sposobem walidacji aplikacji na Androida. Integruje już wyświetlacz, interfejs dotykowy, procesor, pamięć, pamięć masową, łączność bezprzewodową, obudowę i system operacyjny.

W przypadku wczesnego prototypu może to być zaleta. OEM może testować aplikację bez ponoszenia niepotrzebnych kosztów rozwoju sprzętu.

Sytuacja zmienia się, gdy sam tablet wymaga modyfikacji.

Stały produkt może nie potrzebować baterii. Może wymagać ciągłego zasilania i automatycznego uruchamiania aplikacji po uruchomieniu. Ostateczna lista BOM może nie wymagać kamery ani mikrofonu. Może być konieczne dodanie czujnika specyficznego dla projektu, podczas gdy obudowa może pasować do konkretnej struktury ściany lub panelu. Stałe terminale tego rodzaju już istnieją w naszej ofercie – na przykład 14-calowy tablet restauracyjny POE jest zaprojektowany bez baterii do ciągłej pracy na blacie.

Gdy kilka z tych wymagań pojawia się razem, OEM nie wybiera już po prostu gotowego urządzenia konsumenckiego. Sama platforma sprzętowa staje się częścią projektu produktu.

Nie czyni to tabletu nieodpowiednim do zastosowań stacjonarnych. Tablet można oczywiście zamontować na ścianie i uruchomić aplikację w trybie kiosku; nasz 15,6-calowy tablet z systemem Android montowany na ścianie POE jest jednym z takich urządzeń instalowanych na stałe. Pytanie brzmi, czy OEM może uzyskać dokładną konfigurację sprzętu, zachowanie oprogramowania i integrację mechaniczną wymaganą dla gotowego produktu, nie pracując nad oryginalnym projektem tabletu.

W przypadku projektu norweskiego był to punkt, w którym dyskusja przeszła od znalezienia odpowiedniego tabletu do zdefiniowania dedykowanej konfiguracji terminala z systemem Android.

Co 15,6-calowe wymaganie mówi OEM

Specyfikacja 15,6 cala jest ważna, ale sama w sobie nie określa architektury sprzętowej.

W przypadku stałego terminala interaktywnego, 15,6 cala zapewnia większy obszar interfejsu niż urządzenie przenośne, pozostając jednocześnie praktycznym do integracji ze ścianami, szafkami, blatami i innymi konstrukcjami. Może zatem pasować do zastosowań, w których wyświetlacz pozostaje w jednym miejscu, a użytkownicy wchodzą z nim w interakcję z normalnej odległości w pomieszczeniu lub stojąc.

Ale ten sam 15,6-calowy ekran może pojawić się w bardzo różnych produktach.

15,6-calowy komputer typu tablet z systemem Android może być odpowiedni, gdy OEM chce w dużej mierze kompletnego mobilnego urządzenia komputerowego. 15,6-calowy wbudowany wyświetlacz z systemem Android staje się bardziej istotny, gdy ekran jest integrowany z dedykowanym produktem z niestandardowym sprzętem lub wymaganiami instalacyjnymi. 15,6-calowy komputer panelowy staje się bardziej istotny, gdy terminal musi również komunikować się ze sprzętem przemysłowym lub zapewniać szersze I/O.

Ważne rozróżnienie jest zatem takie: 15,6 cala definiuje interfejs użytkownika; nie definiuje architektury.

W przypadku projektów OEM, otaczające oprogramowanie, sprzęt i wymagania instalacyjne muszą zostać rozważone przed wyborem kategorii produktu.

RK3568, Kiosk i brak GMS to oddzielne decyzje konfiguracyjne

Wymaganie norweskie łączy kilka specyfikacji, które można łatwo potraktować jako jedno ogólne żądanie „dostosowania systemu Android”. Są to faktycznie różne części systemu.

RK3568 definiuje platformę obliczeniową. 4 GB/32 GB definiuje pamięć i pamięć masową. WiFi zapewnia łączność bezprzewodową. Tryb Kiosku definiuje sposób prezentacji i sterowania aplikacją. Kamera, mikrofon i czujnik światła otoczenia należą do konfiguracji sprzętowej. Wymaganie braku GMS należy do konfiguracji oprogramowania i wymaga własnej definicji.

Jedna platforma może obsługiwać bardzo różne konfiguracje: Hopestarmonitor dostarcza również RK3568 w wyświetlaczu montowanym na ścianie i tablecie typu kiosk biurkowy oraz 15,6-calowych ekranach dotykowych.

Ma to znaczenie, ponieważ dostawca może obsługiwać odpowiedni procesor bez konieczności obsługi wymaganego oprogramowania lub listy BOM sprzętu. Podobnie dostawca może zapewnić funkcjonalność Kiosku, oferując niewielką elastyczność w podstawowym sprzęcie.

Dla OEM wymagania muszą być zatem analizowane jako jeden system, a nie jako niezależne specyfikacje produktu.

Poprawne zdefiniowanie „Brak GMS”

„Brak GMS” może brzmieć prosto w zapytaniu ofertowym, ale nie opisuje jednej metody implementacji.

Dla konfiguracji omawianej w tym przypadku, aplikacje GMS można usunąć na poziomie konfiguracji oprogramowania/aplikacji zgodnie z wymaganiami projektu. Nie powinno to być przedstawiane jako czysta kompilacja oprogramowania układowego AOSP ani jako usunięcie każdego komponentu Google na poziomie oprogramowania układowego.

To rozróżnienie jest ważne przy porównywaniu dostawców.

Jeśli OEM wymaga jedynie środowiska Android bez standardowych aplikacji GMS, konfiguracja na poziomie oprogramowania może być wystarczająca. Jeśli projekt wymaga fundamentalnie innej architektury oprogramowania układowego opartej na czystej kompilacji AOSP, powinno to zostać określone jako oddzielne wymaganie.

Praktyczna lekcja polega na tym, aby zapytać dostawcę, co „Brak GMS” faktycznie oznacza w dostarczonym obrazie oprogramowania, zamiast traktować samo wyrażenie jako kompletną specyfikację techniczną.

Tryb Kiosku staje się ważny, gdy urządzenie ma jedno zadanie

Tryb Kiosku to kolejne wymaganie, które zmienia sposób oceny urządzenia z systemem Android.

Ogólny tablet jest zaprojektowany do zapewnienia dostępu do aplikacji i funkcji systemowych Android. Dedykowany terminal zazwyczaj ma znacznie węższy model działania:

Włącz zasilanie → uruchomienie systemu Android → uruchomienie wyznaczonego APK → użytkownik pozostaje w zamierzonej aplikacji — model działania, który projektujemy w terminalach jednofunkcyjnych, takich jak nasza seria tabletów do rezerwacji sal konferencyjnych.

Pytanie o zamówienie nie dotyczy zatem jedynie dostępności trybu Kiosku.

OEM musi zrozumieć pełne zachowanie. Co się dzieje po przerwaniu zasilania? Czy wyznaczona aplikacja uruchamia się ponownie automatycznie? Czy użytkownicy mogą wyjść z aplikacji? Czy mogą pojawić się niepotrzebne interfejsy systemowe? Jak wdrażany i aktualizowany jest APK klienta?

Te szczegóły mają znaczenie, ponieważ urządzenie z systemem Android nie jest już używane jako komputer ogólnego przeznaczenia. Jego zachowanie podczas uruchamiania i działanie aplikacji staje się częścią gotowego produktu.

W przypadku omawianego projektu tryb Kiosku był zatem traktowany jako część zachowania operacyjnego urządzenia, a nie jako odizolowana funkcja oprogramowania.

Dostosowanie sprzętu zmienia definicję produktu

Żądanie braku kamery, mikrofonu i czujnika światła otoczenia również zmienia sposób specyfikacji projektu.

Tablet konsumencki zazwyczaj ma predefiniowaną listę BOM. Jeśli aplikacja nie korzysta z kamery ani mikrofonu, te komponenty mogą być nadal fizycznie obecne, ponieważ są częścią standardowego produktu.

Platforma OEM może zamiast tego być skonfigurowana wokół rzeczywistej aplikacji.

Usunięcie nieużywanych komponentów może pomóc dopasować sprzęt do zamierzonych wymagań produktu. W aplikacji wrażliwej na prywatność wykluczenie niepotrzebnego sprzętu do przechwytywania może być również częścią projektu produktu.

Czujnik światła otoczenia służy innemu celowi. W wyświetlaczu instalowanym na stałe oświetlenie otoczenia może się znacznie różnić. Czujnik światła może dostarczać dane środowiskowe do automatycznego zachowania jasności.

W przypadku projektów OEM wymagania te nie są zatem jedynie opcjonalnymi funkcjami. Są one częścią konfiguracji sprzętowej, która musi zostać uzgodniona przed produkcją.

Dlatego też dostosowanie listy BOM należy oceniać razem z platformą Android, a nie po wybraniu standardowego tabletu.

Wbudowany wyświetlacz z systemem Android vs. komputer panelowy: Spójrz na I/O przed etykietą

Rozróżnienie między Bezpośrednia komunikacja ze sprzętem zewnętrznym a komputerem panelowym z systemem Android jest często opisywane zbyt szeroko jako „konsumencki kontra przemysłowy”. Bardziej użytecznym punktem wyjścia jest rola, jaką urządzenie z systemem Android musi odgrywać w systemie.

Jeśli ekran dotykowy głównie uruchamia aplikację, akceptuje dane wejściowe dotykowe, łączy się z siecią i działa jako dedykowany terminal, wbudowany wyświetlacz z systemem Android może być wystarczający.

Architektura staje się bardziej zorientowana na komputer panelowy, gdy terminal z systemem Android musi również komunikować się bezpośrednio z zewnętrznym sprzętem. Może to obejmować wymagania, takie jak komunikacja RS232 lub RS485, połączenia Ethernet do integracji sprzętu, sygnały GPIO, komunikacja PLC lub szersze dostosowanie I/O.

W tym momencie urządzenie nie działa już tylko jako ekran interaktywny. Staje się częścią architektury obliczeniowej i komunikacyjnej sprzętu.

monitorów z ekranem dotykowym LCD, na przykład, zawiera modele RS232, które nadal są monitorami, a nie komputerami panelowymi. Chodzi o to, że integracja sprzętu i wymagania I/O są silniejszymi sygnałami architektonicznymi niż sam rozmiar ekranu lub metoda instalacji.To rozróżnienie było istotne w przypadku projektu norweskiego. Wymaganie dotyczyło instalacji wbudowanej i dostosowania sprzętu, ale opisana aplikacja nie wymagała z natury komunikacji PLC, RS232/RS485 ani szerszego przemysłowego I/O.

Bardziej odpowiednią architekturą był zatem wbudowany wyświetlacz z systemem Android lub dedykowany terminal z systemem Android, zamiast automatycznego przejścia do komputera panelowego tylko dlatego, że urządzenie było instalowane na stałe.

Decyzja o 15,6 calach zaczyna się od gotowego produktu

Wymaganie norweskie stanowi użyteczny sposób podejścia do architektury od gotowego produktu wstecz.

Wymaganie dotyczące wyświetlacza wynosiło 15,6 cala. Platforma obliczeniowa to RK3568 z 4 GB/32 GB i WiFi. Oprogramowanie wymagało zachowania w trybie Kiosku i konfiguracji bez aplikacji GMS. Konfiguracja sprzętowa była również specyficzna: brak kamery, brak mikrofonu i czujnik światła otoczenia. Wymaganie mechaniczne dotyczyło instalacji wbudowanej.

Łącznie te wymagania opisują coś innego niż konwencjonalny zakup tabletu. Jednocześnie nie uzasadniają automatycznie komputera panelowego.

Jest to ważne rozróżnienie dla zamówień OEM: stała instalacja i dostosowanie sprzętu same w sobie nie czynią projektu przemysłowym.

Jeśli projekt później doda komunikację PLC, przemysłowe I/O lub bezpośrednią integrację sprzętu, architektura może zostać ponownie oceniona w kierunku

komputera panelowego z systemem Android.Takie podejście oparte najpierw na wymaganiach daje OEM większą elastyczność we współpracy z dostawcą. Zamiast zaczynać od kategorii katalogowej i próbować dopasować do niej projekt, kupujący może zacząć od gotowego produktu i zidentyfikować platformę Android, która najlepiej go obsługuje.

Co zweryfikować przed zatwierdzeniem platformy OEM

Po zidentyfikowaniu architektury ocena dostawcy staje się znacznie bardziej konkretna.

Platforma Android powinna zostać zweryfikowana pod kątem wymaganego procesora, wersji Androida, pamięci, pamięci masowej i konfiguracji bezprzewodowej. Wymagania dotyczące oprogramowania powinny określać rzeczywistą metodę usuwania GMS, proces wdrażania APK, zachowanie w trybie Kiosku, automatyczne uruchamianie i zachowanie ponownego uruchomienia.

Lista BOM sprzętu powinna potwierdzić, czy kamera i mikrofon mogą zostać wykluczone i czy czujnik światła otoczenia może zostać uwzględniony w uzgodnionej konfiguracji produkcyjnej.

Integracja mechaniczna powinna obejmować wymiary, strukturę montażową, lokalizację złączy, wejście zasilania i interfejs obudowy. Jeśli terminal łączy się z zewnętrznym sprzętem, wymagane interfejsy RS232, RS485, Ethernet, GPIO lub inne powinny zostać zdefiniowane przed finalizacją architektury.

Te szczegóły są również miejscem, w którym projekt OEM może przejść od standardowej konfiguracji produktu do niestandardowej platformy. Im więcej wymagań przekracza granice oprogramowania, sprzętu i mechaniki, tym ważniejsze staje się, aby dostawca mógł koordynować te elementy jako jedną konfigurację produkcyjną.

Ostateczne pytanie dotyczy spójności produkcji. Dostawca, który może modyfikować prototyp, niekoniecznie jest w stanie utrzymać ten sam obraz oprogramowania, listę BOM sprzętu i konfigurację mechaniczną przez cały okres produkcji masowej. OEM powinien zatem potwierdzić, w jaki sposób zweryfikowana konfiguracja będzie kontrolowana, gdy projekt przejdzie od walidacji prototypu do skalowania produkcji.

Lepsze zapytanie ofertowe zaczyna się od gotowego produktu

Najskuteczniejsze zapytanie ofertowe dla tego typu projektu opisuje zamierzone urządzenie, a nie tylko prosi o model produktu.

Zamiast prosić o

15,6-calowy tablet z systemem Android i RK3568, OEM może zdefiniować wymagania w sposób umożliwiający dostawcy ocenę kompletnej konfiguracji.Obszar zapytania ofertowego

Daje również dostawcy wystarczające informacje do określenia, czy projekt można zrealizować za pomocą istniejącej konfiguracji platformy, czy też wymaga dalszego dostosowania sprzętu i oprogramowania.

W przypadku projektu OEM podobnego do tego przypadku, ta sama specyfikacja może służyć jako punkt wyjścia do dyskusji technicznej z naszym zespołem. Początkowe zapytanie ofertowe nie musi zawierać wszystkich szczegółów technicznych; zestaw wymagań może być najpierw użyty do określenia odpowiedniej architektury Android i zidentyfikowania obszarów wymagających dalszego potwierdzenia.

Masz projekt OEM z 15,6-calowym systemem Android?

Stały ekran dotykowy z systemem Android nie musi automatycznie stawać się komputerem panelowym, tak jak aplikacja montowana na ścianie nie wymaga automatycznie tabletu.

Lepszym punktem wyjścia jest gotowy produkt: zdefiniuj rozmiar ekranu, procesor, pamięć, konfigurację Android, zachowanie aplikacji, listę BOM sprzętu i metodę instalacji, a następnie określ, która architektura pasuje do tych wymagań. Produkty takie jak nasz

15,6-calowy tablet z systemem Android do inteligentnego domu pokazują, jak daleko można skonfigurować stały ekran dotykowy z systemem Android przed produkcją.Jeśli wymagana jest również komunikacja ze sprzętem przemysłowym, od początku należy uwzględnić interfejsy takie jak RS232, RS485, Ethernet lub GPIO.

Jeśli Twój projekt ma wymagania podobne do tego przypadku, możesz

wysłać nam podstawowe informacje i pozwolić ocenić architekturę od wymagań na zewnątrz. Nasz zespół może ocenić, czy bardziej odpowiedni jest wbudowany wyświetlacz z systemem Android, czy komputer panelowy z systemem Android, i zidentyfikować, które elementy oprogramowania, sprzętu lub instalacji wymagają dostosowania przed produkcją.Celem nie jest zmuszenie projektu OEM do jednej kategorii produktu, ale dopasowanie architektury sprzętowej Android do sposobu, w jaki gotowy produkt faktycznie musi działać.