CI Status and KPI propgration

I am trying to implement custom HIs and KPIs , So I created a custom CI type called Vehicle and it's subtypes Engine and TIres.  I establised relationship between Vehicle and Engine, Tires as containment

Then I created custom CI , four tires , engine and a car in IT universe model and set up relationships. Now I created following Health Indicators and KPIs

Tire :  

 HI : TirePressure , KPI: TirePerformance ( calculated based on TirePressure) 

Engine:

HI : EngineHeat  , KPI : EnginePerformance ( calculated based on EnginePressure)

Car:

KPI : CarPerformance ( Calculated based on HIs and Child KPIs , and choose Legacy System as HI ) 

All of them have worst status rule where possible

 

Using sendEvent.sh I generated  events that changed health indicators of Tires and Engine, they went into Red and Yellow statuses in Top View.  But my car stays in green. How do I propogate that status up to the parent CI. Please help I am learning and trying out a few things. Attached has the topview of a pattern view that I created for this.

 

Parents
  • Verified Answer

    1. While RTSM doesn't care about the names of CITs, the CIT hierachy you created (Engine and Tires are subtypes of Vehicle) is logically incorrect. Subtype is a more specific implementation of its parent CIT, e.g. Computer CIT is a more specific implementation of its parent (Node) CIT. Windows CIT is a more specific implementation of its parent (Computer) CIT. Subtype inherits properties of its parent CIT (after all Windows is a Computer anyway), but usually add some more specific properties that would allow to differentiate it from its parent. Needless to say that by no means Engine or Tires can be a more specific implementation of Vehicle, as neither Engine nor Tires are vehicles. Sedan, SUV, Truck could be examples of correct subtypes for the Vehicle CIT.

    2. Please read the Effective Modeling for BSM Best Practices guide that is part of BSM product documentation. Specifically pay attention to Appendix A - The Impact Layer. The keyword for understanding why what you configured doesn't work would be "triplet".

    3. I strongly discourage you from learning via creating custom CITs. First of all you should always use OOB CIT model whenever possible. Creating custom CITs is definitly possible, but should be only considered as the last resort as it introduces additional compexity (including future product upgrades, integrations with other RTSM/UCMDB, impact level definition etc.). Anyway this would be more appropriate for those with advanced level of product knowledge rather than beginners.

Reply
  • Verified Answer

    1. While RTSM doesn't care about the names of CITs, the CIT hierachy you created (Engine and Tires are subtypes of Vehicle) is logically incorrect. Subtype is a more specific implementation of its parent CIT, e.g. Computer CIT is a more specific implementation of its parent (Node) CIT. Windows CIT is a more specific implementation of its parent (Computer) CIT. Subtype inherits properties of its parent CIT (after all Windows is a Computer anyway), but usually add some more specific properties that would allow to differentiate it from its parent. Needless to say that by no means Engine or Tires can be a more specific implementation of Vehicle, as neither Engine nor Tires are vehicles. Sedan, SUV, Truck could be examples of correct subtypes for the Vehicle CIT.

    2. Please read the Effective Modeling for BSM Best Practices guide that is part of BSM product documentation. Specifically pay attention to Appendix A - The Impact Layer. The keyword for understanding why what you configured doesn't work would be "triplet".

    3. I strongly discourage you from learning via creating custom CITs. First of all you should always use OOB CIT model whenever possible. Creating custom CITs is definitly possible, but should be only considered as the last resort as it introduces additional compexity (including future product upgrades, integrations with other RTSM/UCMDB, impact level definition etc.). Anyway this would be more appropriate for those with advanced level of product knowledge rather than beginners.

Children