Sensor-OEM-partnerskaber: Hvorfor hardwareproducenter co-sælger med FrostLogic Explore

Foto af Vishnu Mohanan på Unsplash.

Denne er til branchens hardwareside: sensorproducenter, IoT-enhedsproducenter og de måler- og overvågningsleverandører, der bygger det fysiske lag en smart bygning kører på. Hvis I sælger sensorer og overvejer, om et analysepartnerskab er tiden til sales engineering værd, er her argumentet for det, økonomien bag det, og hvad integrationen reelt indebærer.

Problemet en sensor-OEM ikke kan løse alene

En sensor er en komponent. En bygningsoperatør køber ikke komponenter; de køber et svar på "hvad er galt, og hvad skal jeg reparere først". Jeres hardware måler præcist, leverer pålideligt og gør præcis det, databladet lover, og intet af det fortæller et facility-team, hvilken af ti tusind målinger i en portefølje der fortjener opmærksomhed denne uge. Det er et softwareproblem, ikke et hardwareproblem, og det ligger nedstrøms for hver sensor, I sælger, uanset om I bygger analysen selv eller ej.

De fleste sensor-OEM'er ønsker ikke selv at bygge det lag. Det er en anden disciplin, et andet ansættelsesproblem og en anden salgsbevægelse, og at bygge det internt betyder som regel enten års investering eller et tyndt dashboard, ingen bad om. Alternativet er at partnere med et firma, der allerede driver analyselaget, så jeres hardware sælges sammen med en grund til at købe det, mens I forbliver fokuseret på det, I faktisk er gode til: at bygge sensorer.

Co-sell-økonomien, ligeud

Et FrostLogic-sensorpartnerskab er et co-sell-forhold, ikke et OEM-embed og ikke en forhandleraftale. I beholder jeres brand, jeres kanal og jeres margin på hardwaren. Vi beholder inferenslaget: detektion, prognose og én prioriteret kø på tværs af alt, der rapporterer ind. Ingen af siderne bliver den andens systemintegrator, hvilket er bevidst hele pointen, da det at bede et hardwareteam om også at drive en softwaresupport (eller bede et softwareteam om også at lagerføre og RMA'e fysiske enheder) er sådan, partnerskaber går i stå.

Den kommercielle logik går begge veje. En køber, der evaluerer jeres sensorer til en porteføljeudrulning, lukker mere sandsynligt, og lukker større, når pitchet allerede svarer på "hvad gør jeg med dataene" i stedet for at lade det hul stå åbent for indkøb at bekymre sig om senere. Og en bygning, der allerede kører Explore, er en varm dør for hardware, der lukker et dækningshul den eksisterende bestand mangler, introduceret af en partner, der allerede har kontoen, i stedet for koldt. Ingen af siderne gætter på efterspørgslen; køen på den ene side og den installerede base på den anden er begge konkrete signaler om, hvor den andens produkt reelt er nødvendigt.

Hullet Explore ikke kan opfinde sig ud af

Her er den del, der betyder mest for netop et hardwarepublikum: analyse kan udvide, hvad en sensor måler, men den kan ikke fabrikere en måling, der aldrig blev taget nogen steder. Explore kører statistiske baselines, prognoseresidualer, korrelation og fysikbaserede kontroller på tværs af alt, der rapporterer ind, og hvor et punkt reelt mangler, kan en virtuel sensor ofte udlede det fra korrelerede målinger, der allerede findes. Det er reelt, nyttigt, og det er ikke syntetiske data: en virtuel sensor er en beregning bygget på et reelt grundlag, der findes et sted i bygningen. Det, den ikke kan, er at erstatte en fysisk størrelse, som ingen i porteføljen måler overhovedet. Ingen model, uanset hvor sofistikeret, gør en bygning uden vandsensorer til én med lækagedetektion, eller et anlæg uden vibrationsovervågning til ét med advarsler om lejeslid. Korrelationen skal først eksistere i reelle målinger.

Det er en hård grænse, og det er også det reelle argument for et hardwarepartnerskab frem for et rent softwarepartnerskab. Dækningshuller som vand- og lækagedetektion, indendørs luftkvalitet, kølekædens og køleanlægs tilstand, vibrations- og akustisk overvågning af roterende udstyr, personoptælling og belægning — det er områder, hvor løsningen er en rigtig sensor på et rigtigt aktiv, ikke en klogere model. Et partnerskab med hardwareproducenten, der allerede har løst det måleproblem, er, hvordan hullet reelt lukkes, i stedet for at en analyseudbyder lader som om et statistisk trick kan erstatte et instrument, der aldrig blev installeret.

Sådan ser integrationsbevægelsen ud

Den tekniske side er bevidst let for jer. Explore læser, hvad jeres enhed allerede rapporterer, over det interface den allerede taler: BMS-side protokoller som BACnet, Modbus eller OPC UA, hvor jeres sensor rapporterer ind i en bygnings eksisterende system, eller et cloud-API, hvor jeres platform allerede centraliserer enhedstelemetri, før en kundes bygning overhovedet ser den. Begge veje læser en datastrøm, der allerede findes; intet ved integrationen beder jer om at ændre jeres firmware, jeres protokolstak eller jeres egen cloud-arkitektur for at passe til vores.

Data flyder én retning: enhed til Explore. Der er ingen styrekanal at designe, intet kommandosæt at eksponere og ingen tilbageskrivningsevne at bygge ind i jeres hardware, fordi sensortelemetri simpelthen ikke er den type punkt, der overhovedet skrives til. (Explores valgfrie tilbageskrivningsevne gælder kun BMS-styrepunkter, setpunkter og tidsplaner, på bygningssiden; også der er den read-only by default og aktiveres kun scope for scope, når en kunde vælger det. Det har intet at gøre med de sensorer, I bygger.) Det, vi normalt beder om på den tekniske side, er en kort samtale: hvilket protokol eller API jeres enhed eksponerer, hvordan payloaden ser ud, og om der er en sandbox eller testenhed, vi kan validere mod, før en fælles kunde går live. Det meste af det ligger på vores integrationsside for BMS-siden; for en enhed, der rapporterer gennem jeres egen cloud-platform, er det tilsvarende API-dokumentation og en testkonto, ikke et styringsprojekt.

Hvad vi kigger efter i en første sensorpartner

Ikke alle sensorfirmaer er den rette første partner, og det er værd at være ærlig om, hvad der gør et fit reelt frem for teoretisk. De stærkeste fits løser et måleproblem, Explores eksisterende integrationer reelt ikke dækker endnu, sælger til kommercielle ejendoms-, industri- eller porteføljeoperatører, der allerede ligner Explores køber, og har en kanal eller installeret base, hvor et fælles pitch har et konkret sted at lande — en eksisterende kundesamtale, ikke en kold liste. Et partnerskab fungerer bedst, når det starter smalt: et delt prospekt eller én levende bygning, der beviser, at kombinationen er mere værd end hvert produkt alene, før nogen af siderne forpligter sig til noget større.

Ofte stillede spørgsmål

Hvad indebærer et FrostLogic-sensorpartnerskab konkret? Et kommercielt co-sell-forhold. I fortsætter med at sælge jeres hardware under jeres eget brand; Explore læser dataene, den producerer, og forvandler dem til prioriterede fund på tværs af en bygning eller portefølje. Vi aftaler territorium, hvordan leads bevæger sig mellem os, og et første bevis, før vi taler om noget større.

Er det her en OEM-embed-aftale, hvor vores enhed kører FrostLogics software, eller et co-sell-forhold? Co-sell. FrostLogic Explore bliver ikke embeddet i jeres firmware eller solgt under jeres brand; det er et separat analyselag, der læser jeres sensors output og bliver foreslået sammen med jeres hardware i aftaler, hvor køberen har brug for begge dele.

Konkurrerer Explore med vores hardware eller forsøger at erstatte den? Nej. Explore måler intet selv; den har ingen egne sensorer at sælge. Den læser, hvad end der allerede rapporterer ind i en bygning, jeres inklusive, og forvandler de data til beslutninger. Jeres hardware forbliver målelaget; Explore forbliver inferenslaget ovenpå.

Hvorfor har I brug for rigtige sensorpartnere i stedet for bare at modellere de manglende data? Fordi en model kan udvide et eksisterende signal, ikke opfinde ét, der aldrig blev målt. En virtuel sensor kan udlede et punkt fra korrelerede målinger, der allerede findes et sted i bygningen, men den kan ikke trylle en fysisk størrelse frem — vandflow, vibration, luftkvalitet — som ingen i porteføljen måler overhovedet. Det er en reel grænse, ikke et forbehold, og det er præcis det hul, et hardwarepartnerskab lukker.

Skriver Explore nogensinde kommandoer tilbage til vores enheder? Nej. Sensortelemetri flyder én retning, enhed til Explore. Der er ingen kommandokanal og intet at bygge ind i jeres hardware for at understøtte det. Explores tilbageskrivningsevne findes kun på BMS-styresiden, setpunkter og tidsplaner, er read-only by default også der og aktiveres kun scope for scope, når en bygnings egen operatør vælger det.

Hvad har I brug for fra os teknisk for at komme i gang? Hvilket protokol eller API jeres enhed allerede rapporterer over, BACnet, Modbus, OPC UA eller jeres egen cloud-platforms API, plus en sandbox eller testenhed at validere mod, før en fælles kunde går live. Vi beder jer ikke om at bygge et nyt interface til os; vi læser det, I allerede har.

Hvad er et godt første skridt, hvis vi er interesserede? Et delt prospekt eller én levende bygning, ikke en rammeaftale på forhånd. Fortæl os, hvad I måler, og hvem I sælger til, vi siger ligeud, hvor fittet er reelt, og det første bevispunkt er bevidst lille.

Hvis I bygger sensorer, lad os tale dækning

Fortæl os, hvad jeres hardware måler, og hvem der køber den, så siger vi ligeud, om fittet er reelt, og hvordan en første fælles aftale ville se ud. Intet manifest, ingen indkøbspakke. Lad os tale om det.