Due to a ransomware attack, the wiki was reverted to a July 2022 version. . We apologize for the lack of a more recent valid backup.
Child pages
  • 2021-03-04 OIMT Meeting notes




  • Administrative 
  • Review the writeup on multi-point MC restriction/rules (defer)
  • TR-512.17 Foundation - States  
  • Equipment 
  • Papyrus version
  • Control model

Discussion items





5 minAdministrativeKam/Nigel

TR-512.17 Foundation (State) has been created. It 

  • took the version of TR-512.3 Foundation (Identifiers, naming and state) that we worked on in last year as the base,
  • removed the part of Identifiers and naming.
  • accepted most of the comments
  • some comments/notes have been added

Main changes/notes

  • LifecycleState
    • "plan" could be in different stages, e.g, tentative, firm, committed; need discussion. 
    • pending removal → pending withdrawal
    • potential not installed  → potential planned

Keep LifecycleState as a flat Enumeration, not to create substate

Will update the figures to align with the changes in the Enumeration.

It will be posted as oimt2021.MB.001-draft-TR-512.17 for discussion next week.


Nigel noted the off-line discussion on Leo's comments and propsoal

  • May pull properties back to the Equipment class from the grouping classes
  • May refactor the model for practical reason
  • The core model is not intended to be implemented as it is. It is intended as the source of attributes and structure that would then be refactored - lightly or heavily, for implementation. Like TAPI.
  • The core model is for representation of information exchanged across interfaces, not to represent information stored in device. It doesn't dictate the internal model. 
  • CH: Will present the principles next week.
  • LN: In a particular API (e.g., JSON), might prefer to have the equipment type attribute of equipment be an UUID so that to avoid repeating the equipment type information in each equipment instance.
  • CH: Will need to have equipment type library
  • CH: Should revisit the physical model to clear up, in particular the Spec.
  • ND: Not just instance data in the Spec, it includes type and instance
  • LN: The spec model needs detailing, avoid repicating information of other instance.
  • CH: Need to clarify the backbone model, options, decoration, augmentation, ...
  • On the spec model, step back, start from simple, take equipment to rework on

Papyrus tooling version

General tooling information on the IISOMI wiki page: Papyrus Releases

TR-512 v1.4 () core model tooling and profile version: See Table 1

Contorl ModelNigel

Briefing on the ofline discussion 

  • Progression of Control driven by Plan
    • Plan / Committe / Install / Control
  • To keep the control infrastructure independent from the entities that are being controlled
minNext calls


  • Review of writeup on multi-point MC restriction/rules
  • Feedback on TR-512.17
  • Equipment
  • Control model

Action items