Príručka pre integráciu údajov a zabezpečenie bezpečnosti vlastného displeja LED

A vlastná LED displejová doska stáva sa iným druhom displeja, keď sa informácie na obrazovke získavajú z meniaceho sa podnikového systému. Teplota počasia môže stratiť platnosť. Číslo v poradí sa môže presunúť na iný pult. Dopravná služba sa môže oneskoriť. Cena sa môže zmeniť, pričom pozadie zostáva presne rovnaké. V týchto projektoch obrazovka už nie je len prehrávačom médií. Zobrazuje aktuálny stav iného informačného systému.

To mení inžiniersku otázku. Ťažkou časťou zvyčajne nie je kreslenie rámčeka okolo čísla ani jednorazové pripojenie rozhrania API. Namiesto toho sú dôležité rozhodnutia o tom, odkiaľ každá hodnota pochádza, ktorá vrstva rozhoduje o jej dôveryhodnosti, ako si niekoľko živých oblastí delí jednu plátno a čo sa zobrazí, ak zdroj prestane aktualizovať údaje. Tento sprievodca sa zameriava práve na túto hranicu: externé podnikové údaje vstupujúce do pracovného postupu obsahu a logika náhradných riešení, ktorá zabezpečuje, že obrazovka zostáva zrozumiteľná aj v prípade nedostupnosti živých údajov.

Rovnaká LED obrazovka môže zobrazovať tri veľmi odlišné typy obsahu

An Displejová doska s LED môže zobraziť obrázok kampane, nasledovať časovo naplánovaný prehľad scén a zároveň zobrazovať aktuálne číslo v poradí – všetko na rovnakej fyzickej ploche. Vizuálne sa tieto prvky môžu javiť rovnako jednoduché. Na druhej strane však z hľadiska prevádzky fungujú veľmi odlišne.

Pripravený obrázok už existuje ešte pred začiatkom prehrávania. Naplánovaná scéna už vopred vie, kedy sa má objaviť. Živé informácie sú iné, pretože ich hodnota nemusí existovať, kým ju neposkytne iný systém. V dôsledku toho živé údaje vytvárajú závislosť, ktorú statický obsah nemá.

Statický obsah prežíva, pretože prostriedok už existuje

Uložený obrázok alebo video je predovšetkým médiovým problémom. Keď schválený súbor dorazí do miestneho úložiska pre prehrávanie, obrazovka ho môže ďalej zobrazovať, kým ho nahrádza neskorší prostriedok. Prístup k sieti môže stále byť dôležitý pre vzdialené nahrávanie, avšak samotný viditeľný obsah nepotrebuje pri každom zobrazení snímky odpoveď od inej platformy.

Toto rozlíšenie je dôležité pri plánovaní zlyhaní. Ak sa sieťové pripojenie na krátku dobu stratí, uložená scéna kampane môže stále fungovať normálne. Číslo fronty alebo aktuálny stav prepravy nemusia.

Plánovaný obsah závisí od času, nie však vždy od vonkajších údajov

Rozvrh pridáva ďalšiu vrstvu bez nutnosti zaviesť vonkajší kanál. Ranný obsah sa môže podľa hodín prehrávača prepnuť na popoludňajšiu scénu. Rovnako sa naplánované upozornenie na službu môže spustiť a ukončiť v definovaných časoch, pričom všetky médiá zostanú uložené lokálne.

V tomto modeli je kľúčovou otázkou, či je rozvrh a hodiny správne. Živé údaje vyvolávajú náročnejšiu otázku: či zobrazené informácie stále odrážajú aktuálny stav zdroja.

Živá hodnota môže vyzerat zdravo aj veľmi dlho po tom, čo prestala byť aktuálna

Toto je jeden z najjednoduchších rizík, ktoré sa dajú prehliadnuť. Zlyhanie pripojenia sa často javí ako zrejmé, pretože požiadavka vráti chybu. Zastaralé informácie sú nebezpečnejšie, pretože môžu stále vyzerat úplne normálne.

Teplota môže zostať viditeľná aj napriek tomu, že zdroj počasia prestal aktualizovať hodiny predtým. Riadok dopravy môže naďalej zobrazovať starý odhad príchodu. Panel cien môže zachovať predchádzajúcu hodnotu bez akéhokoľvek zrejmého znaku, že záznam z vyššie položeného systému stratil platnosť. Preto návrh živého zobrazenia potrebuje koncept, ktorý statické médiá zvyčajne nepotrebujú: čerstvosť .

Sledujte údaje od ich pôvodného zdroja až po jednu viditeľnú oblasť

Živé informácie často vyzerajú na obrazovke klamlivo malé. Počasie môže obsahovať jednu teplotu a jednu podmienku. Zobrazenie číselného radu môže ukazovať len číslo a počítadlo. Napriek tomu tieto niekoľko viditeľných polí môže prejsť cez niekoľko systémov, kým sa stanú použiteľnými.

Najjednoduchší spôsob, ako pochopiť integráciu, je sledovať jednu hodnotu namiesto toho, aby ste naraz skúmali celý softvérový zásobník. Zvážte číselný rad. Platforma číselného radu vytvára obchodný stav. Rozhranie poskytuje príslušný záznam. Ďalšia vrstva kontroluje a pripravuje hodnotu. Prehrávač umiestni ju do správnej oblasti. Až potom sa finálny vizuálny plátno dostane do LED systému.

Čas je dynamický, ale nemusí potrebovať externý zdroj

Hodiny sa menia každú sekundu, avšak často sa dajú generovať lokálne. V takom prípade sa pozornosť presunie z externého API na synchronizáciu hodín, časové pásmo, formát dátumu, správanie pri reštarte a konzistenciu medzi displejmi.

Toto je užitočné pripomenutie, že „živé“ nepredstavuje automaticky „internetové API“. Správny zdroj závisí od toho, kde už existujú autoritatívne informácie.

Počasie vyžaduje menej polí, ako ich pravdepodobne poskytuje služba počasia

Služba počasia môže poskytnúť veľké množstvo informácií. Displej môže potrebovať iba polohu, aktuálnu teplotu, stav počasia, ikonu a časovú pečiatku zdroja. Načítanie všetkých dostupných polí vytvára viac závislostí bez zlepšenia viditeľného výsledku.

Preto lepšia otázka nie je „Je možné pripojiť API počasia?“, ale „Ktoré polia sú skutočne dostupné a ako staré môžu byť, kým sa stav počasiového regiónu nezmení?“

Údaje frontu predstavujú stav, nie len veľké číslo

Informácie o fronte môžu obsahovať zavolané číslo, čítačku, kategóriu služby, stav a časovú pečiatku. Samotné číslo neposkytuje informáciu o tom, či bolo práve zavolané, či stále prebieha, či už bolo dokončené, alebo či patrí do staršieho záznamu.

Tu je dôležitý význam zdroja. Prázdna hodnota by sa nemala automaticky meniť na nulu. Rovnako chýbajúce pole by nemalo automaticky znamenať „žiadny front“. Tieto stavy môžu predstavovať veľmi odlišné prevádzkové podmienky.

Ceny by mali prísť ako schválené hodnoty, nie ako hodnoty prepočítané priamo na obrazovke

Cenové informácie môžu závisieť od meny, identifikátora produktu, polohy, platného obdobia, stavu akcie, jednotky a iných pravidiel. Tieto obchodné pravidlá patria do zdrojovej platformy, ktorá ich už vlastní.

Pracovný postup zobrazenia sa potom môže sústrediť na prezentáciu. Desatinné miesta, symboly meny, jednotkové označenia, dĺžka textu a stavy nedostupnosti možno štandardizovať bez duplikovania samotnej logiky výpočtu cien.

Dáta o doprave a premávke často vyžadujú preklad skôr, ako sa použijú v grafických prvkoch.

Dopravné platformy môžu poskytovať identifikátory trás, odhadovaný čas príchodu, nástupište, stav oneskorenia, kód služby alebo stav incidentu. Neupravené hodnoty môžu byť navrhnuté pre softvér, nie pre verejnú prezentáciu.

Middleware môže túto zložitosť znížiť tým, že preloží interné kódy do stabilného modelu zobrazenia. Prehrávač môže dostať len cieľové miesto, očakávaný čas a schválený textový stav. Ak sa zdroj neskôr zmení, vrstva prezentácie môže zostať väčšinou nezmenená.

Rozhodnite, ktorá vrstva má rozhodovaciu právomoc pre každé rozhodnutie, ešte pred začiatkom softvérových prác

Integrácia sa stáva ťažkou, keď niekoľko systémov tichým spôsobom zdieľa rovnakú zodpovednosť. Zdrojová aplikácia môže formátovať zobrazovaný text. Prehrávač môže začať interpretovať kódy obchodného stavu. Iný skript môže udržiavať samostatnú vyrovnávaciu pamäť. Výsledok sa stále môže zdáť funkčný počas demonštrácie, avšak odstraňovanie problémov sa výrazne komplikuje, keď sa niečo zmení.

Čistejšia architektúra udržiava hranice pochopiteľné. Zdroj vlastní obchodný fakt. Prostredný softvér rozhoduje, či je fakt vhodný na prezentáciu. Prehrávač vlastní vizuálnu scénu. Cesta riadenia LED svetiel vlastní fyzický výstup.

Toto rozdelenie tiež uľahčuje diskusiu o rozsahu projektu. „Integrácia API“ môže inak opisovať niekoľko úplne odlišných úloh. Môže znamenať načítanie externého kanála, vytvorenie prostredníka, mapovanie dát do šablóny prehrávača alebo koordináciu niekoľkých dynamických oblastí v rámci jedného fyzického displeja.

Keď architektúra informácií ovplyvňuje geometriu displeja, projekt Vlastný LED displej môže tieto dve stránky koordinovať spoločne. Trvalý blok fronty, pruh s počasím, zoznam dopravných prostriedkov alebo viaczónový informačný plátno môžu vyžadovať, aby sa fyzické rozmery a softvérové oblasti uvažovali v rovnakom štádiu.

Fixný formát informačného displeja

Kabinet je fyzickým koncovým bodom. Počet oblastí, hierarchia informácií a prístup k službám stále musia zodpovedať konečnej geometrii displeja.

Zobraziť LED displej 960 × 960

Modulárne informačné plátno

Modulárne hardvérové komponenty môžu vytvárať rôzne celkové veľkosti, pričom oblasti údajov a správanie pri zlyhaní zostávajú definované na úrovni systému obsahu.

Zobraziť LED displej 500 × 500

Definujte význam každého viditeľného poľa pred vytvorením finálneho rozmiestnenia

„Pripojiť API pre počasie“ alebo „zobraziť údaje fronty“ znie počas skorých diskusií jasne. V praxi však obe tvrdenia nechávajú otvorené väčšinu dôležitých rozhodnutí týkajúcich sa integrácie.

Užitočnejším východiskovým bodom je malá zmluva o údajoch. Spája jeden viditeľný prvok s jedným definovaným poľom zdroja a zaznamenáva dostatok kontextu na rozhodnutie, či sa táto hodnota môže bezpečne zobrazovať.

Samotný názov poľa zvyčajne málo vysvetľuje obchodný význam

Vlastnosť s názvom statusby mohla znamenať dostupnosť služby, stav API, platnosť záznamu, stav fronty alebo stav trasy. Vlastnosť s názvom wait_timestále vyžaduje jednotku a definíciu.

Preto by definícia poľa mala zachytiť nielen syntax, ale aj význam. Tento malý krok zabráni tomu, aby technicky správna integrácia zobrazovala nesprávnu interpretáciu.

Hodnoty nula, prázdne pole a nedostupné by mali zostať rôznymi stavmi

Počet položiek v poradí rovný nule môže byť platnou obchodnou hodnotou. Prázdne pole môže znamenať, že neexistuje aktívny záznam. Chýbajúci kľúč môže naznačovať neúplné údaje. Neúspešný požiadavok znamená opäť niečo iné.

Zlučovanie týchto stavov vedie k mylnej vizuálnej reprezentácii. Model zobrazenia by mal rozdiely zachovať, kým schválené pravidlá pre zobrazenie neurčia, ako má každý stav vyzerať.

Dĺžka textu patrí do diskusie o dátach

Dynamické rozloženia často vizuálne zlyhajú skôr, ako technicky. Názov cieľa, ktorý sa vo fáze testovania zmestí, môže byť v bežnom prevádzkovom režime výrazne dlhší. Služobná správa sa môže prekrývať s inou oblasťou. Veľká cena môže vyžadovať viac číslic, než pôvodný návrh umožňoval.

Preto polia obsahujúce veľa textu potrebujú známe vizuálne pravidlo. Projekt môže použiť schválené skratky, zalomenie riadkov, orezanie, iný stav šablóny alebo inú šírku oblasti. Tiché zmenšovanie písma, kým sa stane nečitateľným, je zriedka vhodnou náhradnou možnosťou.

„Reálny čas“ je príliš váhavý pojem, kým nie sú oddelené obnovovací interval a aktuálnosť.

Jednou z najjednoduchších chýb v požiadavkách na ponuku (RFQ) je uviesť len „aktualizáciu v reálnom čase“. Tento výraz znie presne, no môže opisovať úplne odlišné očakávania týkajúce sa prevádzky.

Udalosť v poradí môže musieť byť zobrazená rýchlo, pretože informácia mení okamžitý tok služby. Údaje o počasí môžu nasledovať pomalší cyklus publikovania. Propagačná cena môže zostať nezmenená až do výskytu schváleného komerčného podujatia. Tieto dáta nemusia mať rovnaké správanie pri aktualizácii len preto, lebo sa zobrazujú na jednej obrazovke.

Obnovovací interval sa pýta, ako často systém hľadá niečo nové.

Dotazovanie (polling) môže kontrolovať rozhranie API v definovanom intervale. Webhook môže doručiť zmenu v momente výskytu udalosti. Iný lokálny zdroj môže publikovať súbor alebo správu len vtedy, keď existuje nový záznam.

Mechanizmus aktualizácie by mal nasledovať zdroj, ktorý už existuje. Opakované požadovanie rovnakého počasiového koncového bodu nezabezpečí novšie počasie, ak poskytovateľ ešte nezverejnil nové meranie.

Aktualita sa pýta, ako stará môže byť posledná prijatá hodnota.

Táto otázka je zvyčajne užitočnejšia. Pripojenie môže zostať funkčné, zatiaľ čo zdroj stále vracia starý záznam. Preto potrebuje obrazovka samostatné pravidlo pre vek samotných obchodných informácií.

Ak tento vek prekročí dohodnutú hranicu, systém môže prestať uvádzať hodnotu ako aktuálnu. V tomto bode sa logika vyrovnávania a záložných riešení stáva súčasťou návrhu obsahu, nie len IT-otázkou.

Obsah so záložnou funkciou by mal postupne znížiť kvalitu správy, nie skryť zlyhanie.

Živé informácie potrebujú zmysluplný vizuálny stav aj vtedy, keď zdroj zmizne. Bez neho sa obrazovka môže zaseknúť na starých informáciách, zobrazovať prázdne textové pole, ukazovať chybu aplikácie alebo jednoducho ponechať veľkú prázdnu oblasť.

Najsilnejšia náhradná možnosť zvyčajne nie je jediná núdzová obrazovka. Lepší dizajn umožňuje postupné zhoršovanie kvality informácií. Krátke prerušenia môžu zachovať posledný prijatý záznam. Staršie údaje môžu prejsť do stavu „zastaralých“. Nakoniec môže neutrálna lokálna scéna nahradiť informácie, ktoré už nemali byť predkladané ako aktuálne.

Ukladať do vyrovnávacej pamäte posledný správny záznam, nie len poslednú odpoveď

Nesprávne formulovaná odpoveď by nemala prepísať jediný spoľahlivý lokálny záznam. Namiesto toho môžu nové údaje prejsť overením pred tým, ako nahradia obsah vyrovnávacej pamäte.

Postup je v zásade jednoduchý: prijať nový záznam, skontrolovať ho, normalizovať ho, prijať ho a potom aktualizovať uložený posledný známy správny stav. Ak nová odpoveď neprejde týmito kontrolami, platný obsah vyrovnávacej pamäte zostáva dostupný, kým nevyprší jeho schválená platnosť.

Jedna zlyhajúca informačná zložka nemusí ničiť celú obrazovku

Zmiešaná informačná obrazovka môže obsahovať počasie, čas, údaje o fronte a naplánované médiá. Ak zlyhá informačný kanál pre počasie, platforma pre fronty môže stále fungovať správne a lokálne médiá môžu byť stále dostupné.

Záložné riešenie založené na regiónoch môže zachovať užitočné časti obrazovky. Zóna pre počasie mení svoj stav, zatiaľ čo región pre fronty pokračuje v aktualizácii. Toto vedie k lepšie kontrolovateľnému výsledku ako náhrada celej obrazovky len preto, lebo jedna externá zdrojová informácia nebola dostupná.

Vierohodná náhrada môže byť horšia než správa o nedostupnosti

Predvolené informácie by nemali vymýšľať pravdepodobnú hodnotu. Vymyslená teplota je stále nesprávna. Hodnota nula by nemala nahradiť nedostupný stav fronty, pokiaľ nula skutočne nemá v danom obchodnom kontexte tento význam. Stará cena by nemala zostať na obrazovke donekonečna len preto, lebo sa stále zmestí do rozloženia.

Neutrálne záložné obsahy sú zvyčajne bezpečnejšie. V závislosti od aplikácie môže oblasť zobrazovať všeobecné informácie o službe, statický panel umiestnenia, schválený stav nedostupnosti alebo inú lokálnu scénu, ktorá zostáva platná aj bez vonkajšieho prúdu dát.

Obnovu si zaslúži vlastné pravidlo

Keď sa zdroj vráti, prvá odpoveď by nemala automaticky vymazať záložný stav, kým sa neprevedú bežné kontroly. Nový záznam stále musí spĺňať rovnaké požiadavky na polia a aktuálnosť ako akýkoľvek iný živý aktualizačný záznam.

Toto sa stáva obzvlášť užitočné, keď je nadradená služba nestabilná. Inak sa viditeľná oblasť môže opakovane prepínať medzi záložným a živým obsahom, kým sa pripojenie zo zdroja kolíše.

Lepší RFQ popisuje tok informácií, nie len veľkosť obrazovky

Šírka a výška obrazovky a podmienky inštalácie zostávajú nevyhnutné. Avšak nedokážu vysvetliť, či dokončený plátno obsahuje jeden hodinový displej alebo šesť nezávislých živých prúdov.

Stručný prehľad integrácie sa stane výrazne jasnejším, ak odpovedá na tri praktické otázky: aké informácie vstupujú, ako rýchlo sa môžu meniť a koľko častí obrazovky od nich závisí.

Začnite so zdrojom, nie s názvom softvéru

Každý typ živých informácií by mal mať známy zdroj. Môže ísť o platformu fronty, poskytovateľa počasia, internú databázu cien, službu dopravných informácií, dopravný systém alebo inú schválenú obchodnú aplikáciu.

V skorom stručnom prehľade sa potom dá uviesť, či už existuje dokumentácia rozhrania a či je dostupná metóda REST API, webhook, lokálna služba, prúd správ, štruktúrovaný súbor alebo iná potvrdená metóda. Ak metóda ešte nie je známa, je lepšie ponechať túto položku otvorenú, než hádať.

Malý ukážkový dátový balík môže naraz odpovedať na niekoľko otázok

Sanitizovaný vzorok môže zobrazovať názvy polí, typy údajov, časové pečiatky a štruktúru stavu bez odhaľovania produkčných prihlasovacích údajov alebo dôverovaných záznamov. Často tak poskytuje viac užitočných informácií než dlhý všeobecný popis platformy.

Napríklad obsah fronty, ktorý obsahuje kód služby, číslo fronty, počítadlo, stav a časovú pečiatku aktualizácie, okamžite ukazuje, ktoré polia môžu vyžadovať mapovanie a ktoré hodnoty ovplyvňujú vizuálny stav.

Počet oblastí mení rozsah integrácie

Celoplošná počasie scéna je relatívne jednoduchá, pretože väčšinu meniacich sa obsahov vlastní jeden zdroj. Zmiešaný displej môže byť iný. Čas môže bežať lokálne, počasie môže pochádzať z externého poskytovateľa, informácie o fronte môžu pochádzať z internej platformy a naplánované médiá môžu zaujímať zostávajúce miesto.

Preto počet nezávisle riadených oblastí patrí do RFQ. Každú oblasť potom možno pripojiť k jej vlastnému zdroju, správaniu pri aktualizácii, náhradnému stavu a vizuálnej prioritnej polohe.

Otestujte nepohodlné stavy údajov pred tým, ako sa obrazovka spustí.

Dokonalé vzorové údaje dokazujú, že rozloženie sa dá vykresliť. Nepotvrdzujú však, že informačný systém dokáže bezpečne zlyhať.

Integračné testovanie sa stáva cennejším, keď úmyselne porušuje predpoklady za normálnym scenárom. Požadované pole môže zmiznúť. Hodnota stavu môže nadobudnúť neočakávanú formu. API môže zostať dostupné, pričom sa jeho časová pečiatka prestane meniť. Dátový prúd môže zmiznúť tak dlho, že uložené v cache informácie stratia aktuálnosť.

Dlhý, no platný text tiež patrí do testovania. Cieľové miesto s väčším počtom znakov, vyššou cenou alebo dlhšou správou o stave môže odhaliť vizuálne problémy, ktoré krátke vývojové hodnoty nikdy nezobrazia. Tieto testy sú jednoduché, avšak často predchádzajú viditeľnejším zlyhaniam viac ako ďalšie snímky obvyklých dát.

Často kladené otázky

Najlepší displej živých údajov udržiava obchodnú logiku v hornom toku a prezentáciu jasnou

Platforma fronty by mala naďalej rozhodovať o stave fronty. Platforma cien by mala naďalej vlastniť ceny. Aplikácia pre dopravu by mala naďalej vlastniť dopravné informácie. Zobrazenie sa nestáva spoľahlivejším tým, že sa tieto obchodné pravidlá skopírujú do každého prehrávača.

Namiesto toho integrácia môže extrahovať len informácie potrebné na zobrazenie, rozhodnúť, či je každý záznam stále vhodný na zobrazenie, a odoslať čistý model pre zobrazenie ďalej. Toto oddelenie tiež uľahčuje neskoršie zmeny, pretože rozloženie obrazovky nemusí pochopiť každý detail systému v predchádzajúcej fáze.

Pred poskytnutím ponuky sa musia urobiť tri rozhodnutia, ktoré vytvoria najjasnejší východiskový bod:

• Zmapujte aktívne oblasti. Zaznamenajte, z ktorého zdroja a ktorých polí sa odvádza každá viditeľná oblasť.
• Definujte vek aj rýchlosť aktualizácie. Úspešné pripojenie nepreukazuje, že zobrazené informácie sú stále aktuálne.
• Navrhnite rezervné riešenie ešte pred pripojením živého prúdu. Dĺžka ukladania do vyrovnávacej pamäte, stav zastaralosti, neutrálny obsah a obnova by sa nemali vymyslieť až po nasadení.