View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0009378 | 10000-008: Data Access | Spec | public | 2024-01-30 11:37 | 2024-08-28 14:33 |
Reporter | Mohit Agarwal | Assigned To | Karl Deiretsbacher | ||
Priority | normal | Severity | minor | Reproducibility | always |
Status | assigned | Resolution | open | ||
Product Version | 1.05.02 | ||||
Summary | 0009378: Improvemts to Part 8 - Quantities Model for usage inside Structures | ||||
Description | Use Case: In IJT Specifications, we report several types of values per second which are of custom structure types. Example: ResultValue { Double Value, String name, EUInformation engineeringUnits, Byte SimpleQuantityEnum, etc. } We wanted to use the QuantityDimension data type from Part 8 but it is NOT as easy to use for Structure Data Types. It is good a solution for Address Space Centric Models where Variables are exposed in the address space and can reference the Quantities folder and pre-defined quantities. Example Proposal: If identifiers exist, then the structure will just include simple property as String QuantityId, etc. The application can pre-load the list of quantities with their identifiers during the start-up of the application. Messages and data changes over data items or events payload just include the QuantityId inside the Structures and are easier to use. Any better suggestions also can be thought through but this WOULD help multiple domains to ADAPT the Quantities and EngineeringUnits more easily in the applications. | ||||
Additional Information | Had some initial discussion with Jim Luth for the RC comments on OPC 40450-1 and during that time, we mentioned that it is not easy to use Quantity model from Part 8 inside the Structures. | ||||
Tags | No tags attached. | ||||
Commit Version | |||||
Fix Due Date | |||||
|
By mistake added to Part 5 - but this belongs to Part 8. Unable to edit the issue, hence adding a comment here. |
|
The quantity model has been specified together with VDMA experts. These experts specifically opposed the selection of a specific unit system (like UCUM, QUDT, UNECE, ...). Based on their experience, different industries use different unit systems. |
|
Hi Karl, Thanks for your inputs. As the quantity names NEED NOT have to be dependent directly on the Unit System. Examples: We have DISTANCE, FORCE, SPEED, TIME, NUMBER, TORQUE, ANGLE, PRESSURE, TEMPERATURE, etc. These are the quantity names or symbols and if we have simplied standard name or MultiStateDiscreteType for these symbols, then we can directly include that as a property in the Structure. Example: DISTANCE is a quantity and Units can be KM or MILES or METERS, etc. but Quantity Name is same in that case. |
|
Please check with Carsten Born <Carsten.Born@vitronic.com> and Waszkewitz Peter (BCI/ESW18) <Peter.Waszkewitz@de.bosch.com>. They are experts and have designed the existing model. They will also know whether names can be unique and / or are also localizable. |
|
Hi, For now, we have no action from IJT CS and that is already published and in future, if we change the existing structures, we will try to use it. |
|
The only point which is NOT clear to me is: |
Date Modified | Username | Field | Change |
---|---|---|---|
2024-01-30 11:37 | Mohit Agarwal | New Issue | |
2024-01-30 11:41 | Mohit Agarwal | Note Added: 0020732 | |
2024-02-27 17:23 | Jim Luth | Project | 10000-005: Information Model => 10000-008: Data Access |
2024-02-27 17:24 | Jim Luth | Assigned To | => Karl Deiretsbacher |
2024-02-27 17:24 | Jim Luth | Status | new => assigned |
2024-02-28 08:11 | Karl Deiretsbacher | Note Added: 0020871 | |
2024-02-28 19:58 | Mohit Agarwal | Note Added: 0020877 | |
2024-08-14 06:01 | Karl Deiretsbacher | Note Added: 0021566 | |
2024-08-28 13:53 | Mohit Agarwal | Note Added: 0021628 | |
2024-08-28 14:33 | Mohit Agarwal | Note Added: 0021629 |