The MachineryItemStateMachine is constructed based on the state of the Device (as represented by the LADSDeviceStateMachineType), the states of the FunctionalUnits (as represented by the FunctionalUnitStateMachineType), and the DeviceHealth status.

Table 148 illustrates this mapping. The first column represents the state of the MachineryItemState, while the subsequent columns represent the states of the other state machines. Given that a device can have multiple functional units, their states are aggregated. The rules for this aggregation are also provided in the table.

This mapping ensures that the MachineryItemState accurately reflects the overall state of the device, considering the states of its individual components and their health status. It provides a comprehensive view of the device's operational status, which is crucial for effective device management and operation.

Table 148 – Recommendation for building the MachineryItemState

MachineryItemState	LADSDeviceStateMachineType	FunctionalUnitStateMachineType	DeviceHealth
Executing	“Operate”	One or more in “Running”	Not in“FAILURE”
NotAvailable	“Sleep” OR “Shutdown” OR “Initialization”	StatusCode:Bad_StateNotActive	Not in“FAILURE”
NotExecuting	“Operate”	Not in “Running”	Not in“FAILURE”
OutOfService	StatusCode:Bad_StateNotActive	“Held” OR “Aborted”	“FAILURE”

The aggregation rules for Held and Aborted are vendor specific.

The MachineryOperationMode operates independently of the MachineryItemStateMachine. This means that the operational mode of the device, as represented by MachineryOperationMode, does not directly influence and is not influenced by the state of the machinery item, as represented by MachineryItemStateMachine.

The StatusCode of the FunctionalUnitStateMachineType current state should be set to Bad_StateNotActive if the LADSDeviceStateMachineType is in the "Sleep" state. This ensures that the state of the functional unit accurately reflects the operational status of the overall device.

The DeviceHealth of the LADS Device should be determined by aggregating the DeviceHealth of its components. The specific rules for this aggregation are vendor specific and can vary based on the implementation. For instance, one possible rule could be that if one or more of the components have a state other than "NORMAL", the device is also considered to be in the corresponding state. This approach ensures that the overall health status of the device accurately reflects the health status of its individual components. However, it is important to note that this aggregation approach may have a potential drawback. It could indicate an error or issue with the device even if some components that are currently in a non-"NORMAL" state are not in use or needed.