IoT Control Input Construction Error

[mike1813]

An IoT Controller (a.k.a. Actuator) has a control input. This is modelled via three system model elements:

• a domain#Controller asset representing the actuator device
• a domain#Data asset representing the control input
• a relationship of type domain#controlsThing from the former to the latter

The control input is also stored persistently on the IoT device, because the input remains valid until next updated. The data is accessed by two separate processes on the IoT device: a service providing network access to provide new input, and the process that interfaces to the actuator hardware on the device.

If a user specifies a domain#Controller asset but not the control input, the input is added as an inferred asset. The construction pattern for this also adds the domain#controlsThing relationship to the IoT device, and the domain#stores relationship from the device.

If a user includes the control input as an asserted domain#Data asset with a domain#controlsThing relationship to the IoT device, then this construction pattern to add the data is not triggered. However, in that case, the domain#stores will also not be constructed, leaving an inconsistent system model in which a the control input is not stored on the IoT device.

To fix this, the construction sequence should be changed so the domain#stores relationship is added separately. The pattern doing this can then match an asserted or inferred Data asset.

[mike1813]

The two test cases used in #123 can be used to verify the fix for this problem:

• Case 2 has an asserted control input to an IoT device, and an asserted 'stores' relationship from the device.
• Case 1 is identical, but without the 'stores' relationship.

This issue causes the results of these two test cases to differ. In Case 1 the 'stores' relationship is not inferred, leading to modelling errors and missed threats. Once the issue is fixed, this relationship will be inferred, so that the two cases are identical, except for the differences in system model properties (name, last validation time, etc)., and the fact that triples encoding the stores relationship are inferred in Case 1 and asserted in Case 2.

[mike1813]

Now fixed on branch 40 as part of the work to address #40 including #109 and (for consistency with that) #123.