B2MML Technical Q&A

Is there a reason why the Quantity and Value elements which seem to be numerical, include a data type element and a string value element, instead of an xsd:decimal or xsd:double?

The value associated with Quantity and Value has given us some problems. XSD does not seem defined to allow the definition of the type of element in the document itself (say, through some meta-data) instead of for all documents. While the value of Quantity will almost always be numeric, it may not always be decimal. The value of a Value may have even more flexibility, ranging from enumerations to actual strings. We felt that restricting the type of these elements would restrict the use of the schemas. But, since the type of the Quality and Value is defined in the “DataType” element, then a XSLT can use that element value to interpret the ValueString and QuantityString. No conversion is necessary for display purposes.

What is the difference between the "ValueType" and "QuantityType", and why do many types include both?

A QuantityType indicates the quantity of a resource or capability definition (eg: 15 KG).

The ValueType is used to identify a property of a resource, the property might also defined a subclass of the resource (eg: Property of OperatorType with values of Master, Apprentice, and Trainee).

While you could define the quantity as a property, the quantity has a lot of importance in capability/capacity definitions, and is almost always included. It was defined as a separate element to allow for this importance.

Why is QuantityType not a single element, but is unbounded?

There are classes of industries that actually have multiple quantities recorded for a material. This is usually called a “catch weight”. For example, it may include a count, such as how many lobsters were caught and a total weight of all lobsters caught. It is up to the applications to ensure that the multiple quantities are consistent.

Shouldn’t there be "sample documents" to help people understand a schema?

Yes, want to write some? The small group doing the generation of the schemas and documentation didn’t have the time to generate test case documents and documentation. Any submissions are welcome.

Why doesn’t the "standard" schema include inline documentation on each type/element using the <xsd:annotation> & <xsd:documentation> tags?

The documentation should always be available with the schemas, or at least easily available to WBF members. In addition a) many of the tools used to create and test the schemas do not correctly support the annotation and documentation tags (the comments were easy to “lose” during use of the tools), and b) the schemas were actually harder to read with the embedded documentation since not all tools highlighted the “important” parts and pagination and indentation was impossible to control.

The schemas use English words in enumeration strings (e.g. “Enterprise”, “Site”, “Area). This is not “localized” for different languages.

Yes, this is a problem. But it is an XML issue and an ANSI/ISA95 issue. The XSD keywords are English, and the words defined in ANSI/ISA95 are English. Because this standard is designed to support integration, even across countries, a common language for tags and enumerations is required. Otherwise a company with headquarters in Germany could not use XML, the ISA95 standard, or the schemas to communicate. This will probably be acceptable (even if not desirable), much the same way that all international air traffic control is in English, independent of the country of origin or landing.

In general, material requirements may include an acceptable tolerance range in addition to a distinct target quantity, how is this handled?

These can easily be handled using properties. The property model is used to support the industry and even company specific needs, such as tolerances.

Standard XML representations of Unit Of Measure (UOM) conversions (with user-definable units of measure) might be useful. Might include from/to/multiplier, etc.

The UOM issue is bigger then S95, this is something that EbXML or OAG will have to address. If not, there is an ISO standard that defines all “international” UOM, but that might not work in the USA (and the few other countries notusing metric). Basically the agreeing parties will need to agree on the acceptable units of measure.

A generalized mechanism for associating/recording comments, exceptions, or deviations with a production or equipment entity might be useful.

These can be properties of the equipment, or in the multiple descriptions of the elements. If the comments need to be exchanged, because they are recorded by one system and consumed by another, then you should create a specific property called “Comment”, “Deviation”, or “Exception:, with the understanding of what it means, who creates it and who consumes it.

How would a "material movement" request or "material movement" update be modeled in the current schemas?

One of the first phases in any business to manufacturing integration project is the identification of process segments. Identifying process segments requires an understanding of the business processes within the company and the general structure of the manufacturing processes. Not all process segments need to relate to production, there are at least three general types of process segments:

Production segments – those relating to conversion of raw or intermediate materials into intermediate materials or final products.

Movement segments – those relating to movement of materials and keeping track of material and product locations.

Inspection segments – those relating to confirming or testing quality and suitability of materials and products.

What is the difference between ProcessSegmentID and ProductSegmentID on the SegmentRequirementType?

This reflects the S95 standard where it says that a segment requirement corresponds to either a product segment or a process segment. It many cases it may not matter. A segment request should define resources and parameters already defined in process segments or product segments. However, in general in order to match the spirit of the ANSI/ISA95 standard, this should always be a product segment ID and the product segment should refer to a process segment.

What should the ProductionSchedule and the ProductionRequest should be mapped to?

(My interpretation is that the ProductionSchedule was the Schedule and the ProductionRequest is the Product to be built in the Schedule. A colleague of mine suggested that the ProductionSchedule was a placeholder to group a number of schedules stored in the 1 to n number of ProductionRequests, using the ProductProductionRuleID as the key for the product that was to be built. I would like to know what the intended model is. On a related note, I would like to know what the intended usage of the ProductProductionRuleID is.)

Since the schemas define an agreement between scheduling and manufacturing it could be interpreted either way, as long as it is consistent on both sides. I think the agreement depends on the complexity of manufacturing that is "hidden" from the business. If a lot of the details of manufacturing are hidden, and the scheduling just says what to make (products) and when they are needed, then I think the first interpretation is the one to follow, the ProductionSchedule defines the overall schedule and each ProductRequest defines a specific product. There is probably not product segment routing, and maybe only one product segment.

However, if the scheduling system has a lot of visibility into manufacturing and schedules specific intermediates or resources, then the ProductionSchedule is just a container and the specific information for each product (timing, etc...) is contained in the ProductRequest. In this case there may be specific segment dependencies that have to be meet and maybe specific resources for each specific product (e.g. which equipment to use).

The ProductProductionRuleID identifies, to manufacturing, what to build. It is the closest the XML schemas have to a product ID. The reason it is not a product ID is because there can often be many ways to make the same product. For example, some recipes may be seasonal and based on ingredient availability. Other Recipes are determined by whether they are small, medium, or large production runs. Different plants can use different versions of a recipe, so the choice of recipe depends on the plant that is producing the batch. The ProductProductionRuleID is used instead to a ProductID to allow for those cases where the scheduling system makes the determination and not the plant. Usually if there is only one way to make the product, or the plant makes the decision on specific recipes (or assembly rules), then the ProductProductionRuleID is the product ID.

What is the “Location” element used for?

The “Location” element indicates the scope of the enclosed element. This scope relates to the “Equipment Hierarchy” defined in ANSI/ISA95. Usually this will indicate that the element is scoped to the enterprise, a site, or an area. However, since the hierarchy can be expanded and collapsed, it can really refer to any company designation. The Location element is recursive, again to match the equipment hierarchy. The recursion means that the entire hierarchy level can be exchanged, or just the level that is important.

What is the ProductionParameterType supposed to be used for?

This can be used to send information or targets to production, such as target pH or target color. It may also send data that is difficult to indicate any other way, such as which packing material to use (based on government regulations at the receiving country). It is really an escape hatch for things that don't easily fit elsewhere. Someone could do their entire interface using parameters, in fact that is what many systems today use, but the ability to use the other S95 elements should reduce the use of parameters.