Introduction

‘Knowledge based engineering (KBE) represents an evolutionary step in computer-aided engineering (CAE) and is an engineering method that represents a merging of object-oriented programming (OOP), artificial intelligence (AI), and computer-aided design (CAD) technologies, giving benefit to customised or variant design automation solutions’ (Chapman and Pinfold, 2001). Traditionally, in design engineering the output of the preliminary and the detailed design is in the form of a geometric CAD model directly created from requirements. KBE as a method captures product and process-based data and helps in building a virtual prototype in a system which encapsulates rules, requirements, product attributes, features, and rationale for building a geometric model along with downstream processes such as material selection for static and dynamic analysis, and manufacturing capability enabling design automation. A system implementation of KBE can be defined as ‘the use of dedicated software language tools in order to capture and re-use product and process engineering knowledge in a convenient and maintainable fashion’ (Cooper and LaRocca, 2007). A system implementing KBE is dynamic such that it offers true engineering automation including application development, geometric modelling, application deployment, and tools integration (Egging et al., 2000). Investigation of existing KBE methodologies such as knowledge nurture for optimal multidisciplinary analysis and design (KNOMAD) and methodology and tools oriented to knowledge-based engineering applications (MOKA) has revealed some of the shortcomings in the form of neutral representation techniques of a process-based model to enable design process automation. This paper discusses informal process modelling and the formal representation of the informal model. The first part of the paper will discuss various informal process modelling methods such as integrated definition methods (IDEF) suite, design structure matrix (DSM), Petrinet, signposting, role activity diagram (RAD) to capture process-based data along with semiformal modelling methods and languages such as unified modelling language (UML) and systems modelling language (SysML) to capture and represent design features. The next part will discuss existing formal representation techniques such as process specification language (PSL) and IDEF5 based on a particular logic such that an informal or semiformal model can then be mapped onto a suitable formal technique. The formal representation framework will have well-defined syntax, axioms, and semantics and will be compliant with international standards for product model definition and process exchange (Grüninger and Menzel, 2003; Pouchard et al., 2005).

Background of KBE methodologies

There are various methodologies for implementing KBE. A methodology termed as KOMPRESSA with its diagrammatic ways of capturing knowledge in the form of a component diagram was initiated for smaller KBE applications (Bancroft et al., 2000; Chapman et al., 2007). In knowledge capture methodology (KCM), capturing and structuring of knowledge is performed from a designer’s point of view. It breaks down the product knowledge into parts, assemblies, features, and the relationships between the geometric features and the components to formulate product semantics (Terpenny et al., 2000; Chapman et al., 2007). Both KOMPRESSA and KCM were targeted for product modelling and automation. KNOMAD as a methodology laid emphasis on activity diagrams for processes and representation of multidisciplinary knowledge including design and manufacturing (Verhagen et al., 2012). MOKA (Skarka, 2007) as a methodology was initiated for larger applications. It encapsulated both product and process based modelling. It lays emphasis on two stages of the KBE life cycle as shown in Fig. 1. First it captures knowledge in an informal manner in the form of ICARE (illustration, constraints, activities, rules, and entities) and then converts it to a formal manner. MOKA utilised UML notation and extended it to develop MOKA modelling language (MML) as a means of producing a formal knowledge model (Stokes, 2001; Chapman et al., 2007). In spite of strengths in managing engineering knowledge throughout the product life cycle MOKA was revealed to have a few shortcomings, e.g., MML did not comply with Object Modelling Group (OMG) requirements (Abdullah et al., 2005); the formal knowledge model could not be mapped to a KBE system to assist in process automation (Prasad, 2006; Chapman et al., 2007).

Fig. 1
figure 1

MOKA methodology in KBE life cycle (Reprinted from (Lohith et al., 2013), Copyright 2013, with permission from CSREA)

Full size image

This piece of research initially intends to bridge this gap in correct syntactical and semantic mapping of an informal process-based model capturing all the necessary design process features to a neutral formal representation framework. The subsequent step will focus on recommendation of neutral formal representation methods based on discussion and experimentation, which should then be able to achieve the purpose of design process automation through a query layer.

Process modelling for design automation using KBE

There are many methods of capturing and representing knowledge for a KBE system. The approach that will be followed as part of this research aligns its concepts to object process methodology (OPM) whose feature is that it breaks down the knowledge into three types of entities: objects, processes, and states with objects and processes being higher level building blocks (Dori, 2002). OPM is also recognized as an International Standards Organization (ISO) standard in the form of ISO/PRF PAS 19450 (Dori, 2002).

The OPM methodology keeps systems as the viewpoint and enables merger of object-oriented and process-oriented modelling. The states are indicated by links, which exist as both structural and procedural links representing the static and dynamic behaviour of objects in a system. OPM allows for features such as inheritance, and aggregation of objects and their properties. It offers object-process language (OPL) and object-process diagram (OPD) as a means of formal representation of the informal representation (Dori et al., 2003; 2010). The OPL enables java code generation and automatic generation of UML diagrams and natural text output. Pertaining to this research, the formal representation of the entire process model should enable code generation for fulfilling the purpose of process automation.

According to the National Institute of Standards and Technology (NIST), a ‘process model for product realisation is defined as a computer-interpretable representation of human and machine activities and their interactions required for realisation of a product. This may include early concept and configuration design activities, detailed design, prototyping, testing, tooling, fabrication, assembly and other activities within the scope of the realisation process’ (Lyons et al., 1995). There are many governing factors for selecting a process modelling technique. Some of the existing purposes are task scheduling, resource allocation, cost-quality-time trade-offs, and process improvement in terms of design-to-market lead time (Smith and Morrow, 1999).

In order for a process-based model to be interpreted by KBE systems to achieve automation of processes, the process modelling technique should broadly satisfy the following functions:

  1. (1)

    Inter-dependencies between tasks to enable flow of information such as inputs, enablers, mechanisms into multiple tasks which will enable dependency backtracking in the formal representation in the system.

  2. (2)

    Design process decomposition to the highest level of abstraction of artefacts, which includes all features such as design rationale, attributes of a process and product with states and behaviour along with resources and requirements. This also includes control mechanisms and enablers for a process for failure modes through existing rules, constraints and logic for successful process adherence and completion. These may be in the form of geometrical tolerances, manufacturing constraints or material selection information for a design process.

  3. (3)

    Object-process relationship by breakdown of the knowledge content primarily in the form of objects and if possible simultaneous representation of governing entire processes altering the state and behaviour of the object.

  4. (4)

    Computational capability indicating that all aspects of the process model can be mapped to a software system or formally stored in a system with well-defined syntax and axioms which can then be queried to achieve process automation (Chapman and Pinfold, 1999; 2001; Egging et al., 2000; Prasad, 2006; Chapman et al., 2007; Cooper and LaRocca, 2007; Skarka, 2007; Lohith et al., 2013).

The process modelling techniques discussed will be analysed for various functions as described below:

  1. (a)

    Task scheduling and sequential planning;

  2. (b)

    Cost/Time/Quality trade-off;

  3. (c)

    Inter-dependencies between tasks;

  4. (d)

    Design process decomposition;

  5. (e)

    Object-process relationship;

  6. (f)

    Computational capability.

Thus, techniques which satisfy the stated criteria out of all described functions will be carried forward for formal representation.

Informal process modelling techniques

Techniques such as design structure matrix (DSM), work transformation matrix (WTM), IDEF suite, Petrinet, event process chain diagram (EPC), signposting, RAD, UML/SysML, and business process modelling notation (BPMN) will be discussed in this section. A process modelling technique based on a matrix structure for sequencing and scheduling is a DSM (Eppinger et al., 1994). DSM lays emphasis on activity dependencies and can focus on complicated processes with more than 100 tasks (Smith and Morrow, 1999). It helps in assessment of risks throughout the design process along with failure modes (Amigo et al., 2013). However, one of the limitations of DSM is the lack of ability to manage tasks within an iterative group. WTM is a process modelling method which helps in decomposition of a larger task into small processes (Smith and Eppinger, 1997). It is derived from DSM with a modification that the non-diagonal elements in the matrix are represented by re-work quantity. However, a major shortcoming of WTM modelling is the assumption of computation of re-work as a linear function of work from a previous iteration, which is not true in all cases. Both the techniques have strength in modelling interdependencies of tasks but fail to capture all of the necessary design decomposition features.

Process modelling techniques such as Petrinet and EPC fulfill the purpose of measurement of productivity of a process and work flow modelling (Amigo et al., 2013). Petrinet is based on nodes and arcs to represent information (Murata, 1989). One of the limitations of Petrinet is its inability to consider time as a process variable (Browning et al., 2006). Petrinet fails to capture contextual information although it can be used for modelling of interdependencies of tasks (Stacey et al., 2000). To capture contextual information, modifications can be made to Petrinet. For example, NIST researchers used modified Petrinet (MPN) in an object-oriented methodology to include additional information such as mechanisms and rules for governing failure modes along with resources in the form of people, machines, and tools to implement computer-aided concurrent engineering (CACE) (Lyons et al., 1995). Thus, MPN can be used to indicate inter-dependencies within a process along with design decomposition features. An EPC helps in generating tools for benchmarking along with documentation of design data (Browning, 2009; Amigo et al., 2013). EPC fails to capture design decomposition features, but MPN allows the capturing of design decomposition features.

A modelling method, initially for representing manufacturing systems, but which progressed to the design process is integrated definition for functional modelling (IDEF0) (Colquhoun et al., 1993; PUBS, 1993). It was derived from structured analysis and design technique (SADT). An IDEF0 model comprises of a set of activity boxes referred as ICOM (input, control, output, and mechanism). The top level box is the highest fidelity model and can be represented elaborately in more detail using lower fidelity models (Colquhoun et al., 1993; Gingele et al., 2002). The ICOM activity box for IDEF0 is illustrated in Fig. 2.

Fig. 2
figure 2

IDEF0 higher fidelity activity box with an example (Reprinted from (PUBS, 1993), Copyright 1993, with permission from Knowledge Based Systems, Inc.)

Full size image

Although IDEF0 was found to be a very detailed graphical representation of the processes (Al-Ahmari and Ridgway, 1999) with all the control parameters, it was considered to be time-consuming. A major shortcoming of the IDEF0 approach was its lack of consideration of time as a variable. IDEF1 was introduced after IDEF0 and was based on information modelling instead of IDEF0 functional modelling. It shows the relation between constraints and is based on entity relationships (Mayer, 1992; Lyons et al., 1995). IDEF1 lays emphasis on representing information based on a class of entities with attributes to define their behaviour (Lu et al., 1996). Thus, it can be used to model real world objects as well as information required to manage an enterprise. IDEF2 was introduced to address a major shortcoming of earlier IDEFX versions for their lack of inclusion of time. It was supposed to be dynamic but was not successfully implemented in commercial systems (Lyons et al., 1995). IDEF3 shows the relation and logical flow of activities within a process. It is referred to as a process description capture method with time-based behaviour of activities. Another advantage of IDEF3 was that it can show two views of the process, one termed process flow network (PFN) which lays emphasis on activity and the other object state transition network (OSTN) which allows an object—centered view (Plaia and Carrie, 1995; Knutilla et al., 1998). The IDEF3 process description method lays emphasis on the flow of junctions, which embeds the time varying behaviour of activities.

IDEF4 is an object-oriented design process description and broadly consists of two models—class and method sub-models with diagrams such as protocol, inheritance, and taxonomy diagrams which can be interlinked and sufficiently capture all intricate parts of a process (Mayer et al., 1992). The complete IDEF suite, however, adopts slightly different methods to capture process information, as illustrated. IDEF0 focusses on function modelling, IDEF1 focusses on information modelling, IDEF2 on simulation modelling, IDEF3 on detailed flow of junctions in a process flow, IDEF4 on object-oriented design, and IDEF5 on ontology-based description (Plaia and Carrie, 1995). IDEF4 will be discussed in detail in the next section to verify whether it satisfies the requirements for design process automation. IDEF5 will be discussed under ‘formal representation methods’.

A role activity diagram (RAD) enables a graphic view of the process with interactions between various processes. It allows an object-oriented view of the process with changes in behaviour of the object with activities (Aguilar-Savén, 2004). However, one of the limitations of RAD is its inability to decompose the high level processes to lower levels of process with precise details. RAD can be used to model workflows for improvement. RAD can be visualised through MS Visio (Shukla et al., 2014), but it captures high level aspects with activities assigned to roles for a particular system but does not capture design decomposition features as stated in the requirements for design automation.

A data flow diagram (DFD) shows the flow of process data and information graphically. It enables decomposition of the process to a lower level of detail (Aguilar-Savén, 2004) in contrast to RAD. It allows functional modelling and thus has conceptual similarities to IDEF0. However, it fails to capture all design decomposition features.

BPMN is an object-oriented modelling method and is a recognised standard of the OMG (Sharma et al., 2014). It includes swim-lanes to show the roles of actors in a system. In this way, it has similarities with the RAD. BPMN can be used to describe activities with the flow of information similar to RAD, unified modelling language (UML) activity diagram, and EPC. BPMN can be enhanced to show activities, events, decision nodes, and activity along with actors and roles. It can be used to model both functional and non-functional requirements (Heidari et al., 2013), and improve business processes in terms of lead time to market for products and in the visualisation of processes. However, it fails to capture all of the design decomposition features to enable design process automation.

The signposting model is a task-based modelling method. It is based on three core elements— tasks, states, and ‘signposting parameters’, offering three views—task level, process level, and the parameter level (Clarkson and Hamilton, 2000). Depending upon the confidence of the parameters, a relationship between tasks is constructed. Thus, it enables modelling of the interrelationships between tasks and can also be modelled as a DSM approach. Signposting is very useful for modelling uncertainty in the design process which is a critical feature (O’Donovan et al., 2003). It also offers inclusion of additional text information in its core constructs which can include requirements (Stacey et al., 2000). It allows for the capture of design decomposition features along with interdependencies. It is illustrated with the help of Fig. 3. Power and rigid body are tasks to be performed. Letters l, m, and h are low, medium, and high confidence rating of the parameters, respectively, such as blade-loads and engine power. After the total confidence of the task is performed based on these parameters, it is used to determine whether the task will be successfully completed. Thus, task status is derived from confidence mapping of parameters.

Fig. 3
figure 3

Using signposting to derive task status from confidence mapping of parameters (Reprinted from (Clarkson and Hamilton, 2000), Copyright 2000, with permission from Springer-Verlag London Ltd.)

Full size image

Semi-formal modelling methods and languages

As per the context of a formal representation of an informal process model to enable design automation, there exists a boundary between informal and formal modelling. All the informal process modelling techniques can be used to capture process-based data in a human readable form. Similarly, languages like UML and SysML can be used both to capture data and represent it formally using tools. Alternatively, any informal method of capturing data can be converted into XML serialisation, which then becomes a formal representation.

‘UML is a language for specifying, visualizing, constructing, and documenting the artefacts of software systems, as well as for business modelling and other non-software systems’ (Aguilar-Savén, 2004). UML utilises object-oriented techniques and utilizes nine types of diagrams to model and exhibit information. These are: class, object, state-chart, activity, sequence, collaboration, use-case, component, and deployment diagrams (Aguilar-Savén, 2004). UML is considered as an international standard as specified by the OMG in the form of ISO/IEC 19501 (Weilkiens, 2007).

There are three main modelling viewpoints in UML: use-case, static, and dynamic models (Kim et al., 2003). The use-case models define the generic processes that the system should handle. They provide a graphical description, and although offer a very brief description, they are similar in principle to IDEF as a means of communication through graphical display. The static view includes class diagrams, which enable a static view in terms of objects and relationships within objects of a class. The dynamic modelling view enables communication between the system objects. For dynamic modelling UML utilises four types of diagram: state, sequence, collaboration, and activity diagrams (Kim et al., 2003). UML can be used as an informal modelling technique and then maps to a formal representation through a final diagrammatic layer known as implementation diagrams. SysML was derived from UML for the modelling of complex systems involving real life objects (Weilkiens, 2007). SysML inherits a lot of properties from UML with the addition of two types of diagram: requirement and parametric diagrams. It has minor variations on UML. Blocks in SysML replace UML classes. The class diagram in UML is replaced by a block definition diagram in SysML and the composite structure diagram in UML is replaced by an internal block diagram in SysML (Weilkiens, 2007). A very important point about SysML is that the models can be exchanged via a neutral format in the form of ISO AP233 (discussed later). Both UML and SysML with multiple viewpoints can exhibit and represent design decomposition features along with interdependencies of tasks.

IDEF4 as a derivation of IDEF features but with a focus on object-oriented technique is similar to UML in terms of layering and process views. Both are object-oriented modelling techniques which are necessary for capturing processes and representing in a neutral format for process automation. ‘IDEF4 is an object-oriented design method for developing component-based client server systems. It has been designed to support smooth transition from the application domain and requirements analysis models to the design and to actual source code generation’ (Mayer et al., 1992). IDEF4 provides three layers: system design, application design, and low-level design. Thus, it decomposes design into higher level of abstraction. Along with the three design models, IDEF4 includes a design rationale component. In IDEF4, symbols such as O, R, L, M, A, and E are used to denote objects, relations, links, methods, attributes, and events, respectively (Mayer et al., 1992). Thus, its concepts become similar to UML by focusing on object-oriented modelling and by providing multiple layers of the design process. However, the design rationale component in IDEF4 is an additional feature and provides the designer with a wider view of the design data. This makes IDEF4 suitable for capturing all of the design decomposition features required for process automation. It also enables inter-dependencies between tasks along with illustrating changes in the state of an object with governing processes propagating throughout the model with object-oriented modelling.

Comparative analysis of informal and semiformal process modelling methods and languages

As stated earlier, the majority of process modelling techniques for knowledge acquisition or capturing can be visualized or edited with the help of existing tools. Some examples are—use of SIMAN/ARENA tool for simulation of IDEF0 (Al-Ahmari and Ridgway, 1999), ProCAP for IDEF3 (Grüninger, 2009), and CAM for construction and visualisation of signposting (Wynn et al., 2010). Thus, computational capability will be excluded from the criteria in the analysis table because any process-based method of capture can be converted into XML syntax and stored in a system with a formal representation. The other three criteria, i.e., inter-dependencies between tasks, design process decomposition, and object-process relationship, will be the most important functions in evaluating whether a process model can broadly capture enough information which when mapped onto a formal representation can achieve process automation. The analysis is shown in Table 1.

Table 1 Analysis of informal and semiformal process modelling methods and languages for capturing knowledge to enable design process automation
Full size table

Formal modelling and representation techniques

Process models can be shared across multiple domains using different representation techniques, but this may have problems due to syntax, semantics, and axioms. The objective of the following discussion is to discuss and narrow down a few existing neutral formal representation techniques of the informal model in terms of these issues that should help integration with multiple platforms. The next step would be running a query on the formal representation of the informal model, which will lead to an automation process from the neutral representation using KBE. This query stage will not be discussed here.

There are many existing process representations. Some of them are the knowledge interchange format (KIF), process specification language (PSL), standard for the exchange of product model data (STEP as ISO 10303), and IDEF5 (Knutilla et al., 1998). PSL and IDEF5 are ontology-based representations. Some of the other ontology-based representations are common plan representation (CPR), workflow process definition language (WPDL), and planning domain definition language (PDDL). An ontology-based approach helps formalise the concepts and provides axioms as a formal means of constraining the meaning of the concepts in the language. Ontology is defined as the taxonomy of concepts and their definitions supported by a logical theory. Ontology defines a set of terms, entities and objects, classes and relationships along with formal definitions and axioms to constrain the meaning of terms (Pouchard et al., 2000). Thus, ontology enables interoperability and re-usability of the data using common semantics of modelled information. The ontologies for WPDL and PDDL do provide common semantics but are unable to provide axioms as a formal means of maintaining the semantics in the language (Grüninger, 2004). CPR (Pease, 1998) was initiated by the Defense Advanced Research Projects Agency (DARPA)-sponsored object model working group (OMWG). The basic concepts in CPR are action resource, actor, and objective with additional concepts such as plan and time point. However, CPR as a language does not enable representation of all design decomposition features through its ontology.

OWL is a web ontology language for creating and sharing ontologies on the World Wide Web and is regarded as a W3C recommendation (Bechhofer, 2009). OWL was developed as an extension of the resource description framework (RDF) and is derived from the DAML+OIL ontology. OWL has three variants: OWL Lite, OWL DL, and OWL Full. OWL Lite offers ease of implementation but offers the least of the OWL constructs. OWL DL is based on descriptive logic and offers more constructs and, more importantly, reasoning ability. OWL Full offers the most comprehensive constructs but deviates from reasoning ability and offers less ease of computation compared to OWL DL.

OWL-S, as a semantic markup for web services built on OWL, enables viewing of process with inputs, outputs, parameters, precondition, and results (Martin et al., 2004). Thus, selection of a particular OWL language is critical to represent design decomposition features (Bechhofer, 2009; W3C, 2012). RDF offers representation of information over the World Wide Web and is regarded as a W3C recommendation (Klyne and Carroll, 2004; Manola et al., 2004). The syntax of RDF describes information by breaking it into a triple form consisting of subject, object, and predicate. It also offers a formal graphical syntax in the form of an RDF Graph. The uniform resource identifier (URI) is an id which locates the address of the information over the web. The most critical aspect of RDF is that it uses XML-based syntax and schema (Klyne and Carroll, 2004).

KIF (Genesereth and Fikes, 1992) as a computer-oriented language was developed by the Interlingua Working Group of the DARPA knowledge sharing effort (Knutilla et al., 1998). It has formally defined semantics and breaks down knowledge into the form of objects with related attributes, processes, and functions. Thus, it aligns its methodology with OPM (Dori, 2002) and solves a major issue of pre-defined formal semantics. As stated earlier, OPM as ISO 19450 forms a part of ISO TC 184/SC5 (Dori, 2002). ISO TC 184 is managed by the ISO and covers ‘standardization in the field of industrial automation and integration concerning discrete part manufacturing and encompassing the applications of multiple technologies, i.e., information systems, machines and equipment and telecommunications’ (Pouchard et al., 2005).

To address the shortcoming of formulating common semantics and as a standard for the exchange of process specification, PSL was designed to facilitate correct and complete exchange of process information among manufacturing systems, such as scheduling, process modelling, process planning, production planning, simulation, project management, work flow, and business process re-engineering (Grüninger and Menzel, 2003). A major purpose of PSL was to enable interoperability of processes utilising different process models and process representations (Pouchard et al., 2005). PSL ontology is written in KIF format and forms ISO 18629 as an integral part of ISO TC 184 (Pouchard et al., 2005). PSL ontology is based on the first-order logic (Pouchard et al., 2000). Ontologies based on the first-order logic exhibit more expressiveness compared to descriptive logic and can run inference on the modelled information. PSL architecture consists of two parts: PSL core (foundation theories) and a set of extensions which can be mapped to EXPRESS schemas, UML and XML (Grüninger and Cutting-Decelle, 2000; Pouchard et al., 2005). PSL ontology is divided into the following four theories: core theories, duration and ordering theories, resource theories, and actor and agent theories (Grüninger, 2004). The PSL core provides four kinds of elements: object, activity, activity occurrence, and time point. To represent an activity-based description, PSL uses an activity role declaration (ARD) along with object declarations to describe objects being affected by the activities of the process (Grüninger and Menzel, 2003). The extensions allow for temporal relations between activities. Thus, the use of extensions with experimentation may be used for representing design decomposition features other than the core theory.

Another important ISO standard for product data exchange is STEP which is also regarded as ISO 10303 (Pratt, 2001). STEP is widely used in industry for representing and exchanging CAD data in a neutral format (Wenzel et al., 2011). STEP not only covers exchange of geometric information between different CAD formats but includes all product data throughout the life cycle (Lützenberger et al., 2012). STEP also uses EXPRESS as a modelling language to represent objects with related attributes and properties. STEP allows various formats for product data representation. Some examples are: ISO 10303-21 for text format, ISO 10303-28 for XML serialization, ISO 10303-22 for API, ISO 10303-41 for product identification and product configuration, and ISO 10303-46 for visual representation (Weilkiens, 2007). STEP, UML, parts library (PLIB), PSL, and manufacturing management data exchange (MANDATE) are examples of standardized exchange specifications for sharing of product and process information in industrial data (Chandrasegaran et al., 2013). As PSL deals with standardized syntax and semantic sharing of modelled information, it is consistent with ISO 10303, ISO 13584 (PLIB), and ISO 15531 (MANDATE) (Grüninger and Cutting-Decelle, 2000). STEP as ISO 10303, PSL as ISO 18629 along with MANDATE as ISO 15531 all comprise part of ISO TC 184/SC4.

SysML is a language that can be used for capturing and representing of process-based data for a complex system and can be viewed as a formal representation with the help of tools such as visual paradigm. SysML models, once created, can be exchanged via ISO AP 233 of STEP. Some of the important APs of STEP for consideration are AP233, AP213, Part49, and AP242 for formal storage of informal process models. Other individual formats such as rule interchange format (RIF) offer a neutral representation technique for rules, logic, and constraints. RIF offers a major advantage as it can be expressed in both XML-based syntax and more importantly can be extended to AP242 of STEP (Lützenberger et al., 2012). It can integrate with any platform or a CAD/PDM platform (Colombo et al., 2014). RuleML is another format for representing and sharing of rules on the World Wide Web. It is based upon XML, RDF, and OWL (Boley et al., 2005). Table 2 illustrates some of the available formal representation methods for some of the design decomposition features.

Table 2 Formal representation methods & techniques available for representing design decomposition features to enable design process automation
Full size table

IDEF5 is an ontology-based formal representation based on the basic concepts of IDEF suite. It is also written in KIF format and is based on the first-order logic (Perakath et al., 1994). The IDEF5 ontology language comprises two languages: the IDEF5 schematic language and the IDEF5 elaboration language. The schematic language is a graphical language that allows input of information through an automated ontology capture tool. The elaboration language is a structured text language with full expressive power of the first-order logic which allows input of information with detailed context (Perakath et al., 1994). It enables storage and representation of classes, kinds, and the first- and second-order relations as well through the ontology.

Mapping example: manual translation of an informal process to formal representation

An informal process capturing design aspects of fan blades has been derived and compiled in a process map illustrating inputs, enablers, parameters, requirements, rules and rationale, logic, behavior, and attributes along with the object primarily defined as a blade (Amoo, 2013). The process map captures all aspects of a process which IDEF4 captures but does not demonstrate the IDEF4 syntax in the form of a static, dynamic, and behavioural models in the present shape. The activities or events are broken down into three basic steps: blade geometry optimisation, dovetail attachment, and material selection as shown in Fig. 4 along with other design decomposition features. Fig. 5 illustrates the object box for the blade.

Fig. 4
figure 4

Example of an informal process capturing design aspects of a fan blade

Full size image
Fig. 5
figure 5

The object box as per IDEF4 methodology

Full size image

The formal representation framework is based on the discussion for representing process information along with other design decomposition features such as rules, logic, rationale, and requirements along with flow of information in the form of inputs and outputs. PSL ARD and object declaration syntax is explained as follows:

figure Graphic1

The object declaration can be a constant as shown in the first object declaration or a variable as shown in the next object declaration. The PSL syntax illustrating the flow of information along with extensions to illustrate parameters along with inputs and outputs is shown as follows, but only for blade geometry optimisation.

figure Graphic2
figure Graphic3

A few examples of the design rules to be followed during the blade geometry optimisation process are represented in RuleML (Boley et al., 2005) as follows: a 30% hollowing in a hollow fan blade results in about a 13%–16% decrease in torsional rigidity compared to a solid blade design (Amoo, 2013).

figure Graphic4

The rate of air intake varies and is dictated by factors such as airfoil geometry, angle of attack, air density, and the speed at which the airfoil moves through the air (Amoo, 2013).

figure Graphic5

The functional requirement as derived from the process for blade geometry optimisation is that the fan blades spin to accelerate a mass of air into the engine to generate thrust that propels the aircraft forward. Approximately 80% of the thrust produced by a modern jet engine is delivered by the fan. Fan blades also function to reduce total engine damage from the ingestion of various foreign objects such as birds by radially deflecting outward such objects rather than passing them through to the core parts of the engine (Amoo, 2013). The functional requirements of the process are captured and represented in a SysML requirement diagram as shown in Fig. 6. The underlying schema of the requirement (Fig. 6) is the textual requirement, identifier, source, kind, method, risk, and status. The model can be exchanged via AP233 of STEP.

Fig. 6
figure 6

SysML requirement diagram for representing requirements of the design aspects of the fan blades process

Full size image

Discussion

From the observations in Table 1, IDEF suite with main emphasis on IDEF4, UML/SysML, Modified Petrinet, and signposting satisfy the criteria as they successfully capture necessary design decomposition features on a higher level. Petrinet is considered to be one of the methods for process modelling and representation techniques. Although in its original form, it does not enable design decomposition to the required level for process automation, MPN can capture design decomposition features. However, it fails to utilise common semantics and uniformity in axioms (Grüninger and Menzel, 2003). This highly inhibits its use in a neutral representation for achieving automation.

Final selection of an informal model would be suggested after experimentation on formal representation of the informal model, as all of the necessary design decomposition features in the form of parameters, inputs and outputs, rationale, logic, rules, constraints, attributes, and requirements will need to be formally represented.

As seen with the help of the mapping example, PSL enables process representation with parameters, inputs, and outputs using core theory and extensions in the ontology. It will need more experimentation to illustrate representation of other design decomposition features such as constraints and attributes. RuleML (Boley et al., 2005) can be implemented to exhibit for textual rules and rationale. Similarly SysML can exhibit requirements. The framework will need integration for simultaneous application. PSL can be directly mapped to UML and hence to the SysML requirement diagram. RuleML and PSL can be integrated and shared via XML schemas. Similarly, all formats and languages to be experimented for representing other design decomposition features will need integration.

Conclusions

Methods and languages such as the IDEF suite, UML/SysML, and signposting informally capture most design decomposition features such as objects, processes with inputs, outputs along with resources, attributes, requirements, rules, logic, constraints, and rationale for design process automation. The formal representation framework as discussed with the help of the cited example aims to achieve process automation by representing all design decomposition features dynamically in a knowledge model and then running a query. To optimally recommend a formal representation framework, other formal representation methods such as STEP schemas for process representation (Part49), OWL-S, and IDEF5 will be experimented with use-case data. Functional markup language (FML), behaviour markup language (BML) for representing engineering process functionality and behaviour, and MathML for representing mathematical information will be experimented with the cited examples. Similarly, formats such as ReqIF (OMG, 2013) for exhibiting requirements will be compared to the SysML requirements diagram, RIF for rules will be compared to RuleML, and common logic interchange format (CLIF) (Pan and Liu, 2010; Sowa, 2011) and OWL DL for logic will be experimented on and compared with the examples cited. The comparison of various formal representation methods and successful integration upon testing and validation will yield a complete formal representation framework of the inferred informal knowledge model, which will enable process automation through a query layer.