etpartners / b2mmlv7beta Goto Github PK
View Code? Open in Web Editor NEWb2mmlv7beta for review
b2mmlv7beta for review
ERDi, MESA:
Background
B2MML does not have an error handling schema. A basic set of error handling logic should be considered by MESA as starting point for users.
Solution
ADD: B2MML-ErrorMessage.XSD
This is an extension schema to help standardize the error handling logic.
MESAInternational/B2MML-BatchML#43
In Material Model, Per 950002, Both material lot and material sub lot objects apply the same material lot property object and instances in their definition. Thus in updated ISA-950002, there's no such model called MaterialSublotProperty,
In Material.xsd / MaterialSublotType, CHANGE MaterialSublotProperty element to MateralLotProperty reflect the property type.
ISA-950002 JWG5 CDV01 version (2019 12)
Table 72 – Material sublot relationship roles
B2MML-Material.xsd
MESAInternational/B2MML-BatchML#47
Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.
Solution
IF MESA does not except the OperationsTest.xsd change, the following changes are recommended to TestSpecification.xsd.
CHANGE: "TestPropertyMeasurementType" with "PropertyMeasurementType"
Multiple changes to TestSpecificationType to align with updated 950002 Operations Test Model's Test Specification object.
complexType name = "TestSpecificationType" element name = "EvaluatedProperty",
CHANGE: type = "TestSpecificationEvaluatedPropertyType" to "EvaluatedPropertyType"
complexType name = "TestSpecificationType"
CHANGE: element name = "PhysicalSample"
TO: "PhysicalSampleRequired"
complexType name = "TestSpecificationType",
ADD: element name = "OperationsTestRequirementID"
complexType name = "TestSpecificationType",
ADD: element name = "TestableObjectID"
950002 JWG5 CDV01 version (2019 12)
Clause 5.9.7 Evaluated property
Clause 5.9.4 Test specification, Table 103 – Test specification relationship roles
B2MML-TestSpecification.xsd
Refer to #10 where this issue and solution are part of the complete explanation and solution across all types. Duplicate with closed #13 and #14.
Background and Solution
ERDi, MESA: Material.xsd, MaterialSubLotType:
ADD TestSpecificationID
to align with updated 950002, Operations Test Model.
This also aligns with the OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinition. MESA may not do. ERDi should.
Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.7.8 Material sublot, Table 72 – Material sublot relationship roles
Clause 5.9.3 Testable object and testable object property, Table 100 Instances of testable object
b2mmlv7beta/Schema/B2MML-Material.xsd
Line 347 in 8ce6f9e
==================
MESAInternational/B2MML-BatchML#38
To align with the updated 950002, There is 0..* "maps to" association relationship from MaterialLotProperty to MaterialDefinitionProperty. The mapping relationship is missing from the current B2MML schema.
ISA-950002 JWG5 CDV01 version (2019 12)
Table 70 – Material lot property relationship roles
B2MML-Material.xsd
complexType name = "MaterialLotPropertyType",
ADD element name = "MaterialDefinitionPropertyID" type = "MaterialDefinitionPropertyIDType". This aligns to updated ISA-950002 JWG5 CDV01 version (2019 12).
Background
WorkflowSpecification.xsd
DELETE complexType name = "WorkflowSpecificationTypeType",
In the B2MML, this is an abstract type that simply refers only to two types, WorkflowSpecificationNodeTypeType and WorkflowSpecificationConnectionTypeType.
It is simply not needed especially since these types are individually exchanged as first order objects as master data.
Second, the name, WorkflowSpecificationType, is confusing to user since it implies that there are different types of a Workflow Specification which there is not in the updated ISA-950004.
Impact Analysis
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause, 6.16.1 Workflow specification model, Figure 5 – Workflow specification model
Clause 6.16.8 Workflow specification node type, Table 43 – Workflow specification node type relationship roles
Clause 6.16.10 Workflow specification connection type, Table 47 – Workflow specification connection type relationship roles
Impacted Types and Solution
Related Issues: #43, #45, #46, #47, #48
B2MML-WorkflowSpecification.xsd
B2MML-Extension.xsd
Background and Solutions
ERDi, MESA: OperationsDefnition.xsd
In the Updated 950002 Operations Definition Model, Operations Definition object has an "Has associated" association relationship to Operations Material Bill object which is a first order object. B2MML does not represent Operations Material Bill as a 1st order object.
B2MML is missing the target element for the "has associated" relationship to the Operations Material Bill from Both "OperationsSegmentType" and "OperationsDefinitionType" in OperationsDefinition.xsd.
Operations Definition has a "Contains" composite relationship to Operations Segment as the target role so it is not a 1st order object but master data contained in an Operations Definition; B2MML needs to delete the Operations segment transaction types.
Above are required to align with updated 950002 Operations Definition Model.
So the following changes are required:
complexType name = "OperationsDefinitionType
ADD: <xsd:element name = "OperationsMaterialBillID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
complexType name = "OperationsSegmentType
ADD: <xsd:element name = "OperationsMaterialBillID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
complexType name = "OperationsDefinitionInformationType"
ADD: <xsd:element name = "OperationsMaterialBill" type = "OperationsMaterialBillType" minOccurs = "0" maxOccurs = "unbounded"/>
Global Elements
ADD: <xsd:element name = "OperationsMaterialBill" type = "OperationsMaterialBillType" />
Transaction Elements
ADD: transaction elements for OperationsMaterialBillType
ADD: OperationsMaterialBill Transaction Types
DELETE: OperationsSegment Transaction Types
Deleted Operations segment transaction types since it a composite relationship to OperationsDefinition.
Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.1.1 Operations definition model, Figure 20 – Operations definition model
Clause 6.1.2 Operations definition, Table 145 – Operations definition relationship roles
Clause 6.1.5 Operations segment, Table 151 – Operations segment relationship roles
Clause 6.1.3 Operations material bill, Table 147 – Operations material bill relationship roles
Impacted Types and Solution
B2MML-OperationsDefinition.xsd
Background
ERDi, MESA: Refers to #49, #95, #101
In the updated 950002 Operations Test Model, the relationship source role name is not a required element for the "Corresponds to" unidirectional relationship from the Evaluated Property object (source) (under the Test Specification object) to the xxxProperty object (target, Testable Object Property). There is No reference attribute.
In B2MML, the EvaluatedPropertyReference element is not necessary and creates a circular reference since the Testable Object Property has a composite relationship to the Testable object which has the "specifies" relationship to associated TestSpecification element. The TestSpecifictionID identifies the defined the EvaluateProperty(s) by it composite relationship.
Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.5.3 Equipment class property, Table 41 – Equipment class property relationship roles
Clause 5.5.5 Equipment property, Table 45 – Equipment property relationships
Clause 5.6.3 Physical asset class property, Table 51 – Physical asset class property relationship roles
Clause 5.6.5 Physical asset property. Table 55 – Physical asset property relationship roles
Clause 5.7.3 Material class property, Table 62 – Material class property relationship roles
Clause 5.7.5 Material definition property, Table 66 – Material definition property relationship roles
Clause 5.7.7 Material lot property, Table 70 – Material lot property relationship roles
Clause 5.9.1 Operations test model, Figure 16- Operations test model
Clause 5.9.7 Evaluated property, Table 109 – Evaluated property relationship roles
Clause 5.11.3 Operations event class property, Table 128 – Operations event class property relationship roles
950004 JWG5 CDV01 version (2019 12)
Clause 6.16.3 Workflow specification property, Table 33 – Workflow specification property relationship roles
Impacted Types and Solution
From the following types:
DELETE: <xsd:element name = "EvaluatedPropertyReference" type = "EvaluatedPropertyReferenceType" minOccurs = "0"/>
Background
Align complexType name = "WorkDefintionType" in WorkDefinition.xsd to align with updated 950004 Work Definition Model.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.4 Work definition,
Impacted Types and Solution
B2MML-WorkDefinition.xsd
Align with updated 950004 Table 24 – Work definition relationship roles. Elements moved to WorkMasterType.
DELETE: element name = "OperationsDefinitionID"
DELETE: element name = "OperationsSegmentID"
DELETE: element name = "ProcessSegmentID"
DELETE: element name = "WorkflowSpecification"
Align with updated 950004 Table 25 – Work definition attributes (common in work master and work directive)
CHANGE: #61 element name = "Parameter"
TO: "ParameterSpecification"
MESAInternational/B2MML-BatchML#48
Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model by having "WorkflowSpecificationInformationType" address the 1st order objects used as master data.
Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.16.1 Workflow specification model, Figure 5 – Workflow specification model
Impacted Types and Solution
Related Issues: ##45, #46, #47, #48, #50
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationInformationType"
CHANGE: element name = "WorkflowSpecificationType" type = "WorkflowSpecificationTypeType"
TO: "WorkflowSpecificationNodeType" type = "WorkflowSpecificationNodeTypeType"
ADD: element name = "WorkflowSpecificationConnectionType" type = "WorkflowSpecificationConnectionTypeType" minOccurs = "0" maxOccurs = "unbounded"/>
To align the XXXActualTypes in the OperationsPerformanceTypes.xsd, B2MML requires the following:
CHANGE element name = "xxxActual" to "xxxActualChild"; #12
DELETE = element name = "TestSpecification".
B2MML-OperationsPerformanceTypes.xsd
950004 JWG5 CDV01 version (2019 12)
Clause 6.3.6 Personnel actual, Table 208 – Personnel actual relationship roles
Clause 6.3.8 Equipment actual, Table 212 – Equipment actual relationship roles
Clause 6.3.10 Physical asset actual, Table 216 – Physical asset actual relationship roles
Clause 6.3.12 Material actual, Table 220 – Material actual relationship roles
MESAInternational/B2MML-BatchML#49
Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.7 Workflow specification node type.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.8 Workflow specification node type
Table 43 – Workflow specification node type relationship roles
Table 44 – Workflow specification node type attributes
Impacted Types and Solution
Related Issues #48, #50, #51
complexType name = "WorkflowSpecificationNodeTypeType"
Global Element
1.1. ADD <xsd:element name = "WorkflowSpecificationNodeType" type = "WorkflowSpecificationNodeTypeType" />
Transaction Elements
2.1. ADD: All transaction elements for WorkflowSpecificationNodeType
Simple & Complex Types
3.1. ADD: to incorporate new proposed element
In the BHP JSON, the design rule was to use camel case for element names, B2MML does not. What is the ERDI design rule?
ERDi Decision:
What is design rule for AMIRA / ERDi Protobuf and JSON implementions?
Background
In updated 950002 and 950004 models, 95 Committee agreed that the standard's convention is show the logical direction of all UML model relationships. Most relationships in models are unidirectional from a source object to a target object where the UML and XML best practice is applied with only the naming of target role element in the relationship role table for each object.
The current B2MML 7.0 beta is very inconsistent by having both source and target elements for unidirectional relationships in many types and having no source element in many types.
Solution
MESA Solution: Since updated 950002 relationship role naming convention only names the target element and not source element, the existing instances of source elements in B2MML shall not be deleted to align with the updated standard but shall change the element name to XXXSourceID to make the role explicit in the object and it B2MML type to be schematically correct, MESA B2MML implementation is inconsistent in it use of source elements across the schema.
ERDi Options: Recommend B2MML adopt a consistent design principle in its implementation of either:
Example: EquipmentClassType, element name = "EquipmentID" type = "IdentifierType".
This the source in a unidirectional relationship in updated ISA-95 part 2 and B2MML represents it as a bidirectional relationship by having this element. This applies across all resource types.
The following elements are the current B2MML source elements for various relationships that are changed to the Option 1 naming convention:
Impacted Types and Solutions
Background
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.5 Workflow specification node property
Table 37 – Workflow specification node property relationship roles
Table 38 – Workflow specification node property attributes
Clause 6.16.7 Workflow specification connection property,
Table 41 – Workflow specification connection property relationship roles
Table 42 – Workflow specification connection property attributes
Clause 6.16.9 Workflow specification node type property
Table 45 – Workflow specification node type property relationship roles
Table 46 – Workflow specification node type property attributes
Clause 6.16.11 Workflow specification connection type property
Table 49 – Workflow specification connection type property relationship roles
Table 50 – Workflow specification connection type property attribute
Impacted Types and Solution
B2MML-WorkflowSpecification.xsd
complexType name = WorkflowSpecificationPropertyType
This Common property type shall be only apply to WorkflowSpecificationType and not to all property types; It shall be replaced with specific property types to align with updated 950004 Workflow Specification model.
ADD:
B2MML-Extension.xsd
MESAInternational/B2MML-BatchML#42
As defined in updated 950002,
ADD: element name = "HierarchyScope"
CHANGE #12 element name = "SegmentData" to "SegmentDataChild"
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.3.5 Segment data
Table 206 – Segment data relationship roles
Table 207 – Segment data attributes
B2MML-OperationsPerformanceTypes.xsd
Background and Solution
To align with updated 950002 and 950004, the defined relationship role names for the "Contains" and "Is made up of" nested association relationships in the Relationship Role Tables for many information models append "Child" to the target role element name nested under parent properties.
In B2MML, current child elements are not explicitly named to distinguish between parent verses child objects in implementations.
In B2MML with any nested structures like equipment hierarchy, there's an assumption that the nesting is from Parent to Child
<p:HierarchyScope>
<p:EquipmentID>CompanyA</p:EquipmentID>
<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
<p:HierarchyScope>
<p:EquipmentID>SiteB</p:EquipmentID>
<p:EquipmentLevel>Site</p:EquipmentLevel>
</p:HierarchyScope>
</p:HierarchyScope>
The issue is, in many cases, users would think the nested property is actually from Child to Parent. how can user tell what's wrong with below payload? (Nested from Child to Parent).
<p:HierarchyScope>
<p:EquipmentID>SiteB</p:EquipmentID>
<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
<p:HierarchyScope>
<p:EquipmentID>CompanyA</p:EquipmentID>
<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
</p:HierarchyScope>
</p:HierarchyScope>
By introducing Child to the tag naming, it becomes explicit the nested tag is referring a child of the current tag.
<p:HierarchyScope>
<p:EquipmentID>CompanyA</p:EquipmentID>
<p:EquipmentLevel>Enterprise</p:EquipmentLevel>
<p:HierarchyScopeChild>
<p:EquipmentID>SiteB</p:EquipmentID>
<p:EquipmentLevel>Site</p:EquipmentLevel>
</p:HierarchyScope>
</p:HierarchyScope>
As this proposed change impacts a lot of elements' name, the list of impacted types are not listed here but will be commented with the changelog.
**Refer to #10 where this issue and solution are part of the complete explanation and solution across all types. Duplicate with closed #13 and #15. **
ERDi, MESA: MaterialLotType: MaterialTestSpecificationID should be deprecated and replaced by TestSpecificationID to align with updated Part 2, Operations Test Model. This also aligns with the OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinition. MESA may not do. ERDi should.
Background
ERDi, MESA: Related #11
When the updated 950002 and 950004 first order objects are used to exchange the various forms of MOM Master Data, a version element in the B2MML Types used for Master Data instances is often required. In some use cases where there are multiple versions of a Master Data instance (ISA-95 1st order object) simultaneously used across a supply chain, the version attribute requires additional identification header information to differentiate each version as identification.
In the ISA95 October 2019 Meeting, an approved C. Gifford comment added 1) new text to the updated 950002 Clause 4.5.5. Object identification and 2) the Version attribute to all 1st order objects. The added text states that additional identification attributes/elements shall be used with Version attribute as required by the implementation.
The recommended identification attribute set is ID, Version, Published Date, Effective Start Date (Start Time) and Effective End Date (End Time) as typical for Master Data of MOM process and resource definitions used by planning and job order execution. Versioned Master Data are time constrained in applications without changing the ID to maintain change history. Some iSA-95 1st order objects have existing attributes of Start Time or End Time for EffectiveStartDate and EffectiveEndDate respectively. These existing similar attributes shall remain as is.
Solution
This issue and associated commits are to ADD the PublishedDate, EffectiveStartDate, and EffectiveEndDate elements to the following Resource Class and Definition Types to support the updating of a Master Data instance as its properties and/or attributes are changed.
Some B2MML types already have one or all three of these elements.
Issue #11 and associated commits are to ADD the version element.
EXAMPLE (or Similar)
complexType name = "MaterialClassType",
ADD element name = "PublishedDate" type = "DateTimeType"
ADD element name = "EffectiveStartDate" type = "DateTimeType"
ADD element name = "EffectiveEndDate" type = "DateTimeType"
Impacted Types:
Equipment.xsd:
EquipmentClassType DONE
EquipmentType DONE
Material.xsd:
MaterialClassType DONE
MaterialDefinitionType DONE
PhysicalAsset.xsd:
PhysicalAssetClassType DONE
PhysicalAssetType DONE
Personnel.xsd:
PersonnelClassType DONE
PersonType DONE
MasterDataProfile.xsd:
MasterDataProfileHeaderType DONE
CHANGE: element name = "ReleaseDate" TO: "PublishedDate"
ADD element name = "EffectiveStartDate" type = "DateTimeType"
ADD element name = "EffectiveEndDate" type = "DateTimeType"
OperationalLocation.xsd:
OperationalLocationClassType DONE
OperationalLocationType DONE
OperationsEvent.xsd:
OperationsEventClassType DONE
OperationsEventDefinitionType DONE
OperationsEventType DONE
-Use Existing element: <xsd:element name = "EffectiveTimeStamp"
-Use Existing element: <xsd:element name = "RecordTimeStamp"
ProcessSegment.xsd:
ProcessSegmentType DONE
OperationsDefinition.xsd:
OperationsDefinitionType DONE
OperationsSegmentType DONE
OperationsMaterialBillType DONE
OperationsMaterialBillItemType DONE
OperationsSchedule.xsd:
OperationsScheduleType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
OperationsRequestType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-PublishedDate: Not required since composite child object to OperationsScheduleType
OpSegmentRequirementType DONE
-Use Existing element: <xsd:element name = "EarliestStartTime"
-Use Existing element: <xsd:element name = "LatestEndTime"
-PublishedDate: Not required since composite child object to OperationsRequestType
OperationsPerformance.xsd:
OperationsPerformanceType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
OperationsResponseType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-PublishedDate: Not required since composite child object to OperationsPerformanceType.
OperationsPerformanceTypes.xsd:
OpSegmentResponseType DONE
-Use Existing element: <xsd: element name = "PostingDate"
-ADD element name = "PublishedDate" type = "DateTimeType"
-Use Existing element: <xsd:element name = "ActualStartTime"
-Use Existing element: <xsd:element name = "ActualEndTime"
OperationsCapability.xsd:
OperationsCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
OpProcessSegmentCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
OpOperationsSegmentCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
WorkDefinition.xsd
WorkDefinitionType DONE
-CHANGE: "EffectiveFrom" TO: "EffectiveStartDate"
-CHANGE: "EffectiveTo" TO: "EffectiveEndDate"
-Use Existing element: PublishedDate
WorkflowSpecification.xsd:
WorkflowSpecificationType DONE
WorkflowSpecificationNodeTypeType DONE
WorkflowSpecificationConnectionTypeType DONE
ResourceRelationshipNetwork.xsd
ResourceRelationshipNetworkType DONE
-CHANGE: <xsd:element name = "EffectiveFrom" TO: "EffectiveStartDate
-CHANGE: <xsd:element name = "EffectiveTo" TO: "EffectiveEndDate
-ADD: <xsd:element name = "PublishedDate"
ResourceNetworkConnectionTypeType DONE
-CHANGE: "EffectiveFrom" TO: "EffectiveStartDate"
-CHANGE: "EffectiveTo" TO: "EffectiveEndDate"
-Use Existing element: PublishedDate
WorkSchedule..xsd
WorkScheduleType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
WorkRequestType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-PublishedDate: Not required since composite child object to WorkScheduleType.
JobOrderListType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
JobOrderType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate
WorkPerformance.xsd
WorkPerformanceType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
WorkResponseType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
JobResponseType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
JobResponseListType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-ADD: <xsd:element name = "PublishedDate"
WorkCapability.xsd
WorkCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
WorkMasterCapabilityType DONE
-Use Existing element: <xsd:element name = "StartTime"
-Use Existing element: <xsd:element name = "EndTime"
-Use Existing element: <xsd:element name = "PublishedDate
WorkAlert.xsd
WorkAlertDefinitionType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkAlertType DONE
-ADD element name = "Description" type = "DescriptionType" minOccurs = "0" maxOccurs = "unbounded"/>
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkCalendar.xsd
WorkCalendarDefinitionType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkCalendarDefinitionEntryType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-CHANGE: <xsd:element name = "StartRule" type = "CodeType" minOccurs = "0"/>
TO: element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkCalendarType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
WorkCalendarEntryType DONE
-Use Existing element: <xsd:element name = "StartDateTime"
-Use Existing element: <xsd:element name = "FinishDateTime"
-ADD: <xsd:element name = "PublishedDate"
Common.xsd:
OperationsRecordSpecTemplateType DONE
-ADD element name = "PublishedDate" type = "DateTimeType"
-ADD element name = "EffectiveStartDate" type = "DateTimeType"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
OperationsRecordTemplateType DONE
-Use Existing element: <xsd:element name = "RecordTimestamp" for "PublishedDate"
-Use Existing element: <xsd:element name = "EffectiveTimestamp" for "EffectiveStartDate"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
OperationsRecordEntryTemplateType DONE
-Use Existing element: <xsd:element name = "RecordTimestamp" for "PublishedDate"
-Use Existing element: <xsd:element name = "EffectiveTimestamp" for "EffectiveStartDate"
-ADD element name = "EffectiveEndDate" type = "DateTimeType"
TestResultType
-ADD element name = "PublishedDate" type = "DateTimeType"
-Use Existing element: <xsd:element name = "EvaluationDate" for "EffectiveStartDate"
-Use Existing element: <xsd:element name = ""Expiration" for "EffectiveEndDate"
This issue and solution are the complete explanation and solution across all types which include closed issues #13, #14, and #15.
Background
In B2MML, all instances of the XXXTestSpecificationID element should be changed to TestSpecificationID to align with updated 950002 Operations Test Model.
Also, general use of TestSpecificationID aligns with the existing OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinitionType.
MESA may not do this solution. ERDi should.
Impacted Types and Solutions
Supporting Documents
950002 JWG5 CDV01 version (2019 12)
Clause 5.4.2 Personnel class, Table 30 – Personnel class relationship roles
Clause 5.4.4 Person, Table 34 – Person relationship roles
Clause 5.5.2 Equipment class, Table 39 – Equipment class relationship roles
Clause 5.5.4 Equipment, Table 43 – Equipment relationship roles
Clause 5.6.2 Physical asset class, Table 49 – Physical asset class relationship roles
Clause 5.6.4 Physical asset, Table 53 – Physical asset relationship roles
Clause 5.7.2 Material class, Table 60 – Material class relationship roles
Clause 5.7.4 Material definition, Table 64 – Material definition relationship roles
Clause 5.7.6 Material lot, Table 68 – Material lot relationship roles
Clause 5.7.8 Material sublot, Table 72 – Material sublot relationship roles
Clause 5.7.8 Material sublot, Table 72 – Material sublot relationship roles
Clause 5.9.3 Testable object and testable object property, Table 100 Instances of testable object
Simplify the current way to define enumerates type.
<xsd:complexType name="AssemblyRelationship1Type">
<xsd:simpleContent>
<xsd:restriction base="CodeType">
<xsd:enumeration value="Permanent"/>
<xsd:enumeration value="Transient"/>
<xsd:enumeration value="Other"/>
</xsd:restriction>
</xsd:simpleContent>
</xsd:complexType>
<xsd:complexType name="AssemblyRelationshipType">
<xsd:annotation>
<xsd:documentation>
Defines the type of the relationships.
Defined types are
- Permanent: an assembly that is not intended to be split during the production process;
- Transient: a temporary assembly using during production, such as a pallet of different materials or a batch kit.
</xsd:documentation>
</xsd:annotation>
<xsd:simpleContent>
<xsd:extension base="AssemblyRelationship1Type">
<xsd:attribute name="OtherValue" type="xsd:string"/>
</xsd:extension>
</xsd:simpleContent>
</xsd:complexType>
<xsd:simpleType name="AssemblyRelationshipType">
<xsd:restriction base="xsd:string">
<xsd:enumeration value="Permanent"/>
<xsd:enumeration value="Transient"/>
<xsd:enumeration value="Other"/>
</xsd:restriction>
</xsd:simpleType>
MESAInternational/B2MML-BatchML#35
Background and Solution
ERDi, MESA: Common.xsd
ADD <xsd:complexType name="DispositionType">, with defined values to align with updated 950002 Material Lot Object.
b2mmlv7beta/Schema/B2MML-Common.xsd
Lines 437 to 468 in c295c79
Impacted Types
B2MML - Common.xsd
Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.7.6 Material lot, Table 69 – Material lot attributes
Clause 5.7.8 Material sublot, Table 73 – Material sublot attributes
Related Issues
#22
Background
OperationsDefinition.xsd
OperationsDefintionType and OperationsSegmentType use WorkDefinitionID, Per the updated 950002, the "corresponds to" association is from the Work Master object, not the Work Definition object. Align with updated 950002.
B2MML is using the an incorrect multiplicity for each relationship target names for OperationsDefinitionType and OperationsSegmentType. Align with updated 950002 Operations Definition Model.
Supporting Documents
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.1.2 Operations definition, Table 145 – Operations definition relationship roles
Clause 6.1.5 Operations segment, Table 151 – Operations segment relationship roles
Impacted Types and Solution
B2MML-OperationsDefinition.xsd
1.2. For the following elements:"BillOfMaterialsID", "WorkMasterID", "BillOfResourcesID"
CHANGE: minOccurs = "0"/>min
TO: Occurs = "0" maxOccurs = "unbounded"/>
2.2. For the following elements: "BillOfMaterialsID", "WorkMasterID", "BillOfResourcesID"
CHANGE: minOccurs = "0"/>min
TO: Occurs = "0" maxOccurs = "unbounded"/>
THE BACKGROUND and COMMENT IS INCORRECT. SEE REWRITE COMMENT BELOW.
There is 0..* map relationship from a certain object's Property to the object's ClassProperty. The mapping relationship is missing from the current B2MML schema.
For example, an EquipmentProperty can be mapped to multiple Equipment Class Properties.
ISA-950002 JWG5 CDV01 version (2019 12)
Table 45 – Equipment property relationships
Table 66 – Material definition property relationship roles
B2MML-Equipment.xsd
B2MML-Material.xsd
Background
Common.xsd
complexType name="SegmentDependencyType", Align with updated 950002 Operations Definition Model.
DELETE:
ADD:
Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.1.15 Segment dependency, Table 172 – Segment dependency attributes
Impacted Types
B2MML-Common.xsd
Background
Align with updated 950004 Workflow Specification Model, Clause 6.16.10 Workflow specification connection type.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.10 Workflow specification connection type
Table 47 – Workflow specification connection type relationship roles
Table 48 – Workflow specification connection type attributes
Impacted Types and Solution
Related Issues #47, #50, #51
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationConnectionTypeType"
Global Element
1.1. ADD <xsd:element name = "WorkflowSpecificationConnectionType" type = "WorkflowSpecificationConnectionTypeType" />
Transaction Elements
2.1. ADD: All transaction elements for WorkflowSpecificationConnectionType
Simple & Complex Types
complexType name = "WorkflowSpecificationConnectionTypeType"
3.1. ADD: to incorporate new proposed elements
3.2. CHANGE: #51
3.3. ADD: Align with updated 950004 Workflow Specification Model.
MESAInternational/B2MML-BatchML#30
to align with updated 950002 Operational Location Model in Material Model, the following changes are required.
complexType name = "MaterialLotType", element name ="StorageLocation";
CHANGE: type = "StorageHierarchyScopeType" to "ResourceLocationType"
complexType name = "MaterialSubLotType", element name ="StorageLocation";
CHANGE: type = "StorageHierarchyScopeType" to "ResourceLocationType"
Material.xsd
950002 JWG5 CDV01 version (2019 12)
Clause 5.7.6 Material lot, Table 69 – Material lot attributes
Clause 5.7.8 Material sublot, Table 73 – Material sublot attributes
**Background **
MESA may not make this change. ERDi should.
Align BatchML-BatchInformation.xsd with B2MML-Common.xsd:
Impacted Types and Solutions
To align with updated ISA950002 and ISA880002, Change the following,
For an " XXXproperty" attribute/element in an object schema, what is the ERDI design rule? Make a property an exchange master data object or include property schema in object schema (including nested child properties?)
Background and Solution
ERDi, MESA: Related to #101
To align with updated 950002 Operations Test Model's relationships.
Align TestResult element with updated 950002, Operations Test Model where the Test Result object has an association relationships with the resource actual objects.
Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.
Solution
IF MESA does not except this change, the following change is recommended to Common.xsd.
CHANGE: "TestPropertyMeasurementType" with "PropertyMeasurementType"
Impacted Types
Common.xsd
TestPropertyMeasurementType
Supporting Document
950002 JWG5 CDV01 version (2019 12)
Clause 5.9.9, Property measurement, Table 114 Property measurement attributes.
ERDI, MESA: Related to #101
TestSpecification.xsd
Background
Align TestResult element with updated 950002, Operations Test Model where the Test Result object has an association relationships with the resource actual objects.
Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.
Solution
IF MESA does not except OperationsTest.xsd change, the following change is recommended to TestSpecification.xsd.
CHANGE complexType name = "TestSpecificationEvaluatedPropertyType" to "EvaluatedPropertyType" to match explicit name of object to align with updated 950002 Operations Test Model's Test Specification object and EvaluatedProperty object.
ERDI, MESA: TestSpecification.xsd, complexType name = "EvaluatedPropertyType",
ADD "TestableObjectPropertyID" element to align with updated 950002 Operations Test Model's relationships for the Test Specification object and EvaluatedProperty object.
B2MML-TestSpecification.xsd
950002 JWG5 CDV01 version (2019 12)
Clause 5.9.7 Evaluated property, Table 109 – Evaluated property relationship roles
Background
B2MML is missing the "corresponds to" relationship between Segment Response and Segment Requirement objects in the Operations Performance Model.
ADD a SegmentRequirementID reference element to OpSegmentResponseType to align to the updated 950002 Operations Performance Model.
Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 6.3.4 Segment response, Table 204 – Segment response relationship roles
Impacted Types and Solution
B2MML-OperationsPerformanceTypes.xsd
ADD: <xsd:element name = "SegmentRequirementID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
Background
B2MML currently has DefinitionType element on the following types:
B2MML is missing the DefinitionType element for a new attribute on the following types:
The DefintionType attribute on process definition objects defines the object as either the Pattern object (target) or the (source) instance to support the "Defined by" exclusive Specialization relationship (0..1 for target element). The source object (instance or child pattern) is defined by a single Pattern object as a template for its objects and its properties._
The Pattern object lacks the details to be scheduled or executed where Instance object is able to be scheduled or executed. The Instance object is defined by Pattern object, This relationship applies to the sharing of the whole complex Pattern object with its composite objects and its properties in the Instance object (not to just properties of a single of object).
Supporting Document
ISA-950002 JWG5 CDV01 version (2019 12)
ISA-950004 JWG5 CDV01 version (2019 12)
Impacted Types and Solutions
950002
B2MML-Common.xsd
B2MML-OperationsDefinition.xsd
950004
B2MML-WorkDefinition.xsd
B2MML-WorkflowSpecification.xsd
ADD: To the above types
<xsd:element name = "DefinitionType" type = "DefinitionTypeType" minOccurs = "0"/>
Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.3 Workflow specification node.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.4 Workflow specification node
Table 35 – Workflow specification node relationship roles
Table 36 – Workflow specification node attributes
Impacted Types and Solution
complexType name = "WorkflowSpecificationNodeType"
CHANGE: Align naming more closely with updated 950004 Workflow Specification Model to reduce confusion.
ADD: Align with updated 950004 Workflow Specification Model.
Background
ERDi, MESA: Related #9
When the updated 950002 and 950004 first order objects are used to exchange the various forms of MOM Master Data, a version element in the B2MML Types shall be used for master data instances as required. In some use cases where there are multiple versions of a Master Data instance (ISA-95 1st order object) simultaneously used across a supply chain, the version attribute requires additional identification header information to differentiate each version as MD identification.
In the ISA95 October 2019 Meeting, one of the approved C. Gifford comments added
Solution
This issue and associated commits are to ADD the "Version" element to following Resource and Definition Types to support the updating of a master data instance as its properties and/or attributes are changed. Some B2MML types already have a version element.
Issue #9 and its associated commits are to ADD the PublishedDate, EffectiveStartDate, and EffectiveEndDate or use exisitng similar elements.
This issue for version element and master data dates (#9) are updated per approved comment at ISA-95 Meeting.
Additional Issue Addressed in This Solution
In Common.xsd, VersionType simply calls IdentiferType.
ETP recommend to MESA to simply the B2MML implementation by deleting Version Type and changing all Version elements to IdentifierType.
Current Common.xsd
<xsd:complexType name="VersionType">
xsd:simpleContent
<xsd:restriction base="IdentifierType"/>
</xsd:simpleContent>
</xsd:complexType>
EXAMPLE SOLUTION
complexType name = "MaterialClassType"
element name = "Version" type = "IdentifierType" minOccurs = "0"/>
Impacted Types:
WorkflowSpecification, WorkflowSpecificationNodeType, WorkflowSpecificationConnectionType
Equipment.xsd:
EquipmentClassType DONE
EquipmentType DONE
Material.xsd:
MaterialClassType DONE
MaterialDefinitionType DONE
MaterialLotType DONE
MaterialSublotType DONE
PhysicalAsset.xsd:
PhysicalAssetClassType DONE
PhysicalAssetType DONE
Personnel.xsd:
PersonnelClassType DONE
PersonType DONE
MasterDataProfile.xsd:
MasterDataProfileHeaderType DONE
OperationalLocation.xsd:
OperationalLocationClassType DONE
OperationalLocationType DONE
OperationsEvent.xsd:
OperationsEventClassType DONE
OperationsEventDefinitionType DONE
OperationsEventType DONE
ProcessSegment.xsd:
ProcessSegmentType DONE
OperationsDefinition.xsd:
OperationsDefinitionType DONE
OperationsSegmentType DONE
OperationsMaterialBillType DONE
OperationsMaterialBillItemType DONE
OperationsSchedule.xsd:
OperationsScheduleType DONE
OperationsRequestType DONE
OpSegmentRequirementType DONE
OperationsPerformance.xsd:
OperationsPerformanceType DONE
OperationsResponseType DONE
OperationsCapability.xsd:
OperationsCapabilityType DONE
OpProcessSegmentCapabilityType DONE
OpOperationsSegmentCapabilityType DONE
WorkDefinition.xsd
WorkDefinitionType DONE
WorkflowSpecification.xsd:
WorkflowSpecificationType DONE
WorkflowSpecificationNodeTypeType DONE
WorkflowSpecificationConnectionTypeType DONE
ResourceRelationshipNetwork.xsd
ResourceRelationshipNetworkType DONE
ResourceNetworkConnectionTypeType DONE
WorkSchedule..xsd
WorkScheduleType DONE
WorkRequestType DONE
JobListType DONE
JobOrderType DONE
WorkPerformance.xsd
WorkPerformanceType DONE
WorkResponseType DONE
JobResponse DONE
JobResponseListType DONE
WorkCapability.xsd
WorkCapabilityType DONE
WorkMasterCapabilityType DONE
WorkAlert.xsd
WorkAlertDefinitionType DONE
WorkAlertType DONE
WorkCalendar.xsd
WorkCalendarDefinitionType DONE
WorkCalendarDefinitionEntryType DONE
WorkCalendarType DONE
Common.xsd:
OperationsRecordSpecTemplateType DONE
OperationsRecordTemplateType DONE
OperationsRecordEntryTemplateType DONE
TestResultType DONE
BatchML-BatchInformation.xsd
ApprovalHistoryType DONE
ControlRecipeType DONE
ListHeaderType DONE
MasterRecipeType DONE
RecipeElementType DONE
-- Commonly used elements -- DONE
Background
Align complexType name = "ProcessSegmentType" in ProcessSegment.xsd with updated 950002 Process Segment Model.
Supporting Documents
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 5.8.2 Process segment,
Impacted Types and Solution
B2MML-ProcessSegment.xsd
CHANGE: #12 element name = "ProcessSegment"
TO: element name = "ProcessSegmentChild"
ADD: element name = "DependentProcessSegmentID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: #32 element name = "ProcessSegmentPatternID" type = "IdentifierType" minOccurs = "0"/>
#2 Since updated 950002 relationship role naming convention only names the target element and not source element, the existing instances of source elements in B2MML shall not be deleted to align with the updated standard but shall change the element name to XXXSourceID to make the role explicit in the object and it B2MML type to be schematically correct, MESA B2MML implementation is inconsistent in it use of source elements across the schema.
CHANGE:
These elements are the source of the "Corresponds To" unidirectional relationship, not the target, element; The current element names are very confusing since process segment DOES NOT "correspond to" the source element.
B2MML creates common types for each element and subelement in the common schema; Many of the common types in the common schema simply reference common types like codeType, IdentifierType, string, etc. In the BHP JSON, we just used common types like string, array, object, etc. What is the ERDI design rule?
Background
Align complexType name = "WorkDirectiveType" in WorkDefinition.xsd with updated 950004 Work Definition Model.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.6 Work directive relationship roles and attributes,
Table 28 – Work directive relationship roles
Table 29 – Work directive attributes
Impacted Types and Solution
B2MML-WorkDefinition.xsd
Align with updated 950004 Table 28 – Work directive relationship roles
CHANGE: #12 element name = "WorkDirective"
TO: "WorkDirectiveChild"
ADD: element name = "WorkDirectiveState"
This is a new attribute for Work Directive object to align with other state attributes for the Job Order State Model. Comment approved by 95 Committee at October 28th 2019 meeting.
CHANGE: #2 element name = "JobOrderID"
TO: JobOrderSourceID
Since updated 950002 relationship role naming convention only names the target element and not source element, the existing instances of source elements in B2MML shall not be deleted to align with the updated standard but shall change the element name to XXXSourceID to make the role explicit in the object and it B2MML type to be schematically correct, MESA B2MML implementation is inconsistent in it use of source elements across the schema.
In Table 28, the Job Order element is the source of the "Corresponds To" unidirectional relationship between Work Directive and Job Order objects; element is not the target, so Work Master and Work Directive objects do not "correspond to" the source element and the type should not reference the relationship source in this schema.
Closed: Duplicate of Issue #12 and #75
ADD element name = "xxxActualPropertyChild";
ADD element name = "xxxClassPropertyID";
ADD element name = "xxxPropertyID"
Take Personnel Actual as an example,
ISA-950002
Section 6.3.7
B2MML-OperationsPerformanceTypes.xsd
OpPersonnelActualPropertyType
OpEquipmentActualPropertyType
OpMaterialActualPropertyType
OpPhysicalAssetActualPropertyType
Below change is tracked by #53
DELETE element name = "RequiredByRequestedSegmentResponse"
MESAInternational/B2MML-BatchML#44
Background
B2MML 7.0 still has the TestResult element in each instance resource property type per the old version of ISA-95 resource models and B2MML 6.0. The old resource model had an association relationship from each resource property to the Test Result object which did not allow Test Result object to be exchanged and queried as a 1st class object and did not allow Test Result object to be related to resource actuals.
The updated 950002 as part of the collaboration with OAGi changed Test Results to a 1st order object as part of the Operations Test Model.
ADDED new OperationsTest.xsd schema #101 with TestSpecificationType and TestResultType which allows 1st order transactions for both types. I do not believe that the 1st order transactions for both types were added to the updated 950005.
B2MML 7.0 beta only has B2MML-TestSpecification.xsd schema and has complex types of "TestResultType" and TestPropertyMeasurementType in the Common Schema.
In the new Operations Test Model in updated 950002, Test Result object is a 1st order object that is able to be exchanged/queried and has relationship to resource actual which is represented as a root element.
The MESA Committee may reject changing their implementation. If so, ERDi should create per updated standard.
Supporting Documents
Clause 5.9.1 Operations test model
Each of following resource models in updated 95002 do not have a Test Result object in their resource property objects. In the Operations Test Model, each of following resource models do have a Testable Object object that are target role in an association relationship from the Test Result object.
Clause 5.4.1 Personnel model
Clause 5.5.1 Role-based equipment model
Clause 5.6.1 Physical asset model
Clause 5.7.1 Material model
The following resource actual objects have a Test Result attributes per the Operations Test model
Clause 6.3.6 Personnel actual, Table 208 – Personnel actual relationship roles
Clause 6.3.8 Equipment actual, Table 212 – Equipment actual relationship roles
Clause 6.3.10 Physical asset actual, Table 216 – Physical asset actual relationship roles
Clause 6.3.12 Material actual, Table 220 – Material actual relationship roles
Impacted Types and Solutions
B2MML - Equipment.xsd, EquipmentPropertyType
B2MML - Material.xsd, MaterialLotPropertyType
B2MML - PhysicalAsset.xsd, PhysicalAssetPropertyType
B2MML - Personnel.xsd, PersonPropertyType
DELETE: TestResult element
Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.2 Workflow specification.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.2 Workflow specification
Table 31 – Workflow specification relationship roles
Table 32 – Workflow specification attributes
Impacted Types and Solution
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationType"
Align naming more closely with updated 950004 Workflow Specification Model to reduce user confusion.
CHANGE:
MESAInternational/B2MML-BatchML#36
Charlie's comment (modified to cover all changes)
ERDi, MESA: ADD element name = "Disposition", type = "DispositionType" to align with updated ISA-95 Part 2 Material Lot and Material SubLot Object. Add DispositionType to Common Schema.
B2MML - Material.xsd
950002 JWG5 CDV01 version (2019 12)
Clause 5.7.6 Material lot, Table 69 – Material lot attributes
Clause 5.7.8 Material sublot, Table 73 – Material sublot attributes
MESAInternational/B2MML-BatchML#37
Equipment.xsd
complexType name = "EquipmentType"
CHANGE: element name = "EquipmentLevel" type = "HierarchyScopeType" minOccurs = "0" />
TO: type = type = "EquipmentLevelType" minOccurs = "0" />
ADD element name ="PhysicalAssetID" type = "IdentifierType" minOccurs = "0"/>
ADD element name = "OperationalLocationType" type = "ResourceLocationTypeType"
complexType name = "EquipmentClassType">
CHANGE: element name = "EquipmentLevel" type = "HierarchyScopeType" minOccurs = "0" />
TO: type = "EquipmentLevelType" minOccurs = "0" />
ISA-950002 JWG5 CDV01 version (2019 12)
Clause 5.5.2 Equipment class
Table 40 – Equipment class attributes
Clause 5.5.4 Equipment
Table 43 – Equipment relationship roles
Table 44 – Equipment attributes
B2MML-Equipment.xsd
Background
ERDi, MESA:
The original B2MML complexType name = "WorkflowPropertyType" is incorrect and confusing since it does not align with updated 950004.
Impacted types
B2MML-WorkflowSpecification.xsd
Solution
Other changes to updated "WorkflowSpecificationPropertyType" already covered by other issues,
Supporting document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.3 Workflow specification property
Refer to #10 where this issue and solution are part of the complete explanation and solution across all types. Duplicate with closed #14 and #15.
Background
In the B2MML, all instances of the XXXTestSpecificationID element should be changed to TestSpecificationID to align with updated 950002 Operations Test Model.
Also general use of TestSpecificationID aligns with the existing OpMaterialRequirementType: TestSpecificationID in the Common Schema for use in OperationsDefinitionType.
MESA may not do this solution. ERDi should.
Impacted Types and Solution
ERDi, MESA: MaterialClassType:
CHANGE: MaterialTestSpecificationID element
TO: TestSpecificationID
The following Types shall be changed similiarly:
COMPLETE ISSUE EXPLANATION with all running comments incorporated. Related to #35
Background:
The required object and relationship updates for the proposed solutions were approved in comments to the ISA95 Committee October 2019 Meeting.
In analyzing the updated 950002 and 950004 "Includes properties of" specialization relationships and then researching on best practices of UML and XML, the current relationship and target role names are incorrect and not best practice for this type of relationship. Recommended Solutions below.
"IncludesPropertiesOf" relationship in the ISA-95 models actually address 2 very different specialization use cases in terms of UML and XML generalization and specialization best practice. Both explained below. The B2MML implementation uses only the "IncludesPropertiesOfXXXID" convention (or similar) for both uses which is semantically and logically incorrect.
Overlapping Specialization Use Case (member of a grouping, 0..*)
The specialization"IncludesPropertiesOf" relationship on the objects addressing the Overlapping Specialization Use Case shall not be renamed.
Overlapping Specialization (0..* for target element) where source element uses the properties of each identified group to define a specialization class of classes.
In updated 950002 and 950004, the original defined Target Role name of XXXParent for "IncludesPropertiesOf" relationships in models is not correct for the relationship semantics and logic; the Target Role is now approved as XXXBase for 0...* as list of member classes in a specialization group where the source object maps to the properties of the group members.
Supporting Documents. This change applies to following objects
ISA-950002 JWG5 CDV01 version (2019 12)
Clause
ISA-950004 JWG5 CDV01 version (2019 12)
Clause
SOLUTION:
Overlapping specialization (0..*) applies to figures and tables above.
CHANGE: Target Role name from XXXParentID to XXXBaseID in the relationship role tables for each Clause above and associated B2MML Type. This relationship for a specialization group is a cumulative properties set of base classes for the source where each member contributes to the specialized properties of the source.
SAMPLE: <xsd:element name = "WorkflowSpecificationNodeTypeBaseID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
OperationsEvent.xsd, OperationsEventClassType
CHANGE: For OperationsEventClassBaseID element, change multiplicity from 0..1 to 0..* for “includes property of” association relationship; Like material class, Operations Event Class “includes properties of” relationship is a grouping (not an instance-to-pattern use case).
WorkflowSpecification.xsd, WorkflowSpecificationNodeType
DELETE: WorkflowSpecificationNodeParentID for "Uses Properties Of" relationship from 950004 on the Workflow Specification Node object in:
Exclusive Specialization (0..1 for target element)
The specialization"IncludesPropertiesOf" relationship shall be renamed "Defined by" relationship for the Exclusive Specialization Use Case (0..1 for Pattern vs. Instance) shall be renamed from XXXParentID to XXXPatternID.
The Target Role object's naming convention of the Exclusive Specialization Use Case (0..1 for Pattern vs. Instance) shall be renamed from XXXParentID to XXXPatternID.
The source object (instance or child pattern) in the "Defined by" association relationship uses a one specific Pattern object as a template for its objects and its properties.
This type of relationship is supported by the Definition Type attribute on process definition objects by identifying the Pattern ID (target) for the (source) instance. This is why the multiplicity is 0..1.
The Pattern object lacks the details to be scheduled or executed where Instance object is able to be scheduled or executed. The Instance object is defined by Pattern object.
This "Defined by" association relationship does not define a class of classes where only properties are shared across a specialized group as in the Overlapping Specialization. The relationship applies to the sharing of the whole complex Pattern object with its composite objects and its properties in the Instance object (not to just properties of a single of object).
This relationship applies across the object's attributes, relationships and their properties, not to just properties. This specialization relationship is very different than the "includes properties of" relationship which has a multiplicity of 0..* which uses properties from any objects to define a single object.
Supporting Documents. The changes of the relationship and relationship name are applied in the following object figures and tables:
ISA-950002 JWG5 CDV01 version (2019 12)
SOLUTION:
Exclusive Specialization (0..1), single Pattern object template for an Instance object, applies the below changes to the objects in the list of figures and tables above.
CHANGE: Target Role name from XXXParentID to XXXPatternID in the relationship role tables for each Clause above and associated B2MML Type so it semantically correct for this use case.
SAMPLE: <xsd:element name = "WorkflowSpecificationPatternID" type = "IdentifierType" minOccurs = "0"/>
ADD: #35 Definition Type element under each Type to support the object definition as either an instance or pattern template object. This reduces user confusion since name is more explicit to Pattern/Instance semantic purpose.
Supporting Document
The Supporting Documents are listed above. But the below paragraphs from Clause 6.1.1. and above Solution changes apply to the 950002 and 950004 Clauses for process segment, operations definition operations segment, work master, and workflow specification
950002, Clause 6.1.1 Operations definition model, paragraphs 4 to 6.
“An operations definition instance may be a specialization of pattern operations definition object. An operations definition shall be defined as pattern or instance. A pattern operations definition defines a ‘template’, upon which other or instance operations definitions may be based. Unlike instance operations definitions, pattern operations definitions shall not be directly scheduled or tracked. Therefore, operations requests and operations responses shall not reference pattern operations definitions.
Pattern operations definitions shall provide a basis for standardization and reuse of pattern operations definitions across many instance operations definitions across and between plants. Where an operations definition references a work master defined in Part 4 of this standard, the definition type (pattern or instance) attribute of the referenced work master shall have the same value as that of the operations definition.
The operations material bill and bill of resources of an operations definition may map to those of any pattern operations definition upon which the operations definition is based.
EXAMPLE 1 A pattern operations definition can reference an operations material bill that contains items referencing material classes, while a instance operations definition based on this pattern operations definition can reference an operations material bill that contains items referencing material definitions belonging to those material classes.
EXAMPLE 2 A mining organization could define the following pattern and instance operations definitions:
• loading (pattern);
• train loading (pattern), specialization of loading (pattern);
• ship loading (pattern), specialization of loading (pattern);
• Site S1 train loading (instance), specialization of train loading (pattern);
• Site S2 ship loading (instance), specialization of ship loading (pattern)”
Background
Align complexType name = "WorkMasterType" in WorkDefinition.xsd with updated 950004 Work Definition Model.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.5 Work master relationship roles and attributes, Table 26 – Work master relationship roles
Impacted Types and Solution
B2MML-WorkDefinition.xsd
ADD: element name = "OperationsDefinitionID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: element name = "OperationsSegmentID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: element name = "ProcessSegmentID" type = "IdentifierType" minOccurs = "0" maxOccurs = "unbounded"/>
ADD: element name = "WorkflowSpecification" type = "WorkflowSpecificationType" minOccurs = "0"/> (0..1: CHANGE from minOccurs = "0" maxOccurs = "unbounded"/>)
ADD: #35 element name = "DefinitionType"
CHANGE: #12 element name = "WorkMaster" TO "WorkMasterChild" to align with Part 4 Work Master relationship table.
CHANGE: #32 element name = "IncludesPropertiesOf" TO "WorkMasterPatternID" type = "IdentifierType" minOccurs = "0"/> (0..1: CHANGE from minOccurs = "0" maxOccurs = "unbounded"/>) to align with Part 4 Work Master relationship table.
Where B2MML Schema uses a “xxxID” to reference other master data objects. B2MML explicitly define the ID for both single element (0..1) and multiple (n) elements (0..n) as collection. In the BHP JSON schema, the design rule was to use the common best practice of xxxId and xxxIds to be explicit between single vs. collections, respectively. What is the ERDi design rule?
Background
ERDi, MESA: Related to #7, #101
Align TestResult element with updated 950002, Operations Test Model where the Test Result object has an association relationships with the resource actual objects.
Under issue #101, the new OperationsTest.xsd schema is added to align with 950002 by including TestSpecificationType and TestResultType together which allows 1st order transactions for both types.
B2MML 7.0 beta only created a B2MML-TestSpecification.xsd schema and created the complex types of "TestResultType" and TestPropertyMeasurementType in the Common Schema.
HOWEVER, B2MML 7.0 still has the TestResult element in each instance resource property per the old version of ISA-95 resource models and B2MML 6.0. The old resource model had a composite relationship from the each resource property of the resource master data objects which did not allow Test Result attribute to be exchanged and queried as a 1st class object. This design has the logic issue where a test result is related to testing of a resource actual to a master data resource's test specification. The old resource models had a composite relationship which did not allow Test Result to be exchanged and queried as a 1st class object.
Supporting Documents
Clause 6.3.6 Personnel actual, Table 208 – Personnel actual relationship roles
Clause 6.3.8 Equipment actual, Table 212 – Equipment actual relationship roles
Clause 6.3.10 Physical asset actual, Table 216 – Physical asset actual relationship roles
Clause 6.3.12 Material actual, Table 220 – Material actual relationship roles
Impacted Type and Solutions
_OperationsPerformanceTypes.xsd,
Background
Explicitly Align B2MML with updated 950004 Workflow Specification Model, Clause 6.16.5 Workflow specification connection.
Supporting Document
ISA-950004 JWG5 CDV01 version (2019 12)
Clause 6.16.6 Workflow specification connection
Table 39 – Workflow specification connection relationship roles
Table 40 – Workflow specification connection attributes
Impacted Types and Solution
B2MML-WorkflowSpecification.xsd
complexType name = "WorkflowSpecificationConnectionType"
CHANGE: Align naming more closely with updated 950004 Workflow Specification Model to reduce confusion.
ADD: Align with updated 950004 Workflow Specification Model.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.