Análisis por fuentes de ingreso de la frecuencia y relación de las variables estudiadas.

Product requirements

The objective of Query 1, as discussed in the methodology chapter, is to determine whether a machine meets a product’s requirements. The route that the general query would need to follow has already been illustrated and discussed in (ref Fig no 14 from methodology). In order to test whether the query would be able to deliver the results required, the contextual information available regarding product components and machine components was instantiated into the Skill model. In this example, due to the objective of the process being to bolt the oil pan to the engine block, the number associated with the number of bolts in the product is compared with the number of bolt heads in the machine. This is so that, if and when a new product variant was introduced with a different number of bolts, the capability of the machine could be checked with respect to the new requirement. This information could be enriched with process parameters such as the number of turns and the torque, due to the extensible nature of the model. The fully instantiated model is illustrated in Figure 4-3 as a screenshot of Protégé.

107

Figure 4-2 High level view of additional concepts added to model engine assembly station

Product Domain ProductFamily ProductVariant hasProductVariant 1..1 1..* Assembly 1..* hasAssembly 1..* ProductComponent 1..* 1..* Liaison hasProductComponentQuantity : integer hasProductComponentID : string contains 1..* hasLiaisonQuantity : integer hasLiaison 1..* 1..* 1..* Product 1..1 ScrewFitLiaison BoltHeads hasBoltHeadDiameter : integer hasBoldHeadQuantity : integer Skill Model SkillContext SkillAction

requiresSkillAction (via ProcessDomain) hasSkillContext Skill ResourceComponent hasComponentID : string ControlComponent NutRunner NonControlComponent NutRunner_Head State hasStateNo : integer hasStateID : string hasStateDescription : string hasState 1..* 1..1 Resource Domain isSkillContext ElementOf 1..1 1..* isSkillAction Element of 1..1 1..* BoltTightener executesSkillAction 1..1 1..* hasSkillContext 1..1 0..1 ProcessComponent NutRunningSequence

108

Figure 4-3 Protégé screenshot showing how the SWRL rules infer that the “Bolt-OilPan-EngineBlock” liaison infer the requirement of BoltTightener SkillAction and NutRunning Process (highlighted in yellow)

Although the generic description of Query 1 in the methodology chapter was focused on ascertaining Product-Resource capability consistency at a high level. This case study explores the expressive power of ontologies and data manipulation in more detail. As such, a query was created that not only checked whether the Resource was generally capable i.e. that the BoltTightening action existed, but also whether the contextual aspect of the skill was consistent i.e. does the Resource have a sufficient number of NutRunner_Heads to realise the number of ScrewFitLiaisons. As such, the query as illustrated in Figure 4-4 was created and the results are presented here also. Note that the structure of the query follows largely the same structure with respect to the routing as compared to the generic version of Query 1 given in chapter 3. However, the key difference is a simple mathematical calculation to determine the difference in the number of NutRunner_Heads and

ScrewFitLiaisons. As the difference is “0” it is observed that no difference between

109

Figure 4-4 SPARQL query and results for Query 1

The results from Query 1 show how it is possible to link product data features with the capabilities of resources to provide a mechanism for reconfiguration should requirements or capabilities change. However, there are several shortcomings of the proposed approach. One of the major issues is whether or not the user, who in this case would most likely be the product designer, has awareness of the knowledge available in the ontology. This would require that either, a considerable training exercise to communicate what can be queried is undertaken, or that the user’s engineering tool is connected to the ontology. As a result, when the relevant inconsistency is identified, the user is notified from within the engineering environment. This would of course require further software development and the question would be raised as to whether the additional human resources required to maintain this connection would outweigh the benefits of seamless data model integration. In addition, depending on the nature of the skill being assessed, the resultant processing will be different. For example, in the case of a load limit of a ControlComponent e.g. a robot, any value of mass of the product less than the limit would necessitate a result that would indicate to the user that the requirements were consistent with the capabilities. In another case, an assessment would need to be made based on a range. For example, a pneumatic gripper has an upper and lower bound for the size of component that it can handle. Provided a given ProductComponent was within the range, the user could be

110

notified that capabilities/skills meet requirements. Therefore, a beneficial extension of the query would be to extend the ontology with additional rules that check the type of skill being assessed e.g. limit, range, difference etc. and then consider the result accordingly. In some sense, this was addressed in (Järvenpää, 2012) however the work was more focused on aggregating and matching capabilities rather than a detailed analysis of the numerical values associated with them.

Finally, it would be of benefit to the use if the numerical result generated by the query was pre-processed before printing. An example for the pre-processing that could be achieved for Query 1 is presented in Table 4-1. This post-processing and even the query itself does not need to exist within Protégé which is a relatively limiting environment. The JENA framework provides much more flexibility and due to its Java implementation would allow the more complex data processing to be carried out more readily.

Table 4-1 Pre-processing example for Query 1

Query result (hasLiaisonQuantity – hasBoltHeadQuantity)

Printed result Interpretation

0 TRUE the difference in the number of engine oil pan

bolts and nut runner heads equals zero

Negative number EXCESS SKILL

there are more nut runner heads on the machine than there are engine oil pan bolts. This could allow the designer to question design validity i.e. there may be insufficient bolts to hold the oil pan. On the other hand appropriate preparations could be made to modify the machine triggering an engineering change.

Positive number EXCESS

PRODUCT

there are fewer nut runner heads on the machine than there are engine oil pan bolts. Again, this allows the designer to question the design

Null NULL

PRODUCT

the required data does not exist in the product domain

Null NULL

RESOURCE

the required data does not exist in the resource domain

Null FALSE data does not exist in the product or resource

domain

It is important to note that the “EXCESS SKILL” result that could be generated does not necessarily represent a design flaw, in fact it could simply be due to overcapacity within the system for flexibility reasons. However, the ability to know that there is a difference is simply an exchange of knowledge between the Resource domain and the Product domain.

111

With this knowledge in hand can allow the relevant stakeholders to make an informed decision where before there would have been a lack of transparency that a decision needed to be made at all.