Partner-Studio-Leitfaden
Wie Sie Ihr Produkt, Ihre Daten und Ihre Domänenexpertise in ABB Ability™ BuildingPro Suites einbringen
Dieser Leitfaden richtet sich an Start-ups, Technologieanbieter und Lösungspartner, die sich mit — oder auf — BuildingPro Suites (BPS) integrieren möchten. Er beschreibt vier Integrationspfade, von einer leichten Datenanbindung bis hin zu einem vollständig gemeinsam entwickelten nativen Modul, und hilft Ihnen dabei, den richtigen Weg für Ihr Produkt und Geschäftsmodell zu wählen.
1. Warum mit BuildingPro Suites zusammenarbeiten?
BuildingPro Suites ist eine cloud-first Smart-Building-Plattform mit einer mehrschichtigen Architektur:
Pflichtbasis — Konnektivität, Asset-Modellierung, Identität und Governance
Plattform-Toolbox — Dashboards, Regeln, Analysen, APIs und App-Framework
Suiten — vertikale Module wie Energy & Sustainability Intelligence, Occupant Experience und Space & Assets Analytics
Als Partner binden Sie sich an eine bestehende Unternehmensplattform mit über 100 OT-Protokollintegrationen, einem Marketplace, einer globalen ABB-Vertriebsorganisation und einem Hardware-Ökosystem an — statt all das selbst aufzubauen.
Das zentrale architektonische Prinzip: Die Struktur gehört den Suites; Datenpunkte werden darauf abgebildet. BuildingPro Suites enthält das kanonische Asset- und Standortmodell (Gebäude, Etagen, Räume, Anlagen). Welchen Integrationspfad Sie auch wählen, Ihre Daten und Funktionen werden an dieses Modell angebunden.
2. Die vier Integrationspfade auf einen Blick
Es gibt vier Möglichkeiten zur Integration, geordnet nach dem typischen Weg eines Partners:
Die Optionen sind nicht gegenseitig ausschließend — viele Partnerschaften beginnen mit Option A oder B, um schnell Wert zu demonstrieren, und entwickeln sich dann zu C oder D weiter.
A — Eingebettete UI
B — Nur Daten
C — Suites App
D — Vollständiges Modul
Was es ist
Ihre bestehende UI läuft innerhalb von BPS
Ihr System streamt Daten in BPS
Sie entwickeln eine Connector-App auf dem App SDK
Gemeinsam entwickeltes natives BPS-Modul
Wer entwickelt
Partner + BPS (Einbettung)
Partner (Datenexport)
Partner (mit BPS SDK)
BPS-Entwicklungsteam + Fachkompetenz des Partners
Aufwand für den Partner
Tage bis Wochen
Tage bis Wochen
Wochen bis Monate
Monate (laufend)
Benutzererlebnis
Look & Feel des Partners
BPS-nativ (generisch)
BPS-nativ (vorlagenbasiert)
Einheitliche BPS-UX
Analysen & KI
Begrenzt (bleibt in der Partner-UI)
Grundlegend (Rohdaten)
Standard-KPIs & Regeln
Vollständige BPS-Analysen & KI
Marketplace-Eintrag
Optional
Nein
Ja
Ja — wird als BPS-Modul verkauft
Geschäftsmodell
Projekt / OEM
Projektbasiert
App-Lizenzierung
Umsatzbeteiligung
Am besten geeignet für
Reife Partnerprodukte mit starker UI
Schneller Proof of Value, bestehende BMS/GRMS
Wiederholbare, skalierbare Geräte-/Systemintegrationen
Tiefgehende Domänenlösungen (ESG, Gastgewerbe, Netz, …)
3. Option B — Nur-Daten-Integration (MQTT / OPC UA / Events)
Konzept
Der einfachste Weg: Ihr System — zum Beispiel eine GRMS-, BMS- oder IoT-Plattform — veröffentlicht Daten über Standard-Schnittstellen wie MQTT oder OPC UA. BuildingPro Suites konsumiert, normalisiert und speichert die Daten gemäß seinem Asset-Modell. Von dort aus gelten alle Standard-Plattformfunktionen: Dashboards, Alarme, Regeln, Trendanalysen und Berichte.
Es ist keine Entwicklung auf Partnerseite gegen die BPS-APIs erforderlich — nur ein konfigurierte Datenexport aus Ihrem System.
Architektur
So funktioniert es
Struktur zuerst: Die Gebäudestruktur (Standorte, Etagen, Räume, Assets) wird in BuildingPro Suites angelegt — dies ist das kanonische Modell.
Verbinden: Ihr System veröffentlicht in einer MQTT-Topic-Struktur oder stellt einen OPC-UA-Adressraum bereit.
Zuordnen: eingehende Datenpunkte werden BPS-Assets und -Attributen zugeordnet (Mapping-Hinweise aus Ihrer Payload-Struktur beschleunigen dies).
Verwenden: Daten stehen sofort für Dashboards, Alarmierung, Regeln und Suite-Analysen zur Verfügung.
Was Sie bereitstellen / was wir bereitstellen
Datenexport via MQTT oder OPC UA
Ingestion, Normalisierung, Persistenz
Payload-Dokumentation (Topics, Einheiten, Semantik)
Asset-Modellierung und Mapping-Tools
Testumgebung oder Beispieldaten
Dashboards, Alarme, Regeln, Reporting
Wann Sie Option B wählen sollten
Sie möchten den Wert in einem Pilotprojekt innerhalb von Tagen statt Monaten
Ihr System spricht bereits MQTT oder OPC UA
Die Hauptanforderung des Kunden ist Daten-Transparenz — Monitoring, Alarmierung, Berichterstattung
📖 Dokumentation: Geräte an BuildingPro Suites anbinden
4. Option C — Suites App: Daten + Auto-Modell + Auto-KPIs
Konzept
Sie entwickeln eine Suites App (Connector) unter Verwendung des BuildingPro Suites App SDK. Anders als bei Option B liefert Ihre App nicht nur Daten — sie treibt die Plattform aktiv an:
Verbindet sich mit Ihrem System über dessen REST-API oder SDK
Erstellt Assets und Attribute automatisch aus Vorlagen (Continuous Asset Creation)
Stellt KPIs, Zielwerte und Regeln automatisch bereit
Stellt Standard-Dashboards bereit sodass Kunden sofort eine funktionierende Lösung erhalten
Das Ergebnis ist eine wiederholbare, produktisierte Integration: App installieren, Zugangsdaten eingeben, und die komplette Lösung konfiguriert sich selbst. Dies ist der Standardweg zu einem Marketplace-Eintrag.
Architektur
Technischer Rahmen (App SDK)
Apps laufen als Docker-Container innerhalb einer BuildingPro Suites-Umgebung und folgen einem definierten Vertrag:
Sprache: Go (vorgefertigte Client-Bibliotheken verfügbar)
Plattformzugriff: ausschließlich über die BPS REST API und WebSockets (
API_ENDPOINT,API_TOKEN)Persistenz: app-spezifisches Schema in PostgreSQL (
CONNECTION_STRING)App-API: eigene Funktionen, die über eine benutzerdefinierte API bereitgestellt werden, beschrieben in
openapi.yaml(API_SERVER_PORT)Lebenszyklus: Aktivierung → Installation → Initialisierung → Updates/Migration → Deinstallation
Best Practice: Kontinuierliche Asset-Erstellung (CAC) — die App erkennt neue Geräte in Ihrem System und erstellt/aktualisiert/entfernt die entsprechenden BPS-Assets automatisch, einschließlich Dashboard-Vorlagen
Eine Mock-Umgebung ermöglicht Ihnen Entwicklung und Tests ohne vollständige BPS-Installation, und ein App-Template-Repository hilft Ihnen in wenigen Stunden den Einstieg.
Was Sie bereitstellen / was wir bereitstellen
App-Entwicklung (Go, gegen das SDK)
App SDK, Client-Bibliotheken, App-Template, Mock-Umgebung
Asset-Vorlagen, KPI-Definitionen, Dashboard-Vorlagen
Review, Zertifizierung, Marketplace-Eintrag
Wartung und Versionierung der App
Bereitstellungs-Framework, Plattformbetrieb
Wann Sie Option C wählen sollten
Sie möchten ein wiederholbares Produkt, keine Integration pro Projekt
Ihr System hat eine gute API, und Sie haben (oder können beschaffen) Go-Entwicklungskapazität
Sie möchten Marketplace-Sichtbarkeit und eine Installation in Minuten für Kunden
📖 Dokumentation: App SDK · 💻 GitHub: github.com/eliona-smart-building-assistant
5. Option A — Eingebettete Partner-UI
Konzept
Wenn Sie bereits eine ausgereifte, differenzierte Benutzeroberfläche haben, können wir sie direkt in BuildingPro Suites einbetten — der Kunde arbeitet in einer Plattform, und Ihr Produkt erscheint als nativer Bestandteil davon. Es stehen drei Einbettungsmuster zur Verfügung:
iFrame — schnellster Weg; Ihre Web-App wird in einem BPS-Frame angezeigt
Webkomponente — tiefere Integration; Ihre UI-Komponenten werden in BPS-Ansichten gerendert
Reverse Proxy — BPS stellt Ihre UI unter seiner eigenen Domain bereit für ein nahtloses Erlebnis
Optional übergibt BPS Kontext an Ihre UI — z. B. das aktuell ausgewählte Hotel, Zimmer oder Asset — sodass sich Ihre Oberfläche an der richtigen Stelle öffnet („Deep Linking mit Kontext“).
Architektur
Design-Aspekte
Single Sign-on: Token- oder Sitzungsübergabe, damit sich Benutzer nicht zweimal anmelden müssen
Kontextübergabe: URL-Parameter oder
postMessagefür Asset-/Raum-/BenutzerkontextVisuelle Anpassung: optionales „leichtes Visu“-Styling, um Farben und Typografie an BPS anzugleichen
Kombinieren mit Option B: viele Partner betten ihre UI ein als auch streamen Daten in BPS, sodass ihre Informationen auch in bereichsübergreifenden Dashboards und Berichten erscheinen
Wann Sie Option A wählen sollten
Die UI Ihres Produkts ist ein zentraler Differenzierungsfaktor und eine Neuentwicklung ergibt keinen Sinn
Sie müssen in der täglichen Plattform des Kunden präsent sein, ohne tiefgreifende Neuentwicklung
Als Brücke: Behalten Sie heute Ihre UI und migrieren Sie Funktionen im Laufe der Zeit nativ
6. Option D — Gemeinsame Entwicklung eines vollständigen Moduls
Konzept
Die tiefste Partnerschaft: Wir kombinieren Ihre Fachkompetenz (Raumlogik, Workflows, KPIs, operative Prozesse, Compliance-Know-how) mit unserer Plattform und Entwicklungskapazität um ein nativen BuildingPro-Suites-Modul mit:
Einheitliche UX — auf dem BPS-Designsystem aufgebaut, nicht vom Kern der Suites zu unterscheiden
Analysen & KI — voller Zugriff auf die ML/AI-Funktionen der Plattform
Standard-KPIs — produktisierte Kennzahlen, Zielwerte und Benchmarks für die Domäne
Das Modul wird zu einer verkäuflichen Einheit innerhalb von BuildingPro Suites — verkauft über ABBs globale Vertriebsorganisation und das Partnernetzwerk, mit einer Umsatzbeteiligung für Sie.
Architektur
Der Co-Entwicklungsprozess
1 — Ideenfindung & Scoping
Gemeinsame Definition des Anwendungsfalls, Marktproblem, Zielkunden, MVP vs. Erweiterungen, grober Business Case
Modulvision, Umfang, grobe Roadmap
2 — Produkt & Design
Gemeinsame Workshops: KPIs, Datenmodelle, Workflows, User Journeys, UX-Mockups
Produktanforderungen, UX-Konzepte, klarer MVP-Umfang
3 — Entwicklung & Integration
Implementierung durch das BPS-Entwicklungsteam, regelmäßige Reviews und Demos, fachliche Validierung durch den Partner
Funktionsfähiges Modul, von beiden Seiten abgenommen
4 — Verpackung & Preisgestaltung
Lizenzierungs- und Preismodell, Marketplace-Positionierung, Produktbeschreibungen, Demo-Szenarien
Verkäufliches, gelistetes Modul
5 — Markteinführung & Vertrieb
Gemeinsame Vertriebsstrategie, Enablement für ABB-Vertrieb und Partner, Aktivierung des Partnernetzwerks
Umsatz- und Markt-Feedback-Loop
Rollen
Sie (Partner) können eine oder mehrere Rollen übernehmen: Domänenverantwortliche/r / Fachexpertin/Fachexperte, Product Owner für das Modul, Co-Designer (UX), Qualitäts- und Validierungspartner, Go-to-Market- und Vertriebspartner, Geräte-/Hardware-Domänenexpertin/-experte.
Wir (ABB / BuildingPro) besitzen die Plattform und Architektur und stellen Entwicklung (Backend, Frontend, DevOps, QA, KI/ML), das UX/UI-Designsystem, Marketplace-Verpackung und Bereitstellung, globalen Vertrieb und Distribution sowie Betrieb, Support und Skalierung bereit.
Geschäftsmodell & IP
Umsatzbeteiligung: Sie erhalten einen Anteil an jedem verkauften Modul. Der Anteil spiegelt Ihren Beitrag zum Produkt (IP, Fachwissen, Produktdefinition), Ihren Beitrag zu Vertrieb und Marketing sowie Ihre langfristige Rolle bei Wartung und Weiterentwicklung wider. Das konkrete Modell wird individuell pro Partner und Modul vereinbart.
IP & Eigentum: Das Modul ist Teil von BuildingPro Suites; ABB betreibt, verkauft und wartet es. Sie bringen Domänen-IP und Fachwissen ein. Details zur IP-Nutzung, Lizenzierung und zu Rechten werden vertraglich geregelt.
Was wir erwarten / was Sie erwarten können
Tiefes Domänenwissen
Zugang zur BPS-Plattform und Architektur
Aktiver Produktbeitrag — nicht nur eine Idee
Professionelle Produkt- und Softwareentwicklung
Verfügbarkeit für Reviews, Tests und Feedback
UX/UI, QA, DevOps und Betrieb
Marktzugang oder fundierte Marktkenntnisse
Marktplatz und globale Vertriebsreichweite
Langfristiges Interesse am Erfolg des Moduls
Skalierung in Unternehmensumgebungen
7. Welche Option ist die richtige für Sie?
Faustregeln:
Wert in einem Pilotprojekt nächsten Monat nachweisen → Option B
Ein wiederholbares Integrationsprodukt ausliefern → Option C
Ihre UI ist das Produkt → Option A (plus B für domänenübergreifende Daten)
Bauen Sie ein gemeinsames Geschäft auf Basis geteilter Umsätze auf → Option D
Und denken Sie daran: Das sind Phasen, keine Silos. Ein typischer Partnerweg ist B → C → D oder A → D.
8. Erste Schritte
Beschreiben Sie Ihren Anwendungsfall — eine kurze Beschreibung der Modul- oder Integrationsidee und des Kundenproblems, das sie löst
Beschreiben Sie Ihr Fachwissen in der Domäne — was Sie einbringen, was sonst niemand hat
Gemeinsamer Scoping-Workshop — wir ordnen Ihre Idee gemeinsam der passenden Option (A–D) zu
Legen Sie das Setup fest — technischer Weg, Rollen und kommerzieller Rahmen
Starten — Pilotprojekt (A/B), App-Entwicklung (C) oder Konzept- und Designphase (D)
Kurz gesagt: Sie bringen die Domänenexpertise, die Anwendungsfälle und den Markt mit — wir bringen die Plattform, die Skalierung und die Vertriebsmaschine mit. Gemeinsam bauen wir ein Produkt, das beiden Seiten beim Wachsen hilft.
📩 Kontaktieren Sie das BuildingPro Suites-Partnerteam, um einen Scoping-Workshop zu vereinbaren.
Ressourcen
Dokumentation: Willkommen zum ABB Ability™ BuildingPro Suites-Leitfaden!
App-SDK: App-SDK-Dokumentation
GitHub (SDK, App-Vorlage, Mock, Client-Bibliotheken): github.com/eliona-smart-building-assistant
API-Referenz: api.eliona.io
Zuletzt aktualisiert
War das hilfreich?