In het verleden was het bouwen van systemen een vrij eenvoudige aangelegenheid. We zochten de bronnen uit, integrators stopten ze in een rek. Voor die paar die niet in het rek konden, een paar extenders om het signaal naar de processor te krijgen. Dan nog een paar extenders om de signalen naar onze schermen te brengen en voila! Het project was klaar. Ok, niet helemaal zo eenvoudig, maar het algemene idee klopt.
Tegenwoordig is het niet meer zo eenvoudig. Fysieke inputs hebben plaats gemaakt voor steeds meer virtuele inputs. Het maakt onze klanten niet meer uit waar dingen zich bevinden, ze moeten er gewoon toegang toe hebben! Dit begon met beveiligingscamera's. Systemen vereisten vroeger een hardware-apparaat om die webpagina/beveiligingscamerafeed te nemen, er een HDMI van te maken en die dan in het systeem te pluggen. Dit was prima toen webontwikkeling nieuw was... maar na verloop van tijd kregen we steeds meer van deze bronnen nodig. En na verloop van tijd zouden ze in veel gevallen het aantal fysieke ingangen in een systeem overschaduwen. Alsof dat nog niet genoeg was, zorgde de opkomst van data-analyse softwareplatforms en dashboards voor een steeds grotere behoefte aan meer virtuele inputs. Immers, waarom 12 computers wijden aan verschillende dashboards als het gewoon een webpagina is die op het netwerk staat.
In het algemeen is de drijvende factor flexibiliteit geweest. Flexibiliteit voor inputs, flexibiliteit in locatie/afstand, en flexibiliteit in systemen. In een systeem dat op fysieke ingangen is gebaseerd, moeten we, als we plotseling een paar ingangen willen toevoegen aan een systeem dat al vol was, of zelfs een ingang willen toevoegen aan een bedieningsstation dat daar voorheen niet voor was aangesloten (of zich misschien op een ander continent bevond!)... dan moeten we hardware toevoegen, nieuwe kabels trekken, dozen installeren. Niets van dit alles is wenselijk. Maar in het verleden was het noodzakelijk.
Tegenwoordig, met een systeem dat de mogelijkheid biedt om virtuele ingangen toe te voegen, laden we gewoon een softwareclient, laten we de klant deze beheren zoals hij elke andere netwerkbron zou beheren en in een kwestie van minuten hebben we die nieuwe "bron" beschikbaar als een ingang voor het systeem. Geen hardware, geen kabels, geen dozen om te installeren. Het is onmogelijk te minimaliseren hoe groot het voordeel hiervan is als het gaat om het bouwen van systemen. Het is niet alleen gemakkelijker, het is veerkrachtiger, veiliger, en wat schaalbaarheid betreft, zijn de mogelijkheden onbeperkt. We hebben al gezegd dat de bronnen overal kunnen zijn, maar dat is niet het enige grote voordeel. In het verleden, als we een dashboard hadden dat gevoed werd vanaf een PC, dan hadden we ook een backup machine nodig voor het geval de primaire machine faalde... of onderhoud/patching/systeem upgrades nodig had. Dus dat betekende meer hardware, meer rekruimte, enz. Als we virtueel toegang hebben tot een bron, speelt dit allemaal geen rol. Of het nu gaat om het openen van een applicatie om dat dashboard rechtstreeks in de processor en daarmee in de muur te krijgen, of om het ophalen van een H.264 videostream om er zeker van te zijn dat we die camerafeed hebben, geen hardware betekent minder storingspunten en mocht die broncamera een probleem hebben, dan is overschakelen naar een andere camera gewoon een kwestie van een script om naar een andere IP-stream te springen. De totale last van het ondersteunen van virtuele bronnen op het netwerk gaat weg van de systeemintegrator en terug naar de eindklant, er is geen schuld meer aan falende hardware of bronnen die op een bepaald moment niet beschikbaar zijn.
Dat klinkt misschien gemakkelijk, maar het heeft geleid tot een heel ander soort systeemplanning. Het traceren van al deze toepassingen en bronnen is een vereiste. En aangezien de meeste netwerken DHCP gebruiken voor apparaatbeheer, kunnen IP-adressen alleen ons niet altijd helpen. Als gevolg daarvan moet het systeem veel gedetailleerder apparaatnamen en IP-adressen bijhouden om te voorkomen dat we dingen kwijtraken na een netwerkonderhoudsvenster. Bovendien moeten we toegangsgegevens bijhouden om in te loggen op deze virtuele ingangen. Een diepgaander gebruik van API's om in te loggen en te communiceren met apparaten kan ook van cruciaal belang zijn. En ten slotte heeft deze verschuiving naar het netwerk geleid tot een enorme toename van de bandbreedtevereisten. Fabrikanten en systeemintegratoren kunnen deze systemen niet alleen ontwerpen, we moeten nauw samenwerken met een aantal verschillende groepen aan de klantzijde. En wat nog belangrijker is, de fabrikanten MOETEN ervaring hebben op dit gebied en de middelen hebben om u te helpen met de klanten samen te werken.
Het andere grote probleem is op te passen voor bedrijven die leven in "AV-centrische" oplossingen. Hoewel de AV-industrie is wie we zijn, leven deze oplossingen in de IT-wereld. Klanten zullen geen nieuwe VLAN's opzetten om voorbij te gaan aan "vreemde" veiligheidshoudingen of fabrikant-specifieke werking. Of het nu gaat om authenticatiemethodes of gebruikte poorten. Op bedrijfsniveau zijn de ENIGE acceptabele oplossingen die oplossingen die enterprise grade zijn en bestaande industriepraktijken volgen. Integratie in het beleid, de workflows en de systemen van de IT-afdeling is een vereiste omdat het hun leven gemakkelijker maakt.
Meer gebruik maken van virtuele inputs zal de kracht van de oplossingen die u voor uw klanten bouwt radicaal veranderen. De tijd nemen om te werken met bedrijven zoals Jupiter Systems zal het gemakkelijker maken en u helpen het te verkopen aan uw klanten. Jupiter staat al zijn hele leven in de voorhoede van deze evolutie. Zij hebben ervaring en know-how op dit gebied die ongeëvenaard is. En aangezien we als industrie blijven evolueren naar meer en meer virtueel, kunnen zij u helpen om uw klanten opties voor te stellen waarvan u zich misschien niet eens realiseerde dat ze bestonden.
