search

MESAInternational / B2MML-BatchML

B2MML is an XML implementation of the ANSI/ISA-95, Enterprise-Control System Integration, family of standards (ISA-95), known internationally as IEC/ISO 62264. B2MML consists of a set of XML schemas written using the World Wide Web Consortium's XML Schema language (XSD) that implement the data models in the ISA-95 standard.
Other
92 stars 45 forks source link

StorageLocation tag definition inconsistent inside MaterialLot, MaterialRequirement #30

Closed racheliurui closed 4 years ago

racheliurui commented 5 years ago

Update, we now have a new issue with implementing the Operational Location. We want to sync systems using the OperationLocation but we found the current schema of MaterialRequirement/StorageLocation do not align with ISA-95 v2. See below screen copy. We hope the storage location can support nested structure like hierarchy scope, so that we can avoid doing string splitting to get the the storage location nested layer.

image

======Original Quesion=========== I am not quite sure about the difference between "ResourceLocationType" and "SotrageHierarchyScopeType" but it's inconsistent while being referred as the "MaterialLot/StorageLocation" and "MaterialRequirement/StorageLocation".

We have used the ResouceLocationType with MaterialRequirement, but then the "MaterialLot/StorageLocation" only support a single string ID. Consider the tag name is the same, it's causing confusion while doing the interface and data aggregation design.

andreb1972 commented 5 years ago

I had a look at this, and you are correct - the naming of the existing ResourceLocationTypes does conflict with the new OperationalLocation. In each of the requirement elements we have:

PersonnelRequirement = OperationalLocation EquipmentRequirement=OperationalLocation PhysicalAssetRequirement=PhysicalLocation MaterialRequirement =StorageLocation

Each of these Requirement elements should now also have an element representing the OperationalLocationType.

As the OperationalLocation can exist on its own i.e. it has transactions etc. it should be referenced by ID, rather than a nested object... something like EquipmentID:

<xsd:complexType name="OpEquipmentRequirementType">
        <xsd:sequence>
                        ...
            <xsd:element name="EquipmentID" type="EquipmentIDType" minOccurs="0" maxOccurs="unbounded"/>
            <xsd:element name="OperationalLocationID" type="OperationalLocationIDType" minOccurs="0" maxOccurs="unbounded"/>
                        ... 
        </xsd:sequence>
    </xsd:complexType>

If the OperationalLocation is somewhat dynamic, as in the resources sector, then could be an issue, as the operational location is defined at the time of scheduling/actualizing. In this case a the OperationalLocation and the SegmentRequirement would need to be included in the same payload, so perhaps an OperationsEvent message construct would be required.

Alternatively, the OperationalLocation could be included as a nested type, which would allow a reference by ID or the entire OperationalLocation could be described within the Requirement element. The issue then would be naming, so as to maintain backward compatibility"

<xsd:complexType name="OpEquipmentRequirementType">
        <xsd:sequence>
                        ...
                  <xsd:element name="OperationalLocation" type="OperationalLocationType" minOccurs="0" maxOccurs="unbounded"/>
                        contradicts
                           <xsd:element name="OperationalLocation" type="ResourceLocationType" minOccurs="0"/>
                        ... 

        </xsd:sequence>
    </xsd:complexType>

This approach would require some restructure of the XSD's, to make the OperationallocationType a common type

vitalJP commented 4 years ago

Adding additional information:

Background

complexType name = "MaterialSubLotType", element name ="StorageLocation"; Change type = "StorageHierarchyScopeType" to "ResourceLocationType" to align with updated ISA-95 Part 2 Material SubLot Object.

Impacted Types

B2MML - Material.xsd

Supporting Document

ISA-950002 Section 5.7.6 and 5.7.8

Dennis-Brandl commented 4 years ago

The proposal is to: 1) Move the OperationalLocationType to the B2MML_Common file. 2) Remove StorageHierarchyScopeType and replace with ResourceLocationType 3) Add a in ResourceLocationType to allow selection of either: a) A Location ID, which is a reference to an OperationalLocation that is previously defined. b) A Location of type OperationaLocationType, so that an entire OperationalLocation can be included in the ResourceLocationType c) Add the following two codetypes to ResourceLocationType1Type: OperationalLocation ID and Person (to allow a resource to be associated with a person, such as a tool's location is with a specific person). 

<xsd:complexType name="ResourceLocationType1Type">
    <xsd:simpleContent>
        <xsd:restriction base="CodeType">
            <xsd:enumeration value="Operational Location ID"/>
            <xsd:enumeration value="Operational Location"/>
            <xsd:enumeration value="Person"/>
            <xsd:enumeration value="Equipment"/>
            <xsd:enumeration value="Physical Asset"/>
            <xsd:enumeration value="Description"/>
            <xsd:enumeration value="Other"/>
        </xsd:restriction>
    </xsd:simpleContent>
</xsd:complexType>
<!--     -->    
<xsd:complexType name="ResourceLocationTypeType">
    <xsd:annotation> 
        <xsd:documentation>

Indicates whether the storage location attribute refers to an operational location, equipment or physical asset object, or contains a description of the storage location. Mandatory where a storage location is specified. Defined values are

JoeDo commented 4 years ago

Confirmed that (1), (2), and (3) referenced above have been made in the January-2020-Sprint branch. I'll circle back and Close this issue after the changes have been merged into Master.

Dennis-Brandl commented 4 years ago

To be added in the soon to be released version. Closed issue.