Backend Architecture & Packages

Technical design of the environment used in the App Builder Workshop. The backend is split into one Catalog package per vertical. Participants get the package of their chosen exercise from the DataMiner Catalog; we provide and maintain these packages so the hands-on sessions run smoothly. How packages reach participants is described in Participant Enablement.

Note

Element names, fields, thresholds, and scenario values in the backend pages are a proposed design and still need to be confirmed.

Design Principles

#	Principle	Consequence
1	One package per vertical	Each exercise is deployed independently from the Catalog. Packages can coexist on the same DataMiner System.
2	A vertical-specific data model	Each package deploys its own DOM module with definitions in the vertical's own language (e.g. Event in broadcast, Mission in space).
3	All metadata lives in DOM	Customer, criticality, impact, owners, locations, limits, and schedules are DOM fields. No service or element properties.
4	DOM links to DataMiner by ID	Each DOM object stores the ID of its linked DataMiner service or element.
5	Only real-time data comes from elements	Parameter values, alarms, and trends come from the elements (and the service alarm state aggregated from them).
6	AI is not part of the backend	Summaries, recommendations, and copilot answers are created by agents in the Specialized Agents Workshop at runtime and never stored.
7	Every problem must be answerable	Each problem has the data it needs and a seeded scenario that produces a clear answer.

Packages

Package (Catalog item)	DOM module	Top-level object	Asset object	Details
Empower – Telco	`empower_telco`	Network Service	Network Element	Telco Package
Empower – Satellite & Space	`empower_satellite`	Mission	Ground Segment Asset	Satellite & Space Package
Empower – Media & Broadcast	`empower_media`	Event	Signal Chain Device	Media & Broadcast Package
Empower – Infrastructure	`empower_infrastructure`	Infrastructure System	Critical Asset	Infrastructure Package
Empower – Government & Public Safety	`empower_government`	Operational Network	Field Asset	Government & Public Safety Package

Vertical Terminology

The same underlying concepts get a vertical-specific name in each data model.

Concept	Telco	Satellite & Space	Media & Broadcast	Infrastructure	Government & Public Safety
Top-level object ↔ DataMiner service	Network Service	Mission	Event	Infrastructure System	Operational Network
Asset ↔ DataMiner element	Network Element	Ground Segment Asset	Signal Chain Device	Critical Asset	Field Asset
Location	PoP / Data Center	Ground Station	Facility	Site	Location (own definition)
Customer	Customer Segment	Customer	Rights Holder	Operator	Agency
Impact	Subscribers	Customers Served	Expected Audience	Users Served	Population Covered
Criticality	SLA Tier	Mission Priority	Event Tier	Criticality	Mission Criticality
Owner / team	Service Owner / NOC	Mission Manager / Operations Center	Event Producer / MCR Team	System Owner / Control Room	Network Owner / Command Center
Schedule	–	Contact Window (own definition)	Event start and end	–	–

Architecture

flowchart LR
    CAT[(DataMiner Catalog)] -->|deploy| PKG[Vertical package]
    subgraph DMS[DataMiner System]
        PKG --> DOM[DOM module<br/>vertical data model]
        PKG --> SVC[3 DataMiner services]
        PKG --> EL[9 elements]
        PKG --> SCR[Scenario scripts]
        DOM -. service ID .-> SVC
        DOM -. element ID .-> EL
        SVC --> EL
        SCR -->|real-time values| EL
    end
    DOM -->|metadata| APP[Participant app]
    EL -->|parameters · alarms · trends| APP
    SVC -->|alarm state| APP

Package Contents

Every vertical package contains the same kinds of components:

Component	Purpose
Install script	Creates the DOM module, elements, services, and view, then seeds the DOM instances with the IDs of the created objects
DOM module	The vertical data model (definitions, sections, fields)
DOM seed data	3 top-level objects, 9 assets, plus schedules/locations where the vertical needs them
Elements (9)	Real-time data sources, 3 per top-level object
DataMiner services (3)	Group the 3 elements of each top-level object; provide the aggregated alarm state
Alarm and trend templates	Thresholds and trending for the parameters the problems need
Scenario scripts	`Baseline`, `StartScenario`, and `Reset` for this vertical
View	`Empower/<Vertical>`

Installation Flow

sequenceDiagram
    participant C as Catalog
    participant I as Install script
    participant D as DataMiner
    C->>I: Deploy package
    I->>D: Create or update DOM module (idempotent)
    I->>D: Create 9 elements, assign alarm and trend templates
    I->>D: Create 3 services and the view
    I->>D: Create DOM instances with service and element IDs
    I->>D: Schedule the Baseline script

The install script is idempotent: redeploying the package updates the model and seed data without creating duplicates.

Linking DOM to DataMiner

DOM object	Link field	Points to
Top-level object	`DataMiner Service`	The DataMiner service that groups its elements
Asset	`DataMiner Element`	The element that provides its real-time data
Asset	Parent link (DOM)	Its top-level object

The install script creates the services and elements first and then writes their IDs into the DOM instances, so the link is always correct for the system the package is deployed on.

Important

Participants must be able to join DOM data with real-time data in App Builder. The ID stored in DOM must therefore also be available as a column in the element, service, and alarm data sources. See Open Decisions.

Real-Time Data

Data	Source	Access in App Builder (verify)
Metadata and schedules	DOM module of the vertical	GQI – DOM instances
Parameter values	Elements	GQI – parameters / parameter tables
Trend data	Elements (trended parameters, ≥ 24 h)	Trend (line chart) component
Active alarms (severity, age)	Elements	GQI – alarms
Alarm history	Elements	GQI – alarms (history)
Alarm state	DataMiner service (aggregated from its elements)	GQI – services

Scenario Engine

Each package has its own three scripts, so verticals can run independently on the same system.

Script	Trigger	Responsibility
`Empower_<Vertical>_Baseline`	Scheduler, every 60 s	Pushes normal values with noise to the 9 elements and applies the 24 h trend drifts. Does not touch DOM.
`Empower_<Vertical>_StartScenario`	Manually, 30 min before the session (T0)	Pushes the incident values that raise the seeded alarms, and sets DOM schedule times (events, contact windows) relative to T0
`Empower_<Vertical>_Reset`	Manually, between sessions	Returns elements to baseline and clears incidents. Optional full reset restarts the trend drifts.

Timeline (relative to T0):

Time	Event	Why
T0 − 24 h	Trend drifts start (package install or full reset)	Trend-based problems need 24 h of history
T0 − 12 h	One short, self-clearing alarm per top-level object	Gives each one a last incident in the alarm history
T0	Seeded incidents start; schedules are set	Alarms are ~30 min old at session start
T0 + 25 min	Delayed incidents (where a vertical needs them)	Crosses thresholds during the session
T0 + 30 min	Session starts

Important

Deploy each package at least 24 hours before the first session.
Date/time values are written as local wall-clock time without a UTC offset.

Data Availability Matrix

Check that every problem has the data it needs. DOM = vertical data model · SS = service alarm state · AA = active alarms (incl. age) · AH = alarm history · PV = parameter values · TR = trend data.

Package	Problem	DOM	SS	AA	AH	PV	TR
Telco	Priority Dashboard	✔	✔	✔
Telco	Customer Impact View	✔	✔	✔
Telco	Capacity Risk Workspace	✔		✔		✔	✔
Satellite & Space	Mission Readiness Dashboard	✔	✔	✔
Satellite & Space	Ground Segment Workspace	✔		✔		✔	✔
Satellite & Space	Customer Service Assurance View	✔	✔	✔		✔
Media & Broadcast	Event Operations Center	✔	✔	✔
Media & Broadcast	Executive Service Overview	✔	✔	✔
Media & Broadcast	Incident Workspace	✔		✔	✔	✔
Infrastructure	Operations Control Center	✔	✔	✔
Infrastructure	Critical Asset Dashboard	✔		✔		✔	✔
Infrastructure	Regional Operations View	✔		✔		✔
Government	Incident Coordination Workspace	✔		✔
Government	Command Center Dashboard	✔	✔	✔
Government	Risk Prioritization View	✔		✔

Source Repository (proposed)

One solution builds all five packages, sharing common code.

Empower.sln
├── Empower.Common/                      shared code: DataAPI client, DOM helpers, scenario engine
├── Empower.Telco/
│   ├── Empower.Telco.Package/           package project → Catalog item "Empower – Telco"
│   ├── Empower.Telco.Install/           install script (DOM, elements, services, seed data)
│   └── Empower.Telco.Scenario/          Baseline, StartScenario, Reset
├── Empower.SatelliteSpace/              same structure
├── Empower.MediaBroadcast/              same structure
├── Empower.Infrastructure/              same structure
└── Empower.GovernmentPublicSafety/      same structure

The pipeline builds each package project and publishes it to the Catalog as a private item for the organization.

Naming Convention

Object	Pattern	Example
Catalog item	`Empower – <Vertical>`	`Empower – Telco`
DOM module	`empower_<vertical>`	`empower_telco`
View	`Empower/<Vertical>`	`Empower/Telco`
Service	Name of the top-level object	`Brussels 5G Core`
Element	`<PREFIX>-<OBJECT>-<ASSET>`	`TEL-BRU5G-UPF`
Script	`Empower_<Vertical>_<Action>`	`Empower_Telco_StartScenario`

Out of Scope for the Backend

Item	Where it lives instead
AI summaries, recommended actions, copilot answers	Agents in the Specialized Agents Workshop (runtime only)
Health or risk scores	The participant's app logic
Tickets	Not included – see Open Decisions
Service and element properties	Replaced by the vertical DOM model

Open Decisions

#	Topic	Options
1	Which ID links DOM to DataMiner	DataMiner identifies elements and services by `DMA ID/element ID` and `DMA ID/service ID`. Confirm which GUID is meant, and that the same key is available as a column in the GQI element, service, and alarm data sources so participants can join. DOM also offers a native `ElementFieldDescriptor` (DataMiner 10.2+) for element links.
2	Tickets	(a) Leave them out – alarms and alarm history cover the problems (current design) · (b) Add a Ticket definition to the vertical DOM model
3	DataAPI	Verify availability on the target system and that alarm and trend templates can be assigned to the generated protocols. Alternative: simulated connectors in the package
4	Shared or dedicated systems	If several participants share one system, the vertical scenario is shared too. Decide whether each participant gets their own system or facilitators run `StartScenario` once per vertical
5	Multi-day trainings	Trend drifts plateau after 24 h. Run a full reset ≥ 24 h before each training day, or make the drift window configurable

Readiness Checklist

Per deployed package:

[ ] Package deployed from the Catalog ≥ 24 h before the session
[ ] DOM module exists with all definitions and seed instances
[ ] Every DOM instance links to an existing service or element
[ ] 9 elements and 3 services exist, alarm and trend templates assigned
[ ] Baseline is scheduled and has been running for ≥ 24 h
[ ] Every top-level object has at least one cleared alarm in its history
[ ] StartScenario triggered 30 min before the session; DOM schedules show upcoming times
[ ] DOM and real-time data can be joined in App Builder
[ ] For each of the 3 problems, the seeded answer is visible in the data
[ ] Reset restores the baseline between sessions

Table of Contents

Backend Architecture & Packages

Note

Design Principles

Packages

Vertical Terminology

Architecture

Package Contents

Installation Flow

Linking DOM to DataMiner

Important

Real-Time Data

Scenario Engine

Important

Data Availability Matrix

Source Repository (proposed)

Naming Convention

Out of Scope for the Backend

Open Decisions

Readiness Checklist