I have several doubts regarding the DataAccessError of AccessResult to be used in Write Response Failure for controls.
In Table 87, only four values are provided ("temporarily-unavailable", "hardware-fault", "object-access-denied" and "object-undefined").
1) "Object-undefined" should be used when "Control does not exist in this security view". Does this refer to perform an action not belonging to the control model, this is, for example writing a SBOw when control model is not SBOes (in DOns, SBOns or DOes)?
2) "Temporarily-unavailable" should be used when "Control is already selected or being operated". It seems obvious that it has to be used when AddCause is "Command-already-in-execution", "Object-already-selected" and "Locked-by-other-client"? Must it be used in any other AddCauses?
3) Only those four values should be used?
3.1) If no, associated to AddCause "Inconsistent-parameters", "object-value-invalid" could/should be used?
3.2) If yes, "object-access-denied" should be used for the rest of the AddCauses, obviously considering that no hardware faults occur.
Proposal
I would suggest adding a table to the standard mapping "AddCause" with the corresponding DataAccessError of AccessResult if possible to clarify all the possible situations.
Test Procedures do not always (I would say never) clarify what DataAccessError of AccessResult must be used and it depends on the person from the Certification Lab if it is checked and passed or not. I also suggest adding the expected DataAccessError of AccessResult in all test cases in the Test Procedures to assure equanimity in tests and improve interoperability.
Discussion
Created
Status
ballot date expired.
Tissue resolution applies to Ed2.1.
05 Nov 18
In Force (green)
The issue is the order of checking for access privilege. If security enforcement point is on the MMS Service (I believe this will be typical) and the check fails here, then the control state machine is never entered and NO AddCause would be possible.
Therefore, for an object-non-existent, an AddCause will never be possible. In AMD1, this will be removed from the table.
In regards to a security privilege issue on an existing control object, if the security enforcement point is at the MMS/Application boundary, then the Control state machine will not be entered. If the security enforcement is at the Application level (e.g. the MMS V-Put succeeds), then an AddCause is possible. This is an implementation choice and why interpreting the MMS Response is the key in this case. In this situation AddCause being returned is optional.
Final Proposal: Remove Object-Undefined from Table.
01 Jun 18
Ballot Period
made peter's comment public
20 Feb 18
Triage
The definition of value TEMPORARILY-UNAVAILABLE is missleading and not aligned with ISO 9506-1, clause 14.4.3 which defines:
"The requested variable is temporarily unavailable for the requested access.
Example: A VMD may disallow an attempt to write to the set-point of a control loop that has been placed in manual mode."
I would recommend to change the definition to "Control is already selected, being operated or the PerformTest failed".