cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - You can subscribe to a forum, label or individual post and receive email notifications when someone posts a new topic or reply. Learn more! X

Modelling variable components / quantities

rclarke
6-Contributor

Modelling variable components / quantities

Have a modelling best practices question - have a case where we need to manage/monitor devices within a process mfg setting that follow a standard thing template / thing shape hierarchy. The product family itself breaks down to 3 main product types. There is one additional aspect to consider - any specific device can have between 1-12 separate 'components' installed. Each device 'component' has it's own set of properties, and we need to store these component-specific property values and also maintain history of all component property values for all devices.

This to me seems a typical use case for 'componentization' - so we model each component as separate Things with their own template/shape, then relate these component things to their parent device thing.

So first question - is my above conclusion correct?

Second question - how best to relate the component things to their parent device? A few ideas spring to mind:

  • Define an infotable property in the device thing template/shape – this infotable stores the ‘thing names’ for the related components
  • Store relationship between device / components in TWX datatables
  • etc

What I'd like to get to is a situation where we have scripted services written generically for managing component-specific properties on the devices that can be used via REST API, easily used in mashups etc. For example, a service that can take in a device id, a component id, and retrieve property history for that specific component.

Be interested in understanding past experiences.

Thanks in advance,

Roy

2 REPLIES 2
PaiChung
22-Sapphire I
(To:rclarke)

Since you are interested in tracking information on a component level, I would similar to you model the components as Templates and represent them as Things.

The easiest way to then hierarchically relate the components to the Main Asset would be a Network. Probably the most straightforward way to easily do parent/child/sibling type queries.

rclarke
6-Contributor
(To:PaiChung)

Many thanks for the input Pai - much appreciated. I agree a Network would seem the easiest way - I will suggest this approach.

Roy

Top Tags