View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0007471 | Part 81: UAFX Connecting Devices and Information Model | Spec | public | 2021-12-14 19:48 | 2022-05-30 22:38 |
Reporter | Greg Majcher | Assigned To | Georg Biehler | ||
Priority | high | Severity | major | Reproducibility | have not tried |
Status | closed | Resolution | fixed | ||
Target Version | 1.00.00 RC3 | Fixed in Version | 1.00.00 RC3 | ||
Summary | 0007471: ACs need to report the ability to require "bundled" commands in the EstablishConnections method | ||||
Description | The EstablishConnections method allows a Connection Manager to send commands one at a time or all together (bundled). Some ACs may only support receiving the commands bundled. CMs need to know which mechanism is required by the AC to interoperate. The recommended solution is to add a capability to the AutomationComponentCapabilitiesType indicating how it processes these commands. | ||||
Additional Information | For more details consult the PowerPoint and recording from the 12/14/21 CD/IM workgroup meeting. | ||||
Tags | No tags attached. | ||||
|
"Bundled vs. Unbundled" commands were discussed in order to distinguish which commands were likely to be sent alone. This does not mean that unbundled commands are required to be sent alone. It is a recognition that certain operations may need to be done outside of the connection establishment process. A ConnectionManager would typically use all commands within one call, if a breakup in several calls is not needed; e.g. when only a small amount of config data is used. Some commands (the unbundled ones) would need to be sent in specific use cases as needed by the AC. Examples include: |
|
The bundled commands would include: CreateConnectionEndpointCmd, EstablishControlCmd, SetConfigureDataCmd, ReassignControlCmd, SetCommunicationConfigurationCmd. In an AC that requires bundled commands, it would be recommended that all commands be bundled, but this AC would still be able to handle the VerifyAsset, VerifyFunctionlEntity, ReserveCommunicationIds outside of a bundle. The status of EnableCommunication would still need to be discussed. |
|
General comment: A single call will be easier to implement than the support of multiple calls on a target device, e.g. in a single call, the sequence of commands is implemented by the target device, whereas if multiple calls are issued by a CM, the target device must verify the correct sequence. Also supporting multiple calls may require storing state information between calls. I recognize that its less implementation and test effort to support "only" single calls. Yet, the slideset states: "Devices (including controller) that do not require multiple calls do not need to support multiple calls" It is not the device that requires multiple calls, it is the workflow(s) that its being used in, that may require multiple calls. If the support of multiple calls is optional, such devices will not be able to be used in certain workflows. The question for me is: Does the reduction of implementation and test effort by omitting support for multiple calls, warrant the limitation of use-cases/workflows such devices can be used in and does it warrant the additional system complexity (engineering tool and/or CM being aware of the capability)? Some examples of scenarios to consider for devices that only support a single call: 1) If ReserveCommunicationIds is contained in such a single call, the call must theoretically be rejected with error, because there will be no subsequent calls that use the reserved ids in SetCommunicationConfiguration. If, as indicated in Pauls comment, only certain commands are contained in a bundle, and remaining commands would still be processed outside of a bundle, then I see no significant reduction in implementation effort on the device side, but still increased system complexity. My proposal: Devices shall support both single and multiple commands, which will enable them to be used in all workflows without introducing additional dependencies and complexity (and increased effort on the implementation side) |
|
In 2022-02-08 call it was noted (as discussed before) that the command sequence diagram should be annotated (somehow) to indicate that the unbundled verify and reserve commands can be sent in any order. Also the Reserve command should be moved higher in the sequence (before the create endpoint, etc), but that may have been done by Georg already |
|
Integrated in specification |
|
Review all changes in multiple calls, agreed to changes and closed issue |
Date Modified | Username | Field | Change |
---|---|---|---|
2021-12-14 19:48 | Greg Majcher | New Issue | |
2021-12-18 15:55 | Greg Majcher | Note Added: 0015576 | |
2021-12-20 14:50 | Paul Hunkar | Note Added: 0015590 | |
2021-12-20 21:32 | Jim Luth | Category | Documentation Errata => Spec |
2022-01-07 13:15 | Paul Hunkar | Note Edited: 0015590 | |
2022-01-10 20:34 | Paul Hunkar | Summary | ACs need to report the ability to support "unbundled" commands in the EstablishConnections method => ACs need to report the ability to require "bundled" commands in the EstablishConnections method |
2022-01-11 13:36 | David Puffer | Note Added: 0015690 | |
2022-02-09 17:30 | Brian Batke | Note Added: 0015961 | |
2022-02-11 13:17 | Paul Hunkar | Assigned To | => Georg Biehler |
2022-02-11 13:17 | Paul Hunkar | Status | new => assigned |
2022-02-24 09:52 | Georg Biehler | Status | assigned => resolved |
2022-02-24 09:52 | Georg Biehler | Resolution | open => fixed |
2022-02-24 09:52 | Georg Biehler | Fixed in Version | => 1.00.00 Release |
2022-02-24 09:52 | Georg Biehler | Note Added: 0016085 | |
2022-04-05 14:23 | Paul Hunkar | Status | resolved => closed |
2022-04-05 14:23 | Paul Hunkar | Note Added: 0016521 | |
2022-05-30 22:38 | Paul Hunkar | Fixed in Version | 1.00.00 Release => 1.00.00 RC3 |
2022-05-30 22:38 | Paul Hunkar | Target Version | => 1.00.00 RC3 |