För att ett LED -visningsprojekt lyckas genomföra och uppnå sina avsedda mål är en omfattande projektplan nödvändig. Vilka steg är involverade i att utforma ett LED -visningskontrollsystem? Vilka indikatorer och parametrar bör beaktas under designprocessen?
LED Display Control System Design -processen inkluderar främst fem faser: kravinsamling och bekräftelse, lösningsdesign, lösningsgranskning, implementering av lösningar och lösningsleverans. Flödesschemat visas nedan.
Kravinsamling och verifiering
Kravens samling
Kravsamling innebär att man genomför djup och detaljerad forskning och analys av "kraven" eller "behov" uttryckt av projektintressenter. Denna process syftar till att exakt förstå de specifika funktionella, prestanda och tillförlitlighetskrav för både användare och projektet. Denna process översätter informella användarkrav till en fullständig kravdefinition och därigenom klargör vad systemet måste göra och ge en grund för systemdesign, förbättring och underhåll.
Kravinsamling är ett avgörande steg i projektplaneringsfasen, eftersom den bestämmer vilken systemfunktionalitet som måste uppnås och ger tydlig riktning för hur man kan uppnå det.
Generellt kategoriseras kraven i affärskrav, användarkrav och funktionella krav, beroende på målet
Vissa behov är pseudo-behov och saknar praktiskt värde. Användarens behov bör screenas baserat på de tre dimensionerna av äkthet, värde och genomförbarhet. Detta kommer att filtrera bort de som är falska, omöjliga eller värdelösa och därmed destillera användarens väsentliga behov. Att förstå "varför" är viktigare än "vad" är avgörande.
Behov kan också kategoriseras som uttryckliga och implicita. Ett uttryckligt behov är ett specifikt uttalande från projektledaren om utmaningar, viktiga punkter och svårigheter; Ett implicit behov är ett vagt uttalande från projektledaren om utmaningar, viktiga punkter och svårigheter. Om en användare till exempel säger att visningskvaliteten är dålig är detta ett implicit behov som bör utforskas som ett uttryckligt behov. Detta kan styras av frågor som "Vilken aspekt av föreställningen menar du?"
Genom att ta $ överklaganden som ett exempel kommer användare att ha följande åtta dimensioner av kraven för lösningen.
$: Pris;
A: tillgänglighet;
P: förpackning;
P: prestanda;
E: lätt att använda;
A: försäkringar;
L: Livscykelkostnad;
S: Socialacceptance.
Kraven bör rankas efter betydelse baserat på projektets prioriteringar och viktiga fokusområden. Detta underlättar designteamets rationella design- och utrustningskonfiguration baserat på dessa prioriteringar.
Kravens insamlingsprocess handlar om att förstå de nuvarande projektbehoven och de mest pressande frågorna som måste tas upp.
Efterfrågan på LED -skärmar kommer vanligtvis från slutanvändare, entreprenörer eller integratorer. Typiska kravinformation kommuniceras till projektföretagspersonal genom projektets anbudsdokument, telefonsamtal, e -postmeddelanden och andra kanaler. Dessa initiala krav samlas sedan in och analyseras tidigt. Denna tidiga analysprocess inkluderar vanligtvis kravbekräftelse och skapandet av en kravlista.
Kravbekräftelse
På grund av de olika källorna och metoderna för krav måste vi utföra sekundär bekräftelse och informationsvisning av kravinformationen. Sekundärbekräftelse innebär att med projektintressenter bekräftas med oklara, felaktiga eller tvetydiga information i kravbeskrivningen för att säkerställa dess noggrannhet. Informationsscreening innebär främst omfattande analys och screening av användarinformation, projektinformation och slutanvändarinformation baserad på tre viktiga element: projekttyp, scenario och process.
1. Bestäm projekttypen.
Olika projekt kräver olika lösningar och har olika prioriteringar. Till exempel prioriterar hyresföretag prestanda och användarvänlighet, medan fasta installationsföretag prioriterar kostnader och stabilitet.
2. Identifiera applikationsscenariot.
Olika applikationsscenarier kräver olika lösningar. Till exempel prioriterar teatrar bildkvaliteten på LED -skärmar, medan sceninstallationer prioriterar funktionaliteten för ED -skärmar.
3. Gå igenom användarupplevelsen.
När olika implementeringsmetoder kan uppfylla samma krav, bör faktiska användarupplevelser och vanor undersökas för att låta designteamet identifiera den optimala lösningen.
Skapa en kravlista
När du har samlat in och bekräftat kravinformation skapar du en kravlista och dokumenterar den. Att dokumentera användarkraven har två betydande fördelar: 1. Det säkerställer effektiv kommunikation inom projektgruppen, vilket minskar interna kommunikationskostnader och säkerställer integriteten i kravinformation under överföring . 2. Det underlättar inspelningen och arkiveringen av kravförändringar, underlättar spårning och övervakning under projektdesignaktiviteter och slutligen fungerar som en checklista för lösning. Lösningar.
Kravlistan bör inkludera, men är inte begränsad till, kravnamn, användare, tidsram, typ, scenario, objekt, beskrivning och prioritet. Vidare bör den faktiska användningen av objektet beskrivas med hänsyn till användarprocesser och vanor, och kraven bör rankas av betydelse.
Kravlista
| Krav | Efterfrågan användare | Krav | Krav | Krav | Krav | Kravbeskrivning | Prioriteringsprioritet |
Lösningsdesign
Efter att ha samlat och bekräftat kraven krävs lösningsdesign. Under lösningens designprocess bör kostnader, kompatibilitet, riskhantering, projektimplementering och andra aspekter övervägas omfattande och den funktionella fullständigheten bör följas.
Designkonceptet är baserat på principerna för tillförlitlig prestanda, avancerad teknik, enkelt underhåll och resursbevarande.
LED Display -skärmdesign inkluderar vanligtvis styrsystemdesign, skärmdesign och konstruktionsdesign. Kontrollsystemets design och skärmdesign är komplementära och är i allmänhet leverantörens ansvar. Konstruktionsdesignen bestäms vanligtvis genom samarbete mellan användaren och byggföretaget.
För närvarande finns det två vanliga installationsmetoder för mainstream LED -skärmar: den ena är att splice LED -moduler, och den andra är att bygga ett LED -skåp. Den förstnämnda erbjuder flexibla lösningar, olika lasttyper, enkelt underhåll och reparation och låga totala projektkostnader. Det senare erbjuder en mer stabil skåpstruktur, snabb och enkel installation, förbättrad skarvning och skåpdesignen, som innehåller strömförsörjningen, mottagningskortet och olika elektroniska komponenter, gör det säkrare att använda. Därför, med hänsyn till alla faktorer, är installationsmetoden för skarvningsmodulen lämplig för de flesta fasta displayinstallationsscenarier på marknaden, medan LED-skåpinstallationsmetoden främst används för stora utomhusskärmar, avancerade fasta displayinstallationer med tillräckliga budgetar och hyresapplikationer. Med tanke på relevansen, praktiken och längden på LED -visningsapplikationer fokuserar denna bok på kontrollsystemdesign inom LED -visningsdesign. Kontrollsystemdesign inkluderar vanligtvis att ta emot kortdesign, styrdesign, tillbehörsdesign och en utrustningslista.
Mottagande kortdesign
För LED -skåpstillverkare beaktas redan marknadspositioneringen och den nödvändiga funktionaliteten för skåpprodukten när skåpet är utformat och släppt. Därför är mottagande kortval ett viktigt övervägande från början av skåpdesign. För kontrollsystemkonstruktioner som använder LED -skåpinstallation finns det därför inget behov av att välja ett mottagande kort eller beräkna dess lastkapacitet. Till exempel säljs ABSENs AW- och DW -serieskåp och Unilumins UGN- och UGM -serie skåp individuellt, med det mottagande kortet redan integrerat och helt felsökat. Slå helt enkelt på skåpet för normal display.
För kontrollsystemkonstruktioner som använder LED -modulskärning måste lämpligt mottagande kortval övervägas baserat på den insamlade informationen. Nyckelfaktorer som påverkar mottagande kortval under kontrollsystemdesign inkluderar modulens dataränta -typ, projektets specifika funktionskrav och mottagningskortets datargruppsformat . 1. Mottagande kortval
1) Typ av moduldatagränssnitt
Datainmatnings-/utgångsgränssnittet för en LED -modul kallas vanligtvis ett navgränssnitt. Den definierar standard "språk" som används vid kommunikation mellan LED -modulen och mottagningskortet. För närvarande finns det många olika Hub -gränssnittstyper på marknaden, där de mest använda är Hub75E och Hub320. Figurerna 2-2-1 och 2-2-2 visar två NOVA-nebula-mottagare: DH426 (för Hub75E-gränssnittet) och DH436 (för Hub320-gränssnittet).
Skillnaden mellan Hub7SE -gränssnittet och Hub320 -gränssnittet ligger i deras definitioner. Moduler med ett Hub75E -gränssnitt innehåller vanligtvis två uppsättningar data, medan moduler med ett HUB320 -gränssnitt innehåller fyra uppsättningar data. Därför bör modulens Hub -gränssnittstyp när du väljer ett mottagande kort vara det primära övervägandet. Inkompatibla gränssnittstyper kan göra det valda mottagningskortet inoperabelt eller inoperabelt direkt, vilket kräver tillägg av ett navadapterkort för att konvertera gränssnittet. Detta ökar projektkomplexiteten och kostnaderna.
2) Specifika funktionella krav i projektet
Baserat på informationen som samlas in från den initiala kravlistan har vi en tydlig förståelse för användarens specifika behov och har bestämt om specifika funktioner krävs. Därför, när du väljer ett mottagande kort, är det viktigt att noggrant överväga användarens specifika behov och kortets funktionella funktioner för att avgöra om en specifik modell eller serie mottagande kort är nödvändig för att implementera den nödvändiga funktionaliteten. I ett projekt måste till exempel användaren upptäcka och hitta (inspektera) utanför kontrollpixlar (döda lampor) på en LED-display. Med Nova Nebula -kontrollsystemet som ett exempel bör den tekniska lösningen inkludera MON300 -övervakningskortet. Detta övervakningskort kan endast användas med en specifik modell för mottagningskort, MRVS60, för att uppnå ovanstående krav.
Det finns många andra specifika funktionella krav, såsom låg latens och HDR. Den specifika lösningen kräver att de relevanta mottagande kortproduktspecifikationer innan du väljer en modell. Om projektet inte kräver sådana speciella funktionskrav är det mottagande kortvalet inte begränsat.
Kontrollsystemtillverkare överväger noggrant marknadspositioneringen av olika modeller för att ta emot kort inom samma serie när de utformar dem och syftar till att ge användare mer flexibla alternativ. Förutom lastkapaciteten är en annan viktig parameter för olika modeller för mottagningskort inom samma serie dataläget, vilket också återspeglas i antalet navportar på mottagningskortet. Till exempel inkluderar NOVA Nebula DH -serien som mottagande kort 8, 12 respektive 16 Hub7se -portar. Hub75E är branschstandarden, med varje port som stöder två grupper av RGB -signaldata. Därför stöder Dh7508, Dh7512 och Dh7516 -mottagningskort högst 16, 24 respektive 32 grupper av data.
Dategrupperna som motsvarar varje navport är ordnade i följd från topp till botten. Den första navporten på DH7508 -mottagningskortet är numrerat 1, anslutning till den första raden med moduler och motsvarande datalegrupper 1 och 2. På liknande sätt motsvarar nummer J2 datalegrupper 3 och 4. På liknande sätt motsvarar nummer J8 datalegrupperna 15 och 16.
När du väljer ett mottagarkort väljs den lämpliga modellen vanligtvis baserat på modulens höjd. Till exempel, om ett projekt använder moduler med en upplösning på 160x80 (pixlar, finns alla upplösningar i den här boken i pixlar) (Hub75E -gränssnitt) för att skapa en 720p (1280x7200) display, vilket mottagande kort ska väljas?
Baserat på upplösningsberäkningar vet vi att LED -displayen består av 9 rader och 8 kolumner med moduler. En 9-radig matris kräver minst 9 navgränssnitt för att stödja den vertikala belastningen. DH7508 -mottagningskortet har emellertid endast 8 navgränssnitt, vilket är otillräckligt för vertikal belastning. Därför bör Dh7512 mottagningskort väljas med sina 9 navgränssnitt. Antalet Dh7512 mottagningskort som krävs för att fullt ut stödja hela displayen kräver ytterligare belastningsberäkningar.
Mottagarkortbelastningsberäkning
Mottagarkortbelastningsberäkning beror främst på det totala antalet pixlar som stöds av mottagningskortet och motsvarande dataläge som används. Beräkningsmetoden är som följer.
De viktigaste övervägandena för att välja en mottagande kortmodell är den totala mottagande kortbelastningskapaciteten och det maximala stödet för datagrupp.
Tänk först på den mottagande kortmodellen baserat på antalet rader och kolumner i modulen. Detta beaktar främst antalet rader. För moduler med upp till 8 rader väljer du ett mottagande kort med 8 navgränssnitt, till exempel Dh7508; För moduler med upp till 12 rader väljer du ett mottagarkort med 12 navgränssnitt, till exempel Dh7512; Och för moduler med upp till 16 rader väljer du ett mottagande kort med 16 navgränssnitt, till exempel Dh7516.
Därefter optimerar du valet baserat på den mottagande kortbelastningskapaciteten. Baserat på modulupplösningen och den mottagande kortupplösningen kan du beräkna det maximala antalet moduler som kan kaskas med ett enda navgränssnitt och det totala antalet mottagarkort som krävs. Om beräkningen visar att ett enda navgränssnitt inte kan stödja en enda modul, kan du överväga att lägga till mottagande kort, minska antalet navgränssnitt eller välja ett mottagande kort med en större lastkapacitet. Taking the Nova Nebula DH7516 receiving card as an example, if hub interfaces 1-4 are used, the receiving card operates in 8-data mode, and the load capacity of a single data group=the total load capacity of the receiving card / 8. If hub interfaces 5-8 are used, the receiving card operates in 16-data mode, and the load capacity of a single data group minus the total load capacity of the receiving card / 16. Om Hub Interfaces 9-16 används fungerar det mottagande kortet i 32-data-läge, och lastkapaciteten för en enda datagrupp minus den totala lastkapaciteten för mottagningskortet / 32.
Generellt sett, genom att beräkna antalet moduler som ett enda mottagande kort kan stödja baserat på specifikationerna för de mottagande korten och modulerna som valts för projektet, kan en rimlig lastdesign göras. Branschanvändare ansluter vanligtvis så många enhetskort som möjligt inom det mottagande kortets lastkapacitet, vilket minskar antalet mottagande kort som används och sänker kostnaderna.
Styrdesign
Styrenheter, ofta kallade sändarkort, är avgörande i LED -displayprojekt. Efter att ha valt och beräknat mottagningskortbelastningen bestäms modellen och mängden mottagningskort i projektet i princip. Därefter utförs kontrollerval och belastningsberäkning för att bestämma modellen och mängden styrenheter i den slutliga lösningen.
Val av kontroller
1) Videoinmatningskälltyp
Kontrollerns primära funktion är att ta emot videosignaler från en front-end videokällanordning eller dator, bearbeta dem till differentiella signaler som är lämpliga för överföring via en nätverkskabel och sedan överföra dessa signaler till mottagningskortet via en nätverksport och kabel för display på LED-displayen. Därför, när du väljer en controller, måste typen av front-end-videokälla beaktas. Till exempel kan ett konferensrum behöva installera en stor industriell ED -skärm, och användaren kräver att ett enda kameravideoflöde visas på skärmen för daglig användning. Kameran använder vanligtvis ett SDI -gränssnitt.
Därför, när du väljer en controller, måste du välja en med ett SDI -gränssnitt, snarare än bara någon styrenhet. Med Nova Cloud Controller som ett exempel kan du välja MCTRL660Pro med ett 3G-SDI-gränssnitt eller MCTRLR5 med ett 6G-SDI-gränssnitt.
Baserat på den information som samlas in i förväg har vi en tydlig förståelse för användarens specifika behov och om några specifika funktioner krävs. Därför, när vi väljer en controller, måste vi noggrant jämföra användarens specifika behov med de funktionella egenskaperna för det mottagande kortet och överväga om en specifik styrmodell krävs för att uppnå motsvarande funktioner.
Till exempel vill en TV -station installera en LED -skärm för live -sändningar. På grund av sändningsegenskaperna för stationen måste LED -displaybilden synkroniseras så nära som möjligt med den levande sändningsbilden och bildfördröjning som påverkar sändningskvaliteten är oacceptabel. På grund av det unika användningsfallet kräver denna lösning ett specifikt funktionskrav, nämligen "låg latens." Vanliga kontroller på marknaden upplever vanligtvis en bildfördröjning med en ram på grund av deras inneboende egenskaper. Om förseningarna på mottagningskortet och LED-displaydrivrutinen tar upp, upplever hela systemet en fördröjning av 3-4-ram, vilket lätt märks för det mänskliga ögat. Därför, när du väljer L660 Pro Controller för denna lösning, bör särskilda överväganden beaktas. Till exempel kan MCTRL660PRO-styrenheten i kombination med A8S/A10S Plus-mottagningskortet minska den totala systemlatensen till cirka två ramar, med nästan noll latens som uppnåtts på kontrollens sida.
