For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

  1. Struktur zuerst: Die Gebäudestruktur (Standorte, Etagen, Räume, Assets) wird in BuildingPro Suites angelegt — dies ist das kanonische Modell.

  2. Verbinden: Ihr System veröffentlicht in einer MQTT-Topic-Struktur oder stellt einen OPC-UA-Adressraum bereit.

  3. Zuordnen: eingehende Datenpunkte werden BPS-Assets und -Attributen zugeordnet (Mapping-Hinweise aus Ihrer Payload-Struktur beschleunigen dies).

  4. Verwenden: Daten stehen sofort für Dashboards, Alarmierung, Regeln und Suite-Analysen zur Verfügung.

Was Sie bereitstellen / was wir bereitstellen

Partner stellt bereit
BuildingPro stellt bereit

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

Partner stellt bereit
BuildingPro stellt bereit

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 postMessage für Asset-/Raum-/Benutzerkontext

  • Visuelle 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

Phase
Wesentliche Aktivitäten
Ergebnis

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

Wir erwarten von Partnern
Partner können von uns erwarten

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

  1. Beschreiben Sie Ihren Anwendungsfall — eine kurze Beschreibung der Modul- oder Integrationsidee und des Kundenproblems, das sie löst

  2. Beschreiben Sie Ihr Fachwissen in der Domäne — was Sie einbringen, was sonst niemand hat

  3. Gemeinsamer Scoping-Workshop — wir ordnen Ihre Idee gemeinsam der passenden Option (A–D) zu

  4. Legen Sie das Setup fest — technischer Weg, Rollen und kommerzieller Rahmen

  5. 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

Zuletzt aktualisiert

War das hilfreich?