Sensor-OEM-partnerskap: Hvorfor maskinvareprodusenter co-selger med FrostLogic Explore

Foto av Vishnu Mohanan på Unsplash.

Denne er til bransjens maskinvareside: sensorprodusenter, IoT-enhetsprodusenter og de måle- og overvåkingsleverandørene som bygger det fysiske laget en smart bygning kjører på. Hvis dere selger sensorer og vurderer om et analysepartnerskap er verdt sales engineering-tiden, er her argumentet for det, økonomien bak det, og hva integrasjonen faktisk innebærer.

Problemet en sensor-OEM ikke kan løse alene

En sensor er en komponent. En bygningsoperatør kjøper ikke komponenter; de kjøper et svar på "hva er galt, og hva bør jeg fikse først". Deres maskinvare måler presist, leverer pålitelig og gjør nøyaktig det databladet lover, og ingenting av det forteller et facility-team hvilken av ti tusen målinger i en portefølje som fortjener oppmerksomhet denne uken. Det er et programvareproblem, ikke et maskinvareproblem, og det ligger nedstrøms for hver sensor dere selger, uansett om dere bygger analysen selv eller ikke.

De fleste sensor-OEM-er ønsker ikke å bygge det laget selv. Det er en annen disiplin, et annet rekrutteringsproblem og en annen salgsbevegelse, og å bygge det internt betyr som regel enten års investering eller et tynt dashbord ingen ba om. Alternativet er å partne med et selskap som allerede driver analyselaget, slik at deres maskinvare selges sammen med en grunn til å kjøpe den, mens dere fortsetter å fokusere på det dere faktisk er gode på: å bygge sensorer.

Co-sell-økonomien, rett fram

Et FrostLogic-sensorpartnerskap er et co-sell-forhold, ikke en OEM-embed og ikke en forhandleravtale. Dere beholder merkevaren, kanalen og marginen deres på maskinvaren. Vi beholder inferenslaget: deteksjon, prognostisering og én prioritert kø på tvers av alt som rapporterer inn. Ingen av sidene blir den andres systemintegrator, noe som bevisst er hele poenget, siden det å be et maskinvareteam også drifte en programvare-support (eller be et programvareteam også lagerføre og RMA-håndtere fysiske enheter) er hvordan partnerskap kjører seg fast.

Den kommersielle logikken går begge veier. En kjøper som vurderer sensorene deres for en porteføljeutrulling, lukker mer sannsynlig, og lukker større, når pitchen allerede svarer på "hva gjør jeg med dataene" i stedet for å la det hullet stå åpent for innkjøp å bekymre seg om senere. Og en bygning som allerede kjører Explore, er en varm dør for maskinvare som tetter et dekningshull den eksisterende bestanden mangler, introdusert av en partner som allerede har kontoen i stedet for kaldt. Ingen av sidene gjetter på etterspørselen; køen på den ene siden og den installerte basen på den andre er begge konkrete signaler om hvor den andres produkt faktisk trengs.

Hullet Explore ikke kan finne opp seg ut av

Her er delen som betyr mest for nettopp et maskinvarepublikum: analyse kan utvide det en sensor måler, men den kan ikke fabrikere en måling som aldri ble tatt noe sted. Explore kjører statistiske baselines, prognoseresidualer, korrelasjon og fysikkbaserte kontroller på tvers av alt som rapporterer inn, og der et punkt genuint mangler, kan en virtuell sensor ofte utlede det fra korrelerte målinger som allerede finnes. Det er reelt, nyttig, og det er ikke syntetiske data: en virtuell sensor er en beregning bygget på et reelt grunnlag som finnes et sted i bygningen. Det den ikke kan gjøre, er å erstatte en fysisk størrelse som ingen i porteføljen måler i det hele tatt. Ingen modell, uansett hvor sofistikert, gjør en bygning uten vannsensorer til én med lekkasjedeteksjon, eller et anlegg uten vibrasjonsovervåking til ett med varsler om lagerslitasje. Korrelasjonen må først finnes i reelle målinger.

Det er en hard grense, og det er også det egentlige argumentet for et maskinvarepartnerskap fremfor et rent programvarepartnerskap. Dekningshull som vann- og lekkasjedeteksjon, inneluftkvalitet, kjølekjedens og kjøleanleggs tilstand, vibrasjons- og akustisk overvåking av roterende utstyr, personetelling og belegg — dette er områder hvor løsningen er en ekte sensor på en ekte eiendel, ikke en smartere modell. Et partnerskap med maskinvareprodusenten som allerede har løst det måleproblemet, er hvordan hullet faktisk tettes, i stedet for at en analyseleverandør later som om et statistisk triks kan erstatte et instrument som aldri ble installert.

Slik ser integrasjonsbevegelsen ut

Den tekniske siden er bevisst lett for dere. Explore leser det enheten deres allerede rapporterer, over det grensesnittet den allerede snakker: BMS-side protokoller som BACnet, Modbus eller OPC UA der sensoren deres rapporterer inn i en bygnings eksisterende system, eller et sky-API der plattformen deres allerede sentraliserer enhetstelemetri før en kundes bygning i det hele tatt ser den. Begge veier leser en datastrøm som allerede finnes; ingenting ved integrasjonen ber dere om å endre firmwaren, protokollstakken eller deres egen skyarkitektur for å passe til vår.

Data flyter én retning: enhet til Explore. Det er ingen styringskanal å designe, ingen kommandosett å eksponere og ingen tilbakeskrivingsevne å bygge inn i maskinvaren deres, fordi sensortelemetri rett og slett ikke er den typen punkt det skrives til i det hele tatt. (Explores valgfrie tilbakeskrivingsevne gjelder kun BMS-styringspunkter, børverdier og tidsplaner, på bygningssiden; også der er den read-only by default og slås på bare scope for scope når en kunde velger det. Det har ingenting med sensorene dere bygger å gjøre.) Det vi vanligvis trenger på den tekniske siden, er en kort samtale: hvilken protokoll eller API enheten deres eksponerer, hvordan payloaden ser ut, og om det finnes en sandbox eller testenhet vi kan validere mot før en felles kunde går live. Det meste av dette ligger på integrasjonssiden vår for BMS-siden; for en enhet som rapporterer gjennom deres egen skyplattform, er det tilsvarende API-dokumentasjon og en testkonto, ikke et styringsprosjekt.

Hva vi ser etter i en første sensorpartner

Ikke alle sensorselskaper er den riktige første partneren, og det er verdt å være ærlig om hva som gjør et fit reelt fremfor teoretisk. De sterkeste fitene løser et måleproblem Explores eksisterende integrasjoner genuint ikke dekker ennå, selger til kommersielle eiendoms-, industri- eller porteføljeoperatører som allerede ligner Explores kjøper, og har en kanal eller installert base der en felles pitch har et konkret sted å lande — en eksisterende kundesamtale, ikke en kald liste. Et partnerskap fungerer best når det starter smalt: en delt prospekt eller én levende bygning, som beviser at kombinasjonen er verdt mer enn hvert produkt alene, før noen av sidene forplikter seg til noe større.

Ofte stilte spørsmål

Hva innebærer et FrostLogic-sensorpartnerskap konkret? Et kommersielt co-sell-forhold. Dere fortsetter å selge maskinvaren deres under deres eget merke; Explore leser dataene den produserer, og gjør dem om til prioriterte funn på tvers av en bygning eller portefølje. Vi avtaler territorium, hvordan leads beveger seg mellom oss, og et første bevis før vi snakker om noe større.

Er dette en OEM-embed-avtale, der enheten vår kjører FrostLogics programvare, eller et co-sell-forhold? Co-sell. FrostLogic Explore blir ikke embeddet i firmwaren deres eller solgt under merket deres; det er et eget analyselag som leser sensorens output og foreslås sammen med maskinvaren deres i avtaler der kjøperen trenger begge deler.

Konkurrerer Explore med maskinvaren vår, eller prøver den å erstatte den? Nei. Explore måler ingenting selv; den har ingen egne sensorer å selge. Den leser det som helst allerede rapporterer inn i en bygning, deres inkludert, og gjør de dataene om til beslutninger. Maskinvaren deres forblir målelaget; Explore forblir inferenslaget over.

Hvorfor trenger dere ekte sensorpartnere i stedet for bare å modellere de manglende dataene? Fordi en modell kan utvide et eksisterende signal, ikke finne opp ett som aldri ble målt. En virtuell sensor kan utlede et punkt fra korrelerte målinger som allerede finnes et sted i bygningen, men den kan ikke trylle frem en fysisk størrelse — vannstrøm, vibrasjon, luftkvalitet — som ingen i porteføljen måler i det hele tatt. Det er en reell grense, ikke et forbehold, og det er nøyaktig hullet et maskinvarepartnerskap tetter.

Skriver Explore noen gang kommandoer tilbake til enhetene våre? Nei. Sensortelemetri flyter én retning, enhet til Explore. Det er ingen kommandokanal og ingenting å bygge inn i maskinvaren deres for å støtte det. Explores tilbakeskrivingsevne finnes kun på BMS-styringssiden, børverdier og tidsplaner, er read-only by default også der og slås på bare scope for scope når en bygnings egen operatør velger det.

Hva trenger dere av oss teknisk for å komme i gang? Hvilken protokoll eller API enheten deres allerede rapporterer over, BACnet, Modbus, OPC UA eller deres egen skyplattforms API, pluss en sandbox eller testenhet å validere mot før en felles kunde går live. Vi ber dere ikke om å bygge et nytt grensesnitt for oss; vi leser det dere allerede har.

Hva er et godt første skritt hvis vi er interessert? En delt prospekt eller én levende bygning, ikke en rammeavtale på forhånd. Fortell oss hva dere måler og hvem dere selger til, vi sier rett ut hvor fitet er reelt, og det første bevispunktet er lite med hensikt.

Hvis dere bygger sensorer, la oss snakke dekning

Fortell oss hva maskinvaren deres måler og hvem som kjøper den, så sier vi rett ut om fitet er reelt, og hvordan en første felles avtale ville sett ut. Ingen manifest, ingen anskaffelsespakke. La oss snakke om det.