For at et LED -visningsprosjekt skal utføre og oppnå sine tiltenkte mål, er en omfattende prosjektplan viktig. Hvilke trinn er involvert i utformingen av et LED -skjermkontrollsystem? Hvilke indikatorer og parametere bør vurderes under designprosessen?
LED Display Control System Design Process inkluderer først og fremst fem faser: Kravinnsamling og bekreftelse, løsningsdesign, løsningsgjennomgang, løsningsimplementering og løsning av løsning. Flytskjemaet er vist nedenfor.
Krav samles og verifisering
Krav til innsamling
Kravinnsamling innebærer å utføre grundig og detaljert forskning og analyse av "kravene" eller "behov" uttrykt av prosjektinteressenter. Denne prosessen tar sikte på å forstå de spesifikke kravene til funksjonelle, ytelses- og pålitelighetskrav til både brukere og prosjektet. Denne prosessen oversetter uformelle brukerkrav til en komplett kravdefinisjon, og avklarer dermed hva systemet må gjøre og gi et grunnlag for systemdesign, forbedring og vedlikehold.
Kravinnsamling er et avgjørende skritt i prosjektplanleggingsfasen, ettersom den avgjør hvilken systemfunksjonalitet som må oppnås og gir klar retning for hvordan du skal oppnå den.
Generelt blir kravene kategorisert i forretningskrav, brukerkrav og funksjonelle krav, avhengig av målet
Noen behov er pseudo-behov og mangler praktisk verdi. Brukerbehov skal screenes basert på de tre dimensjonene av ekthet, verdi og gjennomførbarhet. Dette vil filtrere ut de som er falske, umulige eller verdiløse, og dermed destillere brukerens essensielle behov. Å forstå "hvorfor" er viktigere enn "hva" er avgjørende.
Behov kan også kategoriseres som eksplisitte og implisitte. Et eksplisitt behov er en spesifikk uttalelse fra prosjektlederen om utfordringene, nøkkelpunktene og vanskeligheter; Et implisitt behov er en vag uttalelse fra prosjektlederen om utfordringene, sentrale punkter og vanskeligheter. For eksempel, hvis en bruker sier at skjermkvaliteten er dårlig, er dette et implisitt behov som bør utforskes som et eksplisitt behov. Dette kan styres av spørsmål som "Hvilket aspekt av forestillingen mener du?"
Ved å ta $ Appeals -modellen som eksempel, vil brukerne ha følgende åtte dimensjoner av krav til løsningen.
$: Pris;
A: Tilgjengelighet;
P: Emballasje;
P: ytelse;
E: enkel å bruke;
A: forsikringer;
L: Livssykluskostnad;
S: Socialacceptance.
Krav bør rangeres etter betydning basert på prosjektets prioriteringer og viktige fokusområder. Dette vil lette designteamets rasjonelle design- og utstyrskonfigurasjon basert på disse prioriteringene.
Kravsinnsamlingsprosessen handler om å forstå de nåværende prosjektbehovene og de mest presserende problemene som må løses.
Etterspørsel etter LED -skjermer kommer vanligvis fra sluttbrukere, entreprenører eller integratorer. Typiske krav informasjon formidles til prosjektpersonell gjennom prosjektanbudsdokumenter, telefonsamtaler, e -postmeldinger og andre kanaler. Disse innledende kravene blir deretter samlet inn og analysert tidlig. Denne tidlige analyseprosessen inkluderer typisk krav til krav og oppretting av en kravliste.
Kravbekreftelse
På grunn av de forskjellige kravene og metodene for krav, må vi utføre sekundær bekreftelse og informasjonsscreening av kravinformasjonen. Sekundær bekreftelse innebærer å bekrefte med prosjektinteressenter for prosjektet uklar, unøyaktig eller tvetydig informasjon i kravbeskrivelsen for å sikre dens nøyaktighet. Informasjonsscreening innebærer primært omfattende analyse og screening av brukerinformasjon, prosjektinformasjon og sluttbrukerinformasjon basert på tre nøkkelelementer: prosjekttype, scenario og prosess.
1. Bestem prosjekttypen.
Ulike prosjekter krever forskjellige løsninger og har forskjellige prioriteringer. For eksempel prioriterer utleiefirmaer ytelse og brukervennlighet, mens faste installasjonsselskaper prioriterer kostnader og stabilitet.
2. Identifiser applikasjonsscenariet.
Ulike applikasjonsscenarier krever forskjellige løsninger. For eksempel prioriterer teatre bildekvaliteten til LED -skjermer, mens sceneinstallasjoner prioriterer funksjonaliteten til ED -skjermer.
3. Gå gjennom brukeropplevelsen.
Når forskjellige implementeringsmetoder kan oppfylle det samme kravet, bør faktiske brukeropplevelser og vaner utforskes for å la designteamet identifisere den optimale løsningen.
Lag en kravliste
Etter å ha samlet inn og bekreftet informasjonsinformasjon, oppretter du en kravliste og dokumenterer den. Å dokumentere brukerkrav har to vesentlige fordeler: 1. Det sikrer effektiv kommunikasjon i prosjektgruppen, reduserer interne kommunikasjonskostnader og sikrer integriteten til kravinformasjon under overføring . 2. Det letter registrering og arkivering av kravendringer, letter sporing og overvåking under prosjektdesign og til slutt å tjene som en sjekk for løsningen levering av levering av levering.
Kravlisten skal inneholde, men er ikke begrenset til, kravnavnet, brukeren, tidsrammen, type, scenario, element, beskrivelse og prioritet. Videre bør den faktiske bruken av varen beskrives, under hensyntagen til brukerprosesser og vaner, og kravene bør rangeres etter betydning.
Kravliste
| Kravnavn | Krev brukere | Kravstid | Kravtype | Kravsscenario | Krav | Krav Beskrivelse | Kravprioritet |
Løsningsdesign
Etter å ha samlet og bekreftet kravene, er det nødvendig med løsningsdesign. Under løsningsdesignprosessen bør kostnad, kompatibilitet, risikostyring, prosjektgjennomføring og andre aspekter vurderes omfattende, og den funksjonelle fullstendigheten bør følges.
Designkonseptet er basert på prinsippene for pålitelig ytelse, avansert teknologi, enkelt vedlikehold og ressursbevaring.
LED -skjermdesign inkluderer typisk kontrollsystemdesign, skjermdesign og konstruksjonsdesign. Kontrollsystemets design og skjermdesign er komplementære og er generelt leverandørens ansvar. Konstruksjonsdesignen bestemmes vanligvis gjennom samarbeid mellom brukeren og byggefirmaet.
For øyeblikket er det to vanlige installasjonsmetoder for mainstream LED -skjermer: Den ene er å splitte LED -moduler, og den andre er å bygge et LED -skap. Førstnevnte tilbyr fleksible løsninger, forskjellige belastningstyper, enkelt vedlikehold og reparasjon og lave samlede prosjektkostnader. Sistnevnte tilbyr en mer stabil kabinettstruktur, rask og enkel installasjon, forbedret spleisende glatthet, og skapdesignet, som huser strømforsyningen, mottakskort og forskjellige elektroniske komponenter, gjør det tryggere å bruke. Derfor, tar alle faktorer i betraktning, er skjøting av LED-modulinstallasjonsmetoden egnet for de fleste faste installasjonsscenarier på markedet, mens LED-installasjonsmetoden først og fremst brukes til store utendørsskjermer, avanserte faste visningsinstallasjoner med tilstrekkelige budsjetter og leiebrett. Tatt i betraktning relevansen, praktiske og lengden på LED -visningsapplikasjoner, fokuserer denne boken på design av kontrollsystemer innen LED -displaydesign. Kontrollsystemdesign inkluderer typisk mottak av kortdesign, kontrollerdesign, tilbehørsdesign og en utstyrsliste.
Mottar kortdesign
For LED -produsenter er markedsposisjonering og nødvendig funksjonalitet av skapproduktet allerede vurdert når skapet er designet og utgitt. Derfor er det å motta kortvalg en viktig vurdering fra begynnelsen av kabinettdesign. For kontrollsystemdesign som bruker LED -kabinettinstallasjon, er det derfor ikke nødvendig å velge et mottakskort eller beregne lastekapasiteten. For eksempel selges AWM- og DW -serien og UNILUMINs UGN- og UGM -serieskap individuelt, med mottakskortet som allerede er integrert og fullstendig feilsøkte. Bare slå på skapet for normal visning.
For design av kontrollsystemer som bruker skjøting av LED -modul, må riktig mottak av kortvalg vurderes basert på den innsamlede informasjonen. Nøkkelfaktorer som påvirker mottak av kortvalg under kontrollsystemets design inkluderer modulens databrammingstype, prosjektets spesifikke funksjonskrav, og mottakskortets datagruppeformat . 1. Mottakende kortvalg
1) Modul Data Grensesnitttype
Datainndata/utgangsgrensesnittet til en LED -modul kalles vanligvis et hub -grensesnitt. Den definerer standard "språket" som brukes når du kommuniserer mellom LED -modulen og mottakskortet. For øyeblikket er det mange forskjellige hub -grensesnitttyper på markedet, med de mest brukte er Hub75E og Hub320. Figur 2-2-1 og 2-2-2 viser to Nova Nebula-mottakere: DH426 (for Hub75E-grensesnittet) og DH436 (for Hub320-grensesnittet).
Forskjellen mellom Hub7Se -grensesnittet og Hub320 -grensesnittet ligger i deres definisjoner. Moduler med et Hub75E -grensesnitt inneholder vanligvis to sett med data, mens moduler med et Hub320 -grensesnitt inneholder fire sett med data. Derfor, når du velger et mottakskort, bør modulens HUB -grensesnitttype være den primære vurderingen. Inkompatible grensesnitttyper kan gjengi det valgte mottakerkortet som ikke fungerer eller ikke fungerer direkte, noe som nødvendiggjør tillegg av et hub -adaptertavle for å konvertere grensesnittet. Dette øker prosjektkompleksiteten og kostnadene.
2) Spesifikke funksjonelle krav i prosjektet
Basert på informasjonen som er samlet inn fra den innledende kravlisten, har vi en klar forståelse av brukerens spesifikke behov og har bestemt om spesifikke funksjoner er påkrevd. Derfor, når du velger et mottakskort, er det viktig å vurdere brukerens spesifikke behov og kortets funksjonelle funksjoner nøye for å avgjøre om en spesifikk modell eller en serie mottakskort er nødvendig for å implementere den nødvendige funksjonaliteten. For eksempel, i ett prosjekt, må brukeren oppdage og lokalisere (inspisere) ut-av-kontroll-piksler (døde lys) på en LED-skjerm. Når du tar Nova Nebula -kontrollsystemet som et eksempel, bør den tekniske løsningen omfatte Mon300 -overvåkningskortet. Dette overvåkningskortet kan bare brukes med en spesifikk modell for mottakskort, MRVS60, for å oppnå ovennevnte krav.
Det er mange andre spesifikke funksjonskrav, for eksempel lav latens og HDR. Den spesifikke løsningen krever å konsultere de relevante mottaker av kortproduktspesifikasjoner før du velger en modell. Hvis prosjektet ikke krever slike spesielle funksjonskrav, er ikke mottak av kortet begrenset.
Produsenter av kontrollsystemer vurderer nøye markedsposisjonering av forskjellige modeller for å motta kort i samme serie når de designer dem, og tar sikte på å gi brukerne mer fleksible alternativer. Foruten lastekapasiteten, er en annen viktig parameter for forskjellige modeller for å motta kort i samme serie Data Group Mode, som også gjenspeiles i antall navporter på mottakskortet. For eksempel inkluderer Nova Nebula DH -serien som mottar kort henholdsvis 8, 12 og 16 Hub7se -porter. Hub75E er bransjestandarden, med hver port som støtter to grupper av RGB -signaldata. Derfor støtter DH7508, DH7512 og DH7516 mottakerkort maksimalt 16, 24 og 32 grupper av data, . 3) datagruppemodus for mottakerkortet
Datagruppene som tilsvarer hver hub -port er ordnet sekvensielt fra topp til bunn. Den første hub -porten på mottakskortet Dh7508 er nummerert 1, koblet til den første raden med moduler og tilsvarer datagrupper 1 og 2. Tilsvarende tilsvarer nummer J2 datagrupper 3 og 4.. Tilsvarende tilsvarer nummer J8 til datagrupper 15 og 16.
Når du velger et mottakskort, blir den aktuelle modellen vanligvis valgt basert på modulens høyde. For eksempel, hvis et prosjekt bruker moduler med en oppløsning på 160x80 (piksler, er alle oppløsninger i denne boken i piksler) (Hub75E -grensesnittet) for å lage et 720p (1280x7200) skjerm, hvilket mottakskort som skal velges?
Basert på oppløsningsberegninger, vet vi at LED -skjermen er sammensatt av 9 rader og 8 kolonner med moduler. En 9-rads matrise krever minst 9 hub-grensesnitt for å støtte den vertikale belastningen. Imidlertid har Mottakskortet DH7508 bare 8 HUB -grensesnitt, noe som ikke er tilstrekkelig for vertikal belastning. Derfor bør mottakskortet DH7512 velges ved å bruke sine 9 hub -grensesnitt. Antallet DH7512 Mottakskort som kreves for å støtte hele skjermen krever ytterligere belastningsberegninger.
Mottakerkortbelastningsberegning
Mottakerkortbelastningsberegning avhenger først og fremst av det totale antall piksler som støttes av mottakskortet og den tilsvarende datagruppemodus som brukes. Beregningsmetoden er som følger.
Hovedhensynene for å velge en mottakende kortmodell er den totale mottakende kortbelastningskapasiteten og maksimal støttet datagruppemodus.
Først må du vurdere mottakende kortmodell basert på antall rader og kolonner i modulen. Dette vurderer først og fremst antall rader. For moduler med opptil 8 rader, velg et mottakskort med 8 HUB -grensesnitt, for eksempel DH7508; For moduler med opptil 12 rader, velg et mottakskort med 12 HUB -grensesnitt, for eksempel DH7512; Og for moduler med opptil 16 rader, velger du et mottakskort med 16 HUB -grensesnitt, for eksempel DH7516.
Deretter, optimaliser utvalget basert på mottaker av kortbelastningskapasitet. Basert på moduloppløsningen og mottakskortoppløsningen, kan du beregne det maksimale antall moduler som kan kaskaderes med et enkelt knutepunktgrensesnitt og det totale antallet mottakskort som kreves. Hvis beregningen viser at et enkelt hub -grensesnitt ikke kan støtte en enkelt modul, kan du vurdere å legge til mottakskort, redusere antall navgrensesnitt eller velge et mottakskort med større lastekapasitet. Hvis du tar Nova Nebula Dh7516 mottakskort som et eksempel, hvis hub-grensesnitt 1-4 brukes, fungerer mottakskortet i 8-datamodus, og lastekapasiteten til en enkelt datagruppe=Total lastekapasitet på Mottakende kort / 8. HUB-modus 5-belastning på en enkelt databehandling av en lastkapasitet i en lastkapasitet i en lastekapasitet i en lastkapasitet i en lastkapasitet på en enkelt lastkapasitet i den totale belastningen på en enkelt lastkapasitet i en enkelt datakapasitet på en enkelt datagruppe {=}. Mottakskortet / 16. Hvis navgrensesnitt 9-16 brukes, fungerer mottakskortet i 32-datamodus, og lastekapasiteten til en enkelt datagruppe minus den totale lastekapasiteten til mottakskortet / 32.
Generelt sett, ved å beregne antall moduler som et enkelt mottakskort kan støtte basert på spesifikasjonene til mottakskortene og modulene som er valgt for prosjektet, kan det gjøres en rimelig lastdesign. Bransjebrukere kobler typisk så mange enhetsbrett som mulig i mottakskortets lastekapasitet, og reduserer dermed antall mottakende kort som brukes og senker kostnadene.
Kontrollerdesign
Kontrollere, ofte referert til som senderkort, er avgjørende i LED -visningsprosjekter. Etter å ha valgt og beregnet mottakskortbelastningen, bestemmes modellen og mengden mottak av kort i prosjektet i utgangspunktet. Deretter utføres kontrollervalg og belastningsberegning for å bestemme modellen og mengden av kontrollere i den endelige løsningen.
Kontrollervalg
1) Videoinngangskilde type
Kontrollerens primære funksjon er å motta videosignaler fra en front-end videokildeenhet eller datamaskin, behandle dem til differensialsignaler som er egnet for overføring via en nettverkskabel, og deretter overføre disse signalene til mottakskortet via en nettverksport og kabel for visning på LED-skjermen. Derfor, når du velger en kontroller, må typen front-end videoinngangskilde vurderes. For eksempel kan det hende at et konferanserom trenger å installere en stor industriell ED -skjerm, og brukeren krever at en enkelt kamera -videofeed vises på skjermen for daglig bruk. Kameraet bruker typisk et SDI -grensesnitt.
Derfor, når du velger en kontroller, må du velge en med et SDI -grensesnitt, i stedet for bare noen kontroller. Når du tar Nova Cloud Controller som eksempel, kan du velge MCTRL660PRO med ett 3G-SDI-grensesnitt eller MCTRLR5 med et 6G-SDI-grensesnitt.
Basert på informasjonen som er samlet inn på forhånd, har vi en klar forståelse av brukerens spesifikke behov og om noen spesifikke funksjoner er nødvendige. Derfor, når vi velger en kontroller, må vi nøye sammenligne brukerens spesifikke behov med de funksjonelle egenskapene til mottakskortet og vurdere om en spesifikk kontrollermodell er nødvendig for å oppnå de tilsvarende funksjonene.
For eksempel ønsker en TV -stasjon å installere en LED -skjerm for direktesendinger. På grunn av kringkastingsegenskapene til stasjonen, må LED -skjermbildet synkroniseres så nært som mulig med direktesendingsbildet, og bildeforsinkelse som påvirker kringkastingskvaliteten er uakseptabel. På grunn av den unike brukssaken, nødvendiggjør denne løsningen et spesifikt funksjonskrav, nemlig "lav latens." Vanlige kontrollere på markedet opplever typisk en forsinkelse på en ramme på grunn av deres iboende egenskaper. Hvis forsinkelsene på mottakskortet og LED-skjermdriveren IC er innarbeidet, opplever hele systemet en forsinkelse på 3-4-rammer, noe som lett merkes for det menneskelige øyet. Derfor, når du velger L660 Pro -kontrolleren for denne løsningen, bør spesielle hensyn tas i betraktning. For eksempel kan MCTRL660PRO-kontrolleren sammenkoblet med A8S/A10S pluss mottakskort redusere den totale systemets latens til omtrent to rammer, med nesten null latens oppnådd på kontrollersiden.
