Service Inventory

Service Inventory in tSM is the runtime master model for service instances and their evolving configuration in time. It is built on the generic Inventory capability and specialized for service runtime behavior.

In practice:

• EntityInstance is service identity,
• EntityInstanceConfiguration is service runtime state,
• EntityInstanceConfigurationRelationship is explicit service-to-service runtime link,
• EntityInstanceConfigurationStatus controls service operational lifecycle values.

1. Main Concepts in tSM

Concept	Meaning in Service Inventory	Typical Owner
Service Instance (EntityInstance)	Stable runtime identity of one service in operations.	Operations / OSS
Service Configuration (EntityInstanceConfiguration)	Versioned state of service parameters at a specific point in lifecycle.	Operations / provisioning
Service Runtime Relationship (EntityInstanceConfigurationRelationship)	Explicit runtime link between service instances/configurations.	Service architect / OSS
active state (CURRENT, PENDING, HISTORY, DRAFT)	Timeline position of configuration.	Operations governance
status (code table)	Business/operational lifecycle meaning (ACTIVE, SUSPENDED, ...).	Business + operations

2. How Generic Inventory Models Service Inventory

2.1 Structure

1. Create service EntityInstance (type = SERVICE).
2. Create one CURRENT service configuration.
3. Add child service configurations using parentEntityInstanceId as needed.
4. Add explicit cross-links with EntityInstanceConfigurationRelationship when relation is not pure tree.
5. Use status table and validity windows for governance.

2.2 Behavior

• catalog specification IDs remain mandatory anchors at runtime,
• timeline and lifecycle dimensions stay separated (active vs status),
• pending changes can be prepared and promoted later,
• history is retained for traceability and audit.

2.3 Tree and Relationship Handling

• tree links are parent-based for efficient decomposition view,
• explicit relationship links keep semantic dependencies traceable,
• both can coexist for one runtime object set.

3. CFS, RFS, and Resource Runtime Mapping

The runtime pattern remains aligned with service design:

• CFS instance is the customer-facing operational object,
• RFS instances are supporting technical service objects,
• resources are linked directly or through RFS according to design and integration pattern.

4. Consistent Example: Business Internet Runtime

4.1 Example Service Runtime Set

Runtime object	Type	Role
X INTERNET SERVICE	SERVICE	Top-level CFS instance
ACCESS OPTIC FTTS	SERVICE	Access RFS instance
TRANSPORT SERVICE	SERVICE	Transport RFS instance
PUBLIC IP SERVICE	SERVICE	Optional VAS instance

4.2 Example Runtime States

Object	active	status	Meaning
X INTERNET SERVICE	CURRENT	ACTIVE	running service
SLA SERVICE	PENDING	ACTIVE	planned to be activated
old transport config	HISTORY	TERMINATED	superseded state

5. Recommended Modeling Workflow in tSM

1. Always create inventory from valid catalog specifications.
2. Keep one current configuration per instance.
3. Use pending for future-dated changes and controlled activation.
4. Use explicit relationship entity only for non-tree links.
5. Keep status table consistent with operational process semantics.

6. TM Forum Alignment (Short Mapping)

tSM	TM Forum Pattern
Service EntityInstance + configuration	Service (TMF638)
Runtime service link	ServiceRelationship (TMF638)
Product/runtime relation context	Product and ProductRelationship (TMF637)
Resource realization context	Resource and ResourceRelationship (TMF639)

Detailed payload-level mapping and operation semantics are covered in Service Inventory Blueprint.