Modelación de la dispersión por el software ISCST3

Although there is no model representing detailed product geometry, there are certain features of a ProductComponent that can be represented through the ComponentFeature

class. The use of feature models within the Product domain has also been included in the works of Usman et al., Lanz, Kim, and Demoly (Usman et al., 2013, Lanz, 2010, Kim et al., 2006, Demoly et al., 2010, Technology, 2005). The author has taken inspiration from

71

the model presented in Lanz (Lanz, 2010) which decomposes features into Geometric and NonGeometric. In this work, the ComponentFeature has two subclasses that are

QualitativeFeature and QuantitativeFeature. The former concerns those features that cannot be described through integers. These include colours and materials. These concepts have been defined as classes rather than as instances of the superclass QualitativeFeature

as there is knowledge that needs to be represented at this level to support the selection of appropriate manufacturing resources. For example, a component within a fuel cell is the gas diffusion layer (GDL). This component is made from carbon paper which is a porous material. Therefore, the author envisions a material ontology e.g. Ashino and Fujita (Ashino and Fujita, 2006) that could extend the Product domain and enhance the Skill statement i.e. increasing the breadth of information available to the Skill model to ensure that the appropriate resources can be selected. Upon selection of appropriate equipment/resources, the knowledge associated with the selection process could be stored explicitly as a triple. This could then be used to infer appropriate resources when the same material is used in a different context.

The QuantitativeFeature is modelled in a different way to QualitativeFeature to exploit the fact that this type of feature can be expressed through integers. The data type property of OWL is used to model the QuantitativeFeature and this class can quite easily be extended by adding new properties. The author has elected not to represent these properties as classes because there is little else that can be gleaned or inferred from this information. As an instance of ProductComponent is a physical thing it goes without saying that it will possess some physical attributes.

There is no use case that the author has been able to identify (within the context of assembly automation) that would lend itself to infer, for example, that a robot will need to lift an object of mass. Rather, it is the value of the mass associated with the object that is important and this cannot be captured through the use of a class. If the ontology was to be extended and fully align with the definition of product presented at the head of this section, then there may well be a need to transform the data properties associated with representing

QuantitativeFeature to classes. This is because non-tangible products will not have physical attributes e.g. a mobile phone app. This would require an extension of the

ProductComponent class to represent tangible/physical and non-tangible components. In this case it could be useful to infer that a component does not have a mass associated with it and therefore there is no need to make inferences concerning it from physical parts of the

72

Resource domain. It may well be necessary to include this idea in a future, revised version of the ontology, but it is not within the scope of this work.

Returning to the use of integers as a means for expressing the quantitative information associated with product components, this can be used to check whether a resource is capable of handling the given component. Functions within SPARQL enable the use of simple mathematical calculations and so ultimately a result can be presented to the user highlighting useful information based on the quantitative difference between two values. Depending on the nature of the skill being assessed the result processing will be different. For example, in the case of a weight carrying limit of a machine component, any value of weight of the product less than the limit would result in a positive result. In other cases an assessment would need to be made based on a range. For example, a pneumatic gripper will have an upper and lower value for the size of component it can grip. In this case, provided the product component is within this range, this would produce a positive results. Negative results i.e. indications that the resource bounds are inconsistent with product requirements would highlight how and where changes need to be made either within the Product domain or the Resource domain.

The author has carried out some experiments using Product and Manufacturing Information (PMI) which is supported by several CAD formats (ISO 10303 STEP, ISO 14306:2012 JT) (Chinnathai et al., 2017). PMI is essentially a method to annotate 3D CAD models, usually with geometric dimensioning and tolerance (GD&T) information that has conventionally existed in 2D documents. Maintaining a common model rather than a document through the lifecycle, irrespective of whether this is of the product or the manufacturing system, aligns with the broader model-based, data-driven approach to engineering.

An additional use of PMI is the annotation of key information e.g. annotating the gripping locations of a component. This information can be extracted by parsing the source file and then imported into the relevant data type property of the given component, traceable through unique component identification numbers. As a consequence of this information being present in the ontology, a query can be written to identify whether resources (via the Skill model) are appropriately configured for the product domain’s requirements. Rather than having to process the source CAD for this information, it can be directly gleaned from the ontology as it is explicitly declared. As the ontological model evolves within the business, it is envisioned that annotations of this nature i.e. those associated with process, would become a best practice within industry resulting in the development of standards for how such source CAD should be marked up.

73

An example of the envisioned workflow described in this paragraph is presented in Figure 3-4. This is taken from a previous work of the author in an attempt to demonstrate how the

QuantitativeFeature class could be used in a practical way. One of the shortcomings is to have the knowledge that such information can be queried in the first place. In other words, the user may not know that such information exists within the ontology. Although beyond the scope of this work, it is important to also consider how the ontology associated with the ontology is maintained i.e. how to know what is known? This cannot be considered to be a meta-ontology because that would exist at a higher level of abstraction.

Figure 3-4 Workflow diagram showing how data annotated through PMI can enable effective communication and design verification. Particularly within the context of design changes, there is the potential to highlight

(almost instantaneously) what aspects of the Resource domain may need modifications and at what level (parameters, logic, structure).