For et LED -displayprojekt, der skal udføres og nå sine tilsigtede mål, er en omfattende projektplan vigtig. Hvilke trin er involveret i at designe et LED -displaystyringssystem? Hvilke indikatorer og parametre skal overvejes under designprocessen?
LED -displaystyringssystemets designproces inkluderer primært fem faser: kravindsamling og bekræftelse, løsningsdesign, løsningsgennemgang, implementering af løsningen og levering af løsning. Flowdiagrammet er vist nedenfor.
Krav indsamling og verifikation
Kravsamling
Kravindsamling involverer at gennemføre dybdegående og detaljeret forskning og analyse af "kravene" eller "behov" udtrykt af projektinteressenter. Denne proces sigter mod nøjagtigt at forstå de specifikke funktionelle, ydelse og pålidelighedskrav hos både brugere og projektet. Denne proces oversætter uformelle brugerkrav til en komplet kravdefinition og klarer derved, hvad systemet skal gøre, og tilvejebringe et grundlag for systemdesign, forbedring og vedligeholdelse.
Kravindsamling er et afgørende trin i projektplanlægningsfasen, da det bestemmer, hvilken systemfunktionalitet der skal opnås og giver klar retning for, hvordan man kan opnå det.
Generelt er kravene kategoriseret i forretningskrav, brugerkrav og funktionelle krav, afhængigt af målet
Nogle behov er pseudo-behov og mangler praktisk værdi. Brugerbehov skal screenes baseret på de tre dimensioner af ægthed, værdi og gennemførlighed. Dette vil filtrere dem, der er falske, uundgåelige eller værdiløse, og derved destilleres brugerens væsentlige behov. At forstå "hvorfor" er vigtigere end "hvad" er afgørende.
Behov kan også kategoriseres som eksplicit og implicit. Et eksplicit behov er en bestemt erklæring fra projektlederen om udfordringer, nøglepunkter og vanskeligheder; Et implicit behov er en vag erklæring fra projektlederen om udfordringer, nøglepunkter og vanskeligheder. For eksempel, hvis en bruger siger, at skærmkvaliteten er dårlig, er dette et implicit behov, der skal udforskes som et eksplicit behov. Dette kan styres af spørgsmål som "Hvilket aspekt af forestillingen mener du?"
Ved at tage $ appelmodellen som et eksempel vil brugerne have følgende otte dimensioner af krav til løsningen.
$: Pris;
A: tilgængelighed;
P: emballage;
P: ydeevne;
E: Let at bruge;
A: Forsikringer;
L: Livscyklusomkostninger;
S: Socialacceptance.
Krav skal rangeres efter betydning baseret på projektets prioriteringer og centrale fokusområder. Dette vil lette designteamets rationelle design- og udstyrskonfiguration baseret på disse prioriteter.
Kravindsamlingsprocessen handler om at forstå de aktuelle projektbehov og de mest presserende problemer, der skal behandles.
Efterspørgslen efter LED -skærme kommer typisk fra slutbrugere, entreprenører eller integratorer. Typiske kravoplysninger kommunikeres til projektforretningspersonale gennem projektudbudsdokumenter, telefonopkald, e -mails og andre kanaler. Disse oprindelige krav indsamles og analyseres derefter tidligt. Denne tidlige analyseproces inkluderer typisk kravbekræftelse og oprettelse af en kravliste.
Krav Bekræftelse
På grund af de forskellige kilder og metoder til krav, er vi nødt til at gennemføre sekundær bekræftelse og informationsscreening af kravinformationen. Sekundær bekræftelse involverer bekræftelse med projektinteressenter med uklare, unøjagtige eller tvetydige oplysninger i kravbeskrivelsen for at sikre dens nøjagtighed. Informationsscreening involverer primært omfattende analyse og screening af brugeroplysninger, projektinformation og information om slutbruger baseret på tre nøgleelementer: projekttype, scenarie og proces.
1. Bestem projekttypen.
Forskellige projekter kræver forskellige løsninger og har forskellige prioriteter. For eksempel prioriterer udlejningsfirmaer ydelse og brugervenlighed, mens faste installationsfirmaer prioriterer omkostninger og stabilitet.
2. Identificer applikationsscenariet.
Forskellige applikationsscenarier kræver forskellige løsninger. F.eks. Prioriterer teatre billedkvaliteten på LED -skærme, mens sceneinstallationer prioriterer funktionaliteten af ED -skærme.
3. gå gennem brugeroplevelsen.
Når forskellige implementeringsmetoder kan opfylde det samme krav, bør faktiske brugeroplevelser og vaner udforskes for at give designteamet mulighed for at identificere den optimale løsning.
Opret en kravliste
Når du har indsamlet og bekræftet kravoplysninger, skal du oprette en kravliste og dokumentere den. Dokumentation af brugerkrav har to betydelige fordele: 1. Det sikrer effektiv kommunikation inden for projektteamet, reducerer interne kommunikationsomkostninger og sikrer integriteten af kravoplysninger under overførsel . 2. Det letter optagelsen og arkivering af kravændringer, letter sporing og overvågning under projektdesignaktiviteter og i sidste ende serverer som en checklist til løsning af levering.
Kravlisten skal indeholde, men er ikke begrænset til, kravnavnet, bruger, tidsramme, type, scenarie, vare, beskrivelse og prioritet. Desuden skal den faktiske anvendelse af varen beskrives under hensyntagen til brugerprocesser og vaner, og kravene skal rangeres efter betydning.
Liste over krav
| Kravnavn | Efterspørgselsbrugere | Kravstid | Kravstype | Kravscenarie | Kravelement | Kravbeskrivelse | Krav prioritet |
Løsningsdesign
Efter indsamling og bekræftelse af kravene kræves løsningsdesign. Under løsningsprocessen skal omkostninger, kompatibilitet, risikostyring, projektimplementering og andre aspekter overvejes omfattende, og den funktionelle fuldstændighed bør overholdes.
Designkonceptet er baseret på principperne om pålidelig ydelse, avanceret teknologi, let vedligeholdelse og ressourcebevaring.
LED -display -skærmdesign inkluderer typisk kontrolsystemdesign, displayskærmdesign og konstruktionsdesign. Kontrolsystemdesign- og displaeskærmdesignet er komplementære og er generelt leverandørens ansvar. Konstruktionsdesignet bestemmes typisk gennem samarbejde mellem brugeren og byggefirmaet.
I øjeblikket er der to almindelige installationsmetoder til mainstream LED -skærme: den ene er at splitte LED -moduler, og den anden er at bygge et LED -skab. Førstnævnte tilbyder fleksible løsninger, forskellige belastningstyper, let vedligeholdelse og reparation og lave samlede projektomkostninger. Sidstnævnte tilbyder en mere stabil skabsstruktur, hurtig og nem installation, forbedret splejsning af glathed og kabinetdesignet, der huser strømforsyningen, modtagelseskortet og forskellige elektroniske komponenter, gør det mere sikkert at bruge. Derfor under hensyntagen til alle faktorer er Splicing LED-modulinstallationsmetoden velegnet til de fleste faste displayinstallationsscenarier på markedet, mens LED-kabinetinstallationsmetoden primært bruges til store udendørs skærme, avancerede faste displayinstallationer med tilstrækkelige budgetter og lejeanvendelser. I betragtning af relevansen, praktisk og længde af LED -displayapplikationer fokuserer denne bog på design af styresystem inden for LED -display -design. Kontrolsystemdesign inkluderer typisk modtagelse af kortdesign, controller -design, tilbehørsdesign og en udstyrsliste.
Modtagelse af kortdesign
For LED -kabinetproducenter overvejes markedspositionering og krævet funktionalitet af kabinetsproduktet allerede, når kabinettet er designet og frigivet. Derfor er modtagelse af kortvalg en vigtig overvejelse fra starten af kabinetdesign. Derfor er det ikke nødvendigt at vælge et modtagende kort eller beregne dets belastningskapacitet for kontrolsystemdesign, der bruger LED -kabinetinstallation. For eksempel sælges Abens AW- og DW -serieskabe og Unilumins UGN- og UGM -serieskabe individuelt med det modtagende kort, der allerede er integreret og fuldt fejlagtigt. Strøm blot på kabinettet til normal display.
For kontrolsystemdesign, der bruger LED -modulopspaltning, skal det passende modtagelseskortvalg overvejes baseret på de indsamlede oplysninger. Nøglefaktorer, der påvirker modtagelseskortvalg under kontrolsystemdesign, inkluderer modulets databrænsefladetype, projektets specifikke funktionelle krav og modtagelseskortets datagruppeformat . 1. Modtagelse af kortvalg
1) Moduldata -interface -type
Datainput/output -grænsefladen for et LED -modul kaldes typisk en hubgrænseflade. Det definerer standard "sprog", der bruges, når man kommunikerer mellem LED -modulet og det modtagende kort. I øjeblikket er der mange forskellige hubgrænsefladetyper på markedet, hvor den mest almindeligt anvendte er HUB75E og HUB320. Figur 2-2-1 og 2-2-2 viser to Nova Nebula-modtagere: DH426 (for HUB75E-interface) og DH436 (for HUB320-interface).
Forskellen mellem HUB7SE -interface og HUB320 -interface ligger i deres definitioner. Moduler med en HUB75E -interface indeholder typisk to datasæt, mens moduler med en HUB320 -interface indeholder fire sæt data. Derfor skal modulets hubgrænsefladetype være den primære overvejelse, når man vælger et modtagelseskort. Inkompatible interfacetyper kan gøre det valgte modtagelseskort uoperabelt eller inoperabelt direkte, hvilket kræver tilføjelse af et hubadapterkort for at konvertere grænsefladen. Dette øger projektkompleksiteten og omkostningerne.
2) Specifikke funktionelle krav til projektet
Baseret på de oplysninger, der er indsamlet fra listen over indledende krav, har vi en klar forståelse af brugerens specifikke behov og har bestemt, om der kræves specifikke funktioner. Derfor er det vigtigt at overveje brugerens specifikke behov og kortets funktionelle funktioner, når man vælger et modtagelseskort. I et projekt skal brugeren f.eks. Registrere og lokalisere (inspicere) out-of-control pixels (døde lys) på en LED-skærm. Ved at tage Nova Nebula -kontrolsystemet som eksempel skal den tekniske løsning omfatte MON300 -overvågningskort. Dette overvågningskort kan kun bruges med en bestemt model for modtagelseskort, MRVS60, for at opnå ovenstående krav.
Der er mange andre specifikke funktionelle krav, såsom lav latenstid og HDR. Den specifikke løsning kræver rådgivning af de relevante modtagelseskortproduktspecifikationer, inden du vælger en model. Hvis projektet ikke kræver så specielle funktionelle krav, er det ikke begrænset modtagelseskort.
Producenter af kontrolsystemer overvejer omhyggeligt markedspositionering af forskellige modeller for modtagelseskort inden for den samme serie, når de designer dem, med det formål at give brugerne mere fleksible muligheder. Udover belastningskapaciteten er en anden vigtig parameter for forskellige modeller for modtagelseskort inden for den samme serie datagruppetilstand, hvilket også afspejles i antallet af hub -porte på modtagelseskortet. For eksempel inkluderer Nova Nebula DH -serien, der modtager kort, henholdsvis 8, 12 og 16 Hub7se -porte. HUB75E er branchestandarden, hvor hver port understøtter to grupper af RGB -signaldata. Derfor understøtter DH7508, DH7512 og DH7516 modtagelseskort højst 16, 24 og 32 grupper af data, henholdsvis . 3) datagruppetilstand for modtagerkortet
Datagrupperne svarende til hver hub -port er arrangeret sekventielt fra top til bund. Den første hub -port på Dh7508 -modtagelseskortet er nummereret 1, der forbinder til den første række af moduler og svarer til datagrupper 1 og 2.. Tilsvarende svarer tal J2 til datagrupper 3 og 4.. Tilsvarende svarer tal J8 til datagrupper 15 og 16.
Når du vælger et modtagelseskort, vælges den relevante model normalt baseret på modulets højde. For eksempel, hvis et projekt bruger moduler med en opløsning på 160x80 (pixels, er alle opløsninger i denne bog i pixels) (HUB75E -interface) for at oprette en 720p (1280x7200) display, hvilket modtagelseskort skal vælges?
Baseret på opløsningsberegninger ved vi, at LED -displayet er sammensat af 9 rækker og 8 kolonner med moduler. En 9-række array kræver mindst 9 hubgrænseflader for at understøtte den lodrette belastning. Imidlertid har DH7508 -modtagelseskortet kun 8 hubgrænseflader, hvilket er utilstrækkeligt til lodret belastning. Derfor skal DH7512 -modtagelseskortet vælges ved hjælp af dets 9 hub -grænseflader. Antallet af DH7512 -modtagelseskort, der kræves for fuldt ud at understøtte hele displayet, kræver yderligere belastningsberegninger.
Beregning af modtagerkortets belastning
Beregning af modtagerkortbelastning afhænger primært af det samlede antal pixels understøttet af det modtagende kort og den tilsvarende datagruppetilstand. Beregningsmetoden er som følger.
De vigtigste overvejelser til at vælge en modtagende kortmodel er den samlede modtagende kortbelastningskapacitet og den maksimale understøttede datagruppetilstand.
Overvej først den modtagende kortmodel baseret på antallet af rækker og kolonner i modulet. Dette overvejer primært antallet af rækker. For moduler med op til 8 rækker skal du vælge et modtagelseskort med 8 hubgrænseflader, såsom DH7508; For moduler med op til 12 rækker skal du vælge et modtagelseskort med 12 hubgrænseflader, såsom DH7512; Og for moduler med op til 16 rækker skal du vælge et modtagelseskort med 16 hubgrænseflader, såsom DH7516.
Optimer derefter valget baseret på den modtagende kortbelastningskapacitet. Baseret på modulopløsningen og den modtagende kortopløsning kan du beregne det maksimale antal moduler, der kan kaskaderes med en enkelt hubgrænseflade og det samlede antal, der kræves. Hvis beregningen viser, at en enkelt hubgrænseflade ikke kan understøtte et enkelt modul, skal du overveje at tilføje modtagelseskort, reducere antallet af hubgrænseflader eller vælge et modtagelseskort med en større belastningskapacitet. At tage Nova Nebula Dh7516-modtagelseskortet som et eksempel, hvis hubgrænseflader 1-4 bruges, fungerer modtagelseskortet i 8-data-tilstand, og belastningskapaciteten for en enkelt datagruppe=Den samlede belastningskapacitet for modtagelseskort / 16. Hvis hubgrænseflader 9-16 bruges, fungerer modtagelseskortet i 32-data-tilstand, og belastningskapaciteten for en enkelt datagruppe minus den samlede belastningskapacitet for det modtagende kort / 32.
Generelt kan man ved at beregne antallet af moduler, som et enkelt modtagelseskort kan understøtte baseret på specifikationerne for de modtagende kort og moduler, der er valgt til projektet, et rimeligt belastningsdesign. Branchebrugere forbinder typisk så mange enhedsbestyrelser som muligt inden for modtagelseskortets belastningskapacitet og reducerer derved antallet af modtagende kort, der bruges og sænker omkostninger.
Controller -design
Controllere, ofte benævnt transmitterkort, er afgørende i LED -displayprojekter. Efter at have valgt og beregnet den modtagende kortbelastning bestemmes modellen og mængden af modtagelseskort i projektet dybest set. Dernæst udføres controller -valg og belastningsberegning for at bestemme modellen og mængden af controllere i den endelige løsning.
Valg af controller
1) Video input kildetype
Controllerens primære funktion er at modtage videosignaler fra en front-end videokildeenhed eller computer, behandle dem til differentielle signaler, der er egnede til transmission via et netværkskabel, og derefter transmittere disse signaler til det modtagende kort via en netværksport og kabel til visning på LED-displayet. Når du vælger en controller, skal typen af front-end videoindgangskilde derfor overvejes. For eksempel kan et konferencelokale muligvis installere en stor industriel ED -skærm, og brugeren kræver, at et enkelt kamera -videofeed vises på skærmen til daglig brug. Kameraet bruger typisk en SDI -grænseflade.
Derfor skal du vælge en med en SDI -grænseflade, snarere end bare enhver controller, når du vælger en controller, skal du vælge en med en SDI -grænseflade. Når du tager Nova Cloud-controlleren som et eksempel, kan du vælge MCTRL660PRO med en 3G-SDI-interface eller MCTRLR5 med en 6G-SDI-interface.
Baseret på de oplysninger, der er indsamlet på forhånd, har vi en klar forståelse af brugerens specifikke behov, og om der kræves specifikke funktioner. Derfor skal vi omhyggeligt sammenligne brugerens specifikke behov med de funktionelle egenskaber ved det modtagende kort, når vi vælger en controller, og overvej omhyggeligt at opnå de tilsvarende funktioner.
For eksempel ønsker en tv -station at installere en LED -skærm til live -udsendelser. På grund af stationens udsendelsesegenskaber skal LED -displaybilledet synkroniseres så tæt som muligt med det levende udsendelsesbillede, og billedforsinkelse, der påvirker udsendelseskvaliteten, er uacceptabel. På grund af den unikke brugssag kræver denne løsning et specifikt funktionelt krav, nemlig "lav latenstid." Almindelige controllere på markedet oplever typisk en en-ramme-billedforsinkelse på grund af deres iboende egenskaber. Hvis forsinkelserne på det modtagende kort og LED-display-driver IC er indarbejdet i, oplever hele systemet en 3-4-rammeforsinkelse, som let kan ses for det menneskelige øje. Derfor skal der tages hensyn til, når man vælger L660 Pro -controlleren til denne løsning, skal tages i betragtning. F.eks. Kan MCTRL660PRO-controller parret med A8S/A10S plus modtagelseskort reducere den samlede systemlatens til cirka to rammer, med næsten nul latenstid opnået på controllersiden.
