·Home ·Table of Contents ·General

NDT Data Organisation and Flow Model G. Cavaccini, G. Borzacchiello, G. Caturano, A. Ciliberto Alenia Un'Azienda Finmeccanica Pomigliano d'Arco, Naples (Italy) Contact

ABSTRACT:

Within the frame of European Brite-Euram Research Programmes, an architecture for the implementation of NDT function has been defined in accordance with Unified Life-Cycle Engineering concepts, taking into account concurrent engineering aspects and total quality management around the design. Seen in this context, NDT/NDE is conceived as a function of a general process where a notable amount of information is busily shared, with a high level of interactivity, among all the teams involved in the quality, design, manufacturing and maintenance of the aeronautical product. The kernel of the architecture is a database-oriented tool, based on a NDT data organisation and flow model. The tool has both a static and dynamic feature. In fact, it organises all the data directly or indirectly related to NDT (component to be tested, inspection, analysis and visualisation procedures, acceptance criteria, hardware and software equipment, simulated, acquired and processed data, diagnosis), and manages the information flow from and to NDT function (interacting with NDT facilities and systems, analysis and rendering codes, expertise workstations, data archives, CAD/CAM/CAE stations). In order to support analysis codes and process automation, general mathematical and logical schemes for formulating and memorising some critical items (e.g. acceptance criteria, material properties, equipment characteristics, flaw features) are proposed. A prototypical implementation under Microsoft Access was realised and tested. Developments based on SQLServer and Web procedures are in progress, with the aim to actualise the remote-managing aspects of the architecture. Tests performed in on-line production and engineering environment proved the ability of the architecture in promoting standardisation, automation and concurrent engineering of NDT-related operations; increasing reliability and cost-effectiveness of inspection and analysis processes; improving data management and maintenance; optimising statistical evaluations, detectability and inspectability analysis, defected part repair/rejection.

1. Introduction

In many industrial sectors, including aerospace, the NDT themes are assuming an increasing critical and addressing role, due to the product quality problems coming from the use of new materials, design concepts and manufacturing technologies. However, the emerging needs of improving the performance of NDT must be balanced with the imperative of reducing inspection, analysis and diagnosis costs. This requires to achieve a well defined architecture in terms of standardisation and integration of NDT methods, processes and facilities. Within the frame of European Brite-Euram Researches [1,2], such an architecture for the implementation of NDT function has been assessed in accordance with Unified Life-Cycle Engineering (ULCE) concepts, taking into account concurrent engineering aspects and total quality management around the design [3,4]. Seen in this context, NDT/NDE is a function of a general process where a notable amount of information is busily shared, with a high level of interactivity, among all the teams involved in the quality, design, manufacturing and maintenance of the product (data flow mechanism is sketched in fig. 1). The kernel of the architecture is a database-oriented tool, based on a NDT data organisation and flow model, called INSIDE NDT (INformation Supporting Inspection, Diagnosis and Evaluation of NDT); it approaches a general NDT knowledge base system, defined as a knowledge base component (containing "knowledge") and a database component (containing "information") [5,6]. The tool has both a static and dynamic feature. In fact, it organises all the data directly or indirectly related to NDT, and manages the information flow from and to NDT function. In the following, a formulation of the model is reported: here, the term model is used in the sense of definition of the Object Oriented Data Base (OODB) structures that describe the NDT function and processes.

Fig 1: Data flow scheme from/to the NDT function, as in [1,2].

2. Basic Concepts

It is still hard to use an universally accepted formalism, able to model a complex process such as a nondestructive examination. In addition, the difficulty is increased by the need, from our point of view, to describe the process within the knowledge context peculiar to NDT field, reducing as far as possible the formal details of the model. To this purpose, we make essentially use of a simplified scheme - based on the one reported in [7] - allowing, however, to define complex model structures.

Objects


Fig 2: Elements of a model.

In this scheme, (fig. 2), a set of specific data, grouped on the base of a defined rule (e.g. data describing a particular inspection system), is an object and can be indicated by the pair (OID, d (t)), where OID is the object identifier that univocally refers to the time-dependent set of data d (at a given instant t₀, d (t₀) is called the state at t₀). An object is characterised also by the methods (procedures, operations, etc.) used to create, destroy, extract information or modify the state of the objects itself. A method is public or private: public methods are executed by external object applications and guarantee the integrity of the object itself (no other operation can be performed on its state); private methods are visible only from the other methods of the same object where they are defined.

Types
Each object has its own type which univocally identifies the class which the object belongs to. The type T of d is a description of the features that an object must have in order to be of that type. The simplest types (atomic types) are the ones commonly encountered in programming languages or in database systems (integer, single, string, date, hypertext, OLE, etc.). Atomic types considered in the following are: boolean (b -false/true or yes/no values), byte (b-values from 0 to 255), integer (i-short, long, signed and unsigned integers), enumerative (e-list of a discrete number of values), real (r-single and double precision values), matrix (x), formula (f-combination of OIDs and mathematical/logical operators, variables and constants that produces a string, a number or another OID obtained as output of a computation), string (s-of any length), date-hour (d), multimedia (m-image, movie, etc.), hypertext (h) , password (symbol p). The semantics (i.e. the meaning) of d is defined by label A (attribute) assigned to the type T (type definition). The syntax for a general semantic S is S=A:T (e.g. inspector = inspector-name:string defines the inspector as an alphanumeric sequence of characters representing the name of an inspector). Complex types are created by using specific operators, such as a record, to combine simple types. A record definition is obtained grouping more type definitions: if S₁,..., S_n are type definitions, also their collection defines a type (a record r ) and can be indicated as A:(T=r (S₁,..., S_n)). Others operators are list (l ), set (s ) and bag (y ), which create, respectively, ordered, non-ordered (without duplicates) and non-ordered with duplicates collections of objects having a given type: if S₁ defines a type, also S₂= A₂:l (S₁), S₃= A₃:s (S₁) and S₄= A₄: y (S₁) define types. Due to the recursive nature of the concept of type, it is possible to obtain extremely complex types, by iterative combining the above operators. Moreover, it has to be pointed out that: i) the OID of an object is implicitly associated to each object; OIDs and their collections can be types. In other terms, the definition of a type can make use of references to other objects (object-valued): if w (S₁=A₁:T₁) indicates the reference to the OIDs of objects with type T₁, also S=w (S₁) defines a type.

Classes
A class is a collection of persistent objects of the same type. Non-persistent objects can be created by some applications: they are deleted when the application terminates. Each persistent object has an OID and can be referred by a different object: this guarantees the referential integrity among the structures of the model. Usually, each method is targeted to a specific class; nevertheless, there can be multi-targeted methods applied to more classes. A sub-class can be obtained from a main class (called super-class) by introducing one or more attributes or methods, i.e. by specialising the class. Each sub-class inherits type definitions and methods from the corresponding super-class. The condition that C₁ is a sub-class of C₂ can be written as C₁ h C₂, where h is the ordering relation among the classes (hierarchy) defining the specialisation process; seen as sets, C₁ Í C₂.

OODB Model and Layers
On the base of the above concepts, a model can be defined by the quadruple ( k , ,f ,h ), where: k is the set of the classes; is the set of types; f is the function associating each class to a type; h is the hierarchical relation. The notation can be simplified by indicating the model only with the pair ( k , ), understanding f and h if their value is clear. The recursive nature of the type definitions and the possibility to define object-valued types permit the construction of a model by a progressive itemisation of the types themselves. Let T₀= ₀ and C₀= k ₀ be, respectively, the most generic type of the model (from which all the other types are obtained by itemisation) and the corresponding class. The pair (C₀,T₀) forms the layer 0 of the model. The corresponding type definition is S₀=A₀:T₀ and can be itemised as follows: S₀=A₀:(T₀=r (w (S₁₁),...,w (S_1n))), where, for each iÎ [1..n], S_1i=A_1i:T_1i. If ₁={ T₁₁,...,T_1n} and k ₁ is the set of the corresponding classes, the pair ( k ₁, ₁) forms the layer 1 of the model. If each T_1i is itemised analogously to T₀, the layer 2 is obtained. The itemisation can be recursively iterated and terminates when, for a given layer, there is at least a type that is not itemised exclusively by references to objects. Of course, it is possible to specialise each class by generating sub-classes. It has to be noted also that some of the structures coming from the itemisation could be considered as separate databases linked with the main one.

3. Three layers NDT model INSIDE NDT

Symbols
In order to improve the readability of the type definitions, a same string for S and A is used, so that T:op is used in lieu of A=T:op (op being an operator or an atomic type). Sometimes, a table notation is adopted; in particular, the definition T=op₀(op₁(S₁),...,op_n(S_n)) is tabled as follows

Main Attribute: A - Type: op0

A1 - op1 - Description of A1.

...

An - opn - Description of An.

In some cases, the following symbols are used: (i) op₁/.../op_j, when the type could be defined by means of op₁, ..., or op_j; e.g. w /s is used when a group of data could be come down also to a simple code or name (string); (ii) s _m, for defining a set representations (images, movies, etc.) associated to the attribute of the main definition, aiding in performing NDT operations (for instance, an op_i=s _m in the previous table regards representations of A); in particular, this type could be defined by s (Medium-File-Name:h, Caption:s,...) or also by s (Medium-File:m, Caption:s), if, respectively, the applied rendering method is public or private. Finally, it has to be remarked that too generic types (e.g notes), comments on OIDs (with few exceptions) and descriptions for types having self-explaining attributes are omitted.

Layers 0 and 1
NDT function and processes can be conceived as objects referenced by the structures of a more general model ULCE. Let ndt be the type describing a generic NDT process. Layer 0 of the model can be expressed by means of the type definition NDT Process:ndt to which is associated the super-class of the NDT Processes. On the other hand, each NDT process involves some entities and sub-processes, each corresponding to a type. In detail, layer 1 can be expressed as follows

Main Attribute: NDT Process - Type: r

Component - s (w ) - Collective item grouping all the features of the component to be tested that are relevant for preparing the inspection procedure and for achieving the inspection and the subsequent diagnosis.

Examination - s (w ) - Collective item reporting all the elements concerning requirements, modalities and execution of the inspection of a Component, as well as all the aspects about diagnosis process, including the list - and, when possible, the classification - of the found defects, in accordance with the applicable acceptance criteria.

System - y (w ) - Collective item on the features of the equipment used for applying the examination procedures.

Flaw Collection - y (w ) - Data bank reporting the properties of a number of anomalies, independently of the flaws expected in the article under test. In a sense it could be considered as a collateral Type, not directly involved in an inspection process, but nevertheless it is can be viewed as a tool supporting both the devising of procedures and the achievement of the diagnosis as well.

Personnel - y (w ) - Collective item describing the information about all the persons involved in the preparation and approval of the procedures, as well as in the accomplishment of the inspections.

Layer 2
The third layer is obtained by itemising each of the previous five types.

Component


Fig 3: Scheme of a Component.

The proposed schematisation of a component to be tested has been obtained from a refinement of the schemes adopted in [8,9], primarily with the aim to extend the representation capability to complex articles (such as composites, bonded parts, etc.) and to introduce items linked to diagnosis aspects (such as acceptance/rejection criteria). The main attribute - Component - it is intended as set of design data (so typical OIDs could be drawing numbers) and concerns both general features, that are independent of the specific inspections, and data regarding the particular articles to be inspected. Summarising the itemisation (fig. 3): from the inspection view point, a Component contains one or more volumes to be inspected (Inspection Volumes); from a manufacturing view point, it is constituted by one or more Component Parts (this is valid not only for evident cases - e.g. assemblies - but also for allowing a more detailed schematisation of a sub-article), each of them being made of one or more Part Materials. An Inspection Volume does not necessarily correspond to a part (e.g. a composite part could have sandwich and laminated zones, requiring different ultrasonic inspection procedures) and is characterised, among other things, by the Expected Flaws (for each expected flaw, acceptance/rejection criteria are defined). Finally, from a production point of view, each Component is realised in a number of specimens (Test Components). The model of Component is basically in compliance with the requirements of [10]. A classification (for non-experts) by type of the engineering materials is adopted, implementing the information segments required for a complete description in the light of the demands from NDT function. An attempt to organise the memorisation of physical and mechanical properties has been tried too. To this purpose, it has been proposed [8,9] to fix more or less ultimately all the involved quantities, but nevertheless this is not a flexible solution, requiring the refinement of the model each time a quantity must be added or modified for any reason: a more general structure is introduced here. Finally, it should be pointed out that methods could be created, that link NDT with materials databases and automated production processes, so to actualise most of the fragments of the ULCE connections. The third layer itemisation of Component is as follows.

Main Attribute: Component - Type: r

Structure - s - Code of the macro-component, including an ensemble of Inspection Volumes, for which a defined Inspection Plan (see in the following) is established (e.g. Outb'd Flap Composite Part).

Component Name - s - Conventional name of the Component (e.g. Lower Skin Panel Outb'd.).

CAD File - h - Reference to the Component CAD file.

Manufacturing Standard - h - Reference to the documentation for manufacturing the Component.

Program - w /s - Code of the general manufacturing, assembling, overhaul, service and/or control Program.

Owner - w /s - Component proprietary.

Medium - s m - Set of Component representations.

Inspection Volume - s (w )

Component Part - s (w )

Test Component - s (w ) - The OID of a related object identifies the manufacturing, assembling, overhaul, service and/or control phase including the inspection; typically it will be the Job/Work Order. The type definition describes information on the manufacturing site, the manufacturer and the manufacturing date of the Test Component: Test Component:r (Site:s,Manufacturer:w /s,Date:d),

Main Attribute: Inspection Volume - Type: r

Volume Name - s - Conventional or coded name of the volume to be inspected (e.g. laminate, see description of Inspection Volume). In some cases, it coincides with a Component Part.

Reference System RS - h - Reference system allowing to position the volume with respect to the Component and to size it. It could be a reference to a CAD file (in most cases the same memorised by CAD File in Component).

Notes on RS - s - Interpretation notes about the above type. It can describe also exhaustively the position of the volume with respect to the Component: in this case, RS could be omitted.

Surface Description - s - Typical surface finishing relevant for the inspection (e.g.: grinding condition, polish, etc.)

Medium - Type: s m - Set of Inspection Volume representations.

Expected Flaw - s (w ) - A flaw that is possible to find in a given Inspection Volume. It defines a diagnosis target and is defined as a lack of conformity with respect to the applicable requirements (established on the base of the features of the materials and of the manufacturing process). In function of its nature and of its dimension, a flaw can be considered acceptable or inadmissible: in this last case it is classified as defect and requires repair interventions or, for more severe cases, the rejection of the component.

Volume Material - Type: s (w ) - Set of references to the Materials making up the volume.

Main Attribute: Expected Flaw - Type: r

Flaw Definition - s - Definition of the flaw in accordance with the Acceptance Document.

Acceptance Document - h - Reference to the document reporting the acceptance/rejection criteria of the flaw.

Physical A/R Criteria (PARC) - s (w ) - Set of the references to the physical acceptance criteria applicable to the flaw.

Flaw Collection Link - l (w ) - Reference to Flaw Collection. For diagnosis purposes, each expected flaw can be associated to one or more of these anomalies. The order is associated to the level of similarity between the expected flaw and each of the anomalies.

Main Attribute: Physical A/R Criteria(PARC) - Type: r

Physical Criterion - f(w ) - Rule defining the physical criterion. It can be conceived as a combination of a number of mathematically defined rules (called Physical Ingredients, PI) by means of logical operators. The following type definition can be adopted: PI:r (Ingredient-Name:s, Quantity:s, Unit:s/e, Min:r, Max:r), where: Ingredient Name is the name of the mathematical rule (e.g. "Defected surface"; Quantity is the physical quantity involved (e.g. "area"); Unit is the metrical unit (e.g. "mm2"); Min and Max are, respectively, the allowed minimum and maximum values.

A/R - b - It indicates if the criterion is an acceptance or a rejection rule.

Applicability - s - Notes describing the cases where the criterion is applicable (e.g., an article can be inspected under different severity levels - usually called grades - depending on the status of the manufacturing process).

Main Attribute: Component Part - Type: r

Part Name - s - Conventional or coded name of the part constituting the Component.

Manufacturer - w /s - Manufacturer name/code (or set of related features) of the part.

Property - Type: s (w ) - Set of the properties of the part (e.g. thickness of the lower skin of a sandwich part): Property:r (Property-Name:s, Description:s, Unit:s/e, Value:r)

Part Material - Type: s (w ) - Set of references to the Materials making up the part.

Main Attribute: Material - Type: r

Material Standard - s (h)/s (s) - Reference to the doc's relative to the fabrication of the material.

Description - s - Qualitative description of the material and of its function (e.g.: CFRP tape).

Manufacturer - w /s - Manufacturer of the Material.

Kind of Material - l (w ) - Individuation of the material family. It could be considered an optional type, but, as matter of fact, it may guide in facing some diagnosis targets. Although a more rigorous definition could be given [11] in terms of indexed linguistic variables, here it is sufficient to define list can as an ordered collection of strings (a1,...,ak) variables associated to a sequel of semantic levels: for each j, aj further details/refines aj-1.

Example of information levels: metallic, non-ferrous, aluminium alloy, heat treatable, AlCu Group 2000, 2024, ...

Quantity - s (w ) - Set of the material physical properties influencing the NDT processes. It should include properties both linked and not-linked to the application of specific nondestructive methods (e.g., respectively, acoustical impedance for ultrasound techniques and resin content in composites). It is intended as associated to a super-class subdivided into the sub-classes of Formula-based and Values-based (VB) quantities. In the second case: VB:r (Name:s,Unit:s/e,Row:b,Col:b,Complex:b ,Table-of-values:w (x),Description:s), where: Name is the name of the quantity; Unit is the metrical unit; Row and Col are, respectively, the row and the column number of the matrix of the values; Complex indicates if the values are real or complex; Table-of-values is the matrix of the values, having an order (established by some private methods) of RowxCol or 2xRowxCol according to the real or complex nature of the quantity; Description reports how the values must be interpreted. This allows to memorise any kind of numerical values. In particular, also valued functions can be expressed as a matrix; e.g., a KxN matrix could contain N values for each x1-axis, ..., xk-1-axis, y-axis, in accordance with the function y=f(x1, ..., xk-1).

Main Attribute: Examination - Type: r

Job/Work Order - w - Reference to a Test Component.

Procedure - w - Reference to an Inspection Procedure, that is to an object belonging to a sub-class of the Procedures.

NDT System - w - Reference to a NDT System. A method must guarantee that the System is permitted by Procedure.

Reference System - h - CAD file used as reference (generally, it is the same as Inspection Volume).

Issuing Status - b - It expresses the condition that the examination process was completed or not, so that its values affects the object state. It is possible that only completed processes are considered as persistent objects, as well as that only persistent objects can be assigned to the sub-classes of the super-class corresponding to Objective (see below).

Trace - r - Traceability in terms of Examination date and site: Trace:r (Date:d, Site:w /s).

Objective - b /e - Examinations can require or not formal approvals in compliance with the applicable Quality Specifications. This generates at least two consequent sub-classes. The implementation of the approval protocols should be realised by a method that establishes the selectable values of Personnel and the ordering rule (e.g. on the base of the certification level of the personnel performing the inspection).

Signs - l (w ) - List of references to Personnel according to the method applied within the sub-classes of Objectives.

Environmental Conditions (EnC) - s (w ) - Conditions affecting the inspection results. The corresponding type can be defined as follows: EnC:r (Condition-Name:w /s/e, Description:s, Value:r). Of course, Condition-Name could be, in its turn, a reference or a value selected from a table of values.

Operating Conditions (OpC) - s (w ) - As detailed in the following, each NDT System is made of Devices. A Procedure can prescribe a range of values (from Value-From to Value-To or included in a Data-File) for some Parameters of some Devices. Operating Conditions allows to report the used values (single Used-Value or included in a Used-Data-File) when, for any reason, they must be pointed out (e.g. when they disagree with the prescribed ones): OpC:r (Device:w , Device-Parameter:w , Requirements:r , Used-Values:r ) Requirements:r (Unit:s/e, Value-From:r, Value-To:r, Data-File:h) Used-Values:r (Unit:s/e, Used-Value:r, Used-Data-File:h)

Analysis - s (w ) - References to Analysis and Visualisation Procedures (corresponding objects belong to sub-classes of associated to Procedure) used to treat and visualise data for diagnosis purposes: Analysis:r (Analysis:w ,Visual:w )

Acquired Data (AcD) - s (w ) - Set of references to non-digital and digital data acquired during a specific Examination: AcD:r (Interpretation:s, Analog-Data:s (w ), Digital-Data:s (w )) Analog-Data:r (Support:e, Traceability:s) Digital-Data:r (File-Name:h, Format:s/e) where: Interpretation describes how to interpret data; Support indicates the kind of analog support of data; Traceability reports notes about the traceability of data.

Treated Data (TrD) - s (w ) - Structured as Acquired Data, this type describes the set of data coming from the acquisition and subsequently processed by Analysis. In addition, it contains the type related to the defects found during the Examination by the Analysis of the Treated Data. The type definition is TrD:r (Interpretation:s,Analog-Data:s (w ),Digital-Data:s (w ),Found-Defects:s (w )) Found-Defect:r (CAD-File:h,IARC:w ,Flaw:w ,PARC:w ,Features:s (w )) Feature:r (Feature-Name:s/e,Description:s,Unit:s/e,Value:r) where: CAD-File is used for defining the features of the defect; IARC refers to an Instrumental Acceptance/Rejection Criteria (see Procedure) according to the applied Procedure; Flaw refers to an Expected Flaw of the inspected Inspection Volume; PARC refers to the applied Physical A/R Criteria associated to the involved Expected Flaw; Features describes the measured defect characteristics relevant for the application of the acceptance criteria.

Main Attribute: Procedure - Type: r

Method - e - Conventional or coded name specifying the method which the technique belongs to. Sub-classes can be generated depending on the method nature (Analysis, Rendering or NDT). Additionally, sub-sub-classes can be created (e.g., from the NDT Method, Penetrant Testing, Ultrasound Testing, etc.)

Technique - e - For a given Method, the specific technique used (e.g. Fluorescent Post-Emulsifiable Hydrophilic for Penetrant Testing). The Technique-Method compatibility is assured by proper private methods. Type definition is Technique:r (Name:s, Method:e, Description:s, Output-Data-Type:r ), where Output-Data-Type:r (Description:s, Data-Type:s (e)) indicates the form of data produced by the technique (e.g. digital images, film, etc.)

Trace - r - Traceability in terms of issuing date and Company: Trace:r (Date:d, Company:w /s).

Condition - r - Defined by Condition:r (Status:e, Objective:b /e, Signs:l (w )), where Objective, Sign and Status are as in Examination, but in this case at least three conditions should be considered (Draft, Final, Obsolete) for Status.

Revision - s

Revision History - s (r ) - Definition: Revision History:r (Old-Revision:w , Change-Description:s).

General Content - s/l (s) - Procedure items not to be arranged in Steps of a Sequence. The ordered list definition could allow to subdivide the content in chapters according to a template established by means of a private method.

Applicable Documents - Type: s (h)

Platforms - Type: s (w ) - Reference to the NDT Systems that can be used to perform the Procedure.

Instrumental A/R Criteria (IARC) - s (w ) - Analogous to PARC in Expected Flaw. Before PARC are applied, the selection of the flaws (not yet defects) must be done by evaluating defined quantities depending on the Technique (e.g. peak amplitudes in pulse-echo ultrasound): IARC allows a mathematical formulation of this evaluation.

Sequence - y (w ) - Procedure items organised in Steps of a Sequence of operating instruction to be progressively executed. The following type definition is adopted: Step:r (SeqN:i,Block:e/s,System:w ,Device:w ,Parm:w ,Unit:s,VFrom:r,VTo:r,Operation:s, VFile:h,Medium:s m), where: SeqN indicates the execution order of the Step; Block is the name of a collection of Steps (performing logically linked operations, e.g. the set-up of a hardware), which the specific Step belongs to; Parm, Device and System refer to the Parameter of a specific Device of a System allowed by the Procedure; VFrom and VTo individuate the range of values prescribed for Parm: these values can be also arranged in an attached file Vfile.

Flow Chart - l (w ) - List of references to high-language-like Instructions, which simplify the issue and the interpretation of the operating aspects of a Procedure. Type definition is: Instruction:r (Command:l (w ), Comment:s), where Command is, in its turn, a referencing-based structured type allowing the implementation of a language syntax. OID of an Instruction could be interpreted as the label of the Instruction itself. In addition to the more "usual" ones (If-like, While-like, etc.), two special Commands have to be included, according to what previously maintained; they can be called "Execute a block of Steps" "Execute a Procedure", prescribing the execution, respectively, of the Steps of a referenced Block of the Sequence and of all the Steps of a referenced Procedure.

Examination
It should be noted that more Examinations can concern a given Inspection Volume of a Test Component, i.e. there can be more Examination OIDs for each Job/Work Order (Test Component). Moreover, each Inspection Volume can require more Procedures and, vice versa, a Procedure can be applied to different Inspection Volumes, belonging to one or more Components. A specific inspection can be performed with whatever NDT System permitted by the applied Procedure. When required, Examinations and Procedures must be undergone to a signing/approval protocol (however, the technical/legal aspects of the digital signing, as well as security topics are not tackled here). Each Procedure is classified by an analysis, a rendering or a NDT (Penetrant Testing, Ultrasound Tesing, etc.) Method and reports, among other things, the Sequence of the operating steps to be performed. Problems could arise when a Procedure involves more Methods. To overcome this difficulty, the model contemplates the possibility that each Procedure can refer to other Procedures: this solves also the problems related to the approval of Procedures making use of different NDT Methods (usually, in fact, in this case NDT persons having different certifications are required). Moreover, this simplifies the preparation of the Procedures, allowing to configure these as master-procedures based on sub-procedures.

Fig 4: Scheme of an Examination

System
System is whatever NDT equipment or tool used for NDT purposes: it is intended as an ensemble of hardware apparatuses and software codes, each called Device. Analogously to what done for Procedure, Systems are permitted that make use of other Systems and of Devices associated to different Methods: among other things, this simplifies the modelling of complex Systems as macro-Systems constituted by sub-Systems, so meeting the conditions due to the set up of modular system [12,13]. For a fixed Method, each Device is defined by a Kind, that specifies the function of the Device itself (e.g. demagnetiser for Magnetic Testing). Sub-Kinds can be defined, that detail the nature of the Device (e.g. AC-demagnetiser). According to [8,9], the set of the Kinds of a Method - that is the ensemble of all the hardware and software Devices (together with related process parameters) constituting a typical (or also special) complete tool for implementing/performing a given technique - can be interpreted as a method model. In [8,9] an attempt is made for defining all the Kinds of some Methods. Here, a more general approach is followed, by defining Types that allow the user to create own method model. The third layer itemisation is as follows.

Main Attribute: System - Type: r

Method - e - As for Procedure.

Trace - r - Traceability in terms of integrator/manufacturer, model and serial number of the System: Trace:r (Integrator:w /s,Model:s, S/N:s).

Quality Items (QI) - r - Information on (re)qualification aspects of the System, strictly related to Quality entity of ULCE scheme: QI:r ((Re)Qualification-Date:d, (Re)Qualification-Validity:d, Qualification Report:h).

Medium - s m

Devices - s (w ) - Set of references to the Devices and to other Systems constituting the actual System. Accordingly, two sub-classes of Devices could be generated. It records the characteristics and the performances of a device, independently of the inspection method/technique. Device type definition makes use of Types similar to the ones used for System, with the exception Kind: Device:r (Kind:e/s,Name:s,Trace:r ,QI:r ,Medium:s m,OF:r (s (w )))

Perfomances - s (w ) - Features of the whole System. P:r (Name:s,Description:s,Unit:s/e,Value-From:r,Value-To:r).

Operative Features (OF) - r (s (w )) - It is not within the aims of the paper to detail this type. It concerns some operating aspects of a System, strictly related to the management of the hardware and the software, such as logical and physical connections among Devices, System inputs and outputs and controls available by the user.

Flaw Collection
Articulated type aiming at offering the possibility to define the main features of typical flaws.

Main Attribute: Flaw Collection - Type: r

Classification - s (w ) - References to flaw Categories, with Category:r (Main:e/s,Sub:e/s), Main and Sub being, respectively, the phase of the article fabrication/life in which the flaw occurs and the process detail of Main. The object value of Sub depend on the value of the Main object. Examples Main/Sub values are: "inherent"/"cast material", "primary processing"/"rolling", "secondary processing"/"bending", "service"/"corrosion", etc.

Medium - s m

Applicability of Methods - s (w ) - References to the Applicability for a given NDT Method, defined by Applicability:r (Method:e/s,NApl: s (s),EvAppl:r/x), where: Method is an NDT method (e.g. x-Radiography); Napl is a set of notes about the applicability (e.g. for the flaw "Cold Shut" with x-Radiography a note could be "some castings have inaccessible areas that can only be inspected by radiography"); EvAppl is a single or an ensemble of numerical values reflecting the degree of applicability of the Method: they can be determined by proper codes.

Kinds of Material - s (l (w )) - Set of the Kinds of Material (see Part Material) where the flaw can be typically found.

Material - s (w ) - References to the objects of Part Material. Used materials where the flaw can be found.

Origin - s (s) - Notes on the causes producing the flaw.

Appearance - r - Structured information on the physical aspect of the flaw in terms of features associated to the typical location of the flaw with respect to a hypothetical inspected volume. Inspired by the classification approaches in [14], type definition is as follows (shortly, only Surface is detailed): Appearance:r (Surface:r ,Open-To-Surface:r ,Sub-Surface:r ,Internal:r ,Interface:r ) Surface:r (Interrelationship:r ,Surface Geometry:r ) Interrelationship:r (Multiplicity:r , Alignment:r ) Multiplicity:r (Single:r/x,Grouped:r/x) - Alignment:r    ( Random:r/x,Straight:r/x,Parallel:r/x) Surface Geometry:r (Length-to-Width-Relation:r ,Corner:r ,Shape:r ,Style:r ) Length-to-Width-Relation:r (Rounded:r/x,Elongated:r/x,Filamentary:r/x) Corner:r (Smooth:r/x,Sharp:r/x) - Shape:r    (Point:r/x,Forked:r/x,Branched:r/x,...) Style:r (Continuous:r/x,Dashed:r/x,Dotted:r/x) It must be noted that: (i) type definition could be generalised so to allow, for each itemisation level, user-defined features; (ii) the values of most specialised types indicate the degree of belonging (in the fuzzy or statistical sense) of the flaw to the class defined by those types.

Personnel
This type is strongly connected with the Quality function of the ULCE scheme. The third layer itemisation is as follows.

Main Attribute: Personnel - Type: r

Name - w /s - Person involved in NDT. It can reference to objects having values on particulars, company, and so on.

Certifications & Responsibilities - s (w ) - Set of certifications and responsibilities hold by the NDT person. Each referenced object is associated to a record CR defined as follows: CR:r (Method:e/s,Role:e/s,CertDoc:h,ExpCert:d,Stamp:h/m,Limitation:s,Password:p), where: Role is defined according to the applicable quality/company standards and specifications (e.g. Level III); CertDoc is the certification documentation; ExpCert is the expiry date of the certification; Stamp is the stamp hold by the person (if any); Limitation describes the eventual limitations of the certification.

4. Tests & Conclusions

With the aim to test the model, two prototypical implementations were planned: a basic version oriented to the usage in a production context (inspection sites); and a client/server SQLServer version - based on Web procedures - aiming at actualising the remote-managing aspects of the architecture (e.g. see [15]). The basic version has been almost completely realised, while the last one is yet in the completion phase. In spite of its limits, mainly in terms of hardware platform architecture and data security/management, Microsoft® Access 7 (under Microsoft® WindowsNT 4.0) was selected for the basic version, on the base of its large diffusion and easiness in developing powerful user-friendly graphical interfaces. In particular, all the NDT items (materials, manufacturing, procedures, inspections, hardware and software tools) related to some components of Eurofighter 2000 Typhoon, ATR 42/72 and B767 were treated by means of basic INSIDE NDT. Some applications (used as public methods of the model) were purposely developed, in order to exploit the potentialities of the tool. In particular, modules devoted to the extraction of defects and to reporting them on component drawings, statistical approaches for evaluating the occurrence and the main characteristics of various defect kinds and algorithms addressing the preparation of inspection procedures were developed. Moreover, a binary NDT data format (with features comparable with the format in [9]) for easing data exchange protocols among different inspection sites was established in a preliminary way. All the functionality and data flow tests performed in on-line production and engineering environments confirmed the ability of the architecture in promoting standardisation, automation and concurrent engineering of NDT-related operations; increasing reliability and cost-effectiveness of inspection and analysis processes; improving data management and maintenance; optimising inspectability analysis and defected part repair/rejection operations. Some exercises for approaching POD determination (that still remains one of the more critical NDT items - [16]) was successfully performed too.

In conclusion, the model proved to be a valid ground for setting up a general architecture supporting the diagnosis ends of the NDT/NDE function. However, at this stage, it requires still an improvement of the implementation strategies and the refinement of the primary methods. To this purpose, a re-evaluation, mainly in terms of application activity model, according to the requirements of [17], is needed. Moreover, in order to tackle the forthcoming challenges, it is essential to establish a strict co-operation between NDT/NDE and computer science experts in order to face organically still open problems concerning: the impact of large-scale databases on digital data retrieval (e.g. see [18,19]), the management of the transition from data representation models to information extraction algorithms (decision-diagnosis tool), and the validation (from the quality assurance point of view) of networked real-time information requiring approval/signing protocols.

5. References

1. BRITE-EURAM III, Contract n° BRPR-CT96-0200, CANDIA - Cost Reduction By Advanced Non Destructive Inspection Of Aeronautical Structures, 1997-1999
2. BRITE-EURAM III, Contract n° Contract N° BRPR-CT98-805, INDUCE - Advanced Integrated NDT Concepts for Unified Life-Cycle, 1999-2001
3. H. M. Burte and D. E. Chimenti: Unified Life-Cycle Engineering: an Emerging Design Concept - Rev. of Progr. in QNDE, Vol. 6A, Plenum Press, NY, 1987
4. L. W. Shmerr, Jr. and D. O. Thompson: NDE and Design - A Unified Life-Cycle Engineering Approach - Rev. of Progr. in QNDE, Vol. 12B, D. O. Thompson and D. E. Chimenti, Plenum Press, 1992
5. J. K. Debenham, Integrating Knowledge Base and Database, Proc. 10th ACM Ann. Symp. on Applied Computing SAC'96, Philadelphia, 1996
6. J. Hildreth: Computer-aided feature extraction, classification, and acceptance processing of digital NDE data, SPIE Prooc. V. 2945, Nondestructive Evaluation of Ageing Aircraft, Airports, and Aerospace Hardware, 1996
7. P. Atzeni, S. Ceri, S. Paraboschi, R. Torlone: Basi di dati, concetti, linguaggi e architetture, McGraw-Hill, 1996
8. CEN/TC138/AHG3, Generic Nde Data Format Model, 1997, draft version
9. European RACE Project, TRAPPIST - Transfer Processing and Interpretation of 3D-NDT-Data in a Standard Environment - E. Lebègue: Data For Non Destructive Technique Examinations, Trappist Programming Library - Trappist 1.6/A, General Format For Nde Data, Part 1: Data Model, 1997
10. ASTM Manual on The Building of Materials Databases, Ed. Crystal H. Newton, 1994
11. G. Cavaccini: A Concept of Similarity for Comparing Database Records, CANDIA report (see [1]), 1999
12. G. Cavaccini, A. Ciliberto, L. D'Antonio, C. Sabatino, The Alenia Approach to Integrate NDT Methodologies, Proc. Conf. on Experimental Techniques and Design in Composite Materials, Cagliari (IT), Oct. 1992
13. N. Komsky: Modular Imaging Systems for Ultrasonic Evaluation of Aircraft and Bridge Structures, Prooc. on Int. Symp. on NDT Contrib. to the Infrastructure Safety Systems, UFSM, Brazil, 1999-NDT.net-Apr. 2000, V. 5 No. 04.
14. C. E. Betz: Principles of Penetrants, Magnaflux Corp., Chicago, Illinois, USA, 1963
15. K. Yamamoto, H. Nakamura, S. Matsui: Internet-based Diagnosing System for Hydropower Steel Structures, 13^th ASCE Eng. Mech. Div. Conf., J. Hopkins Univ., Baltimore, MD, USA, 1999
16. B. Doggart: Probability of Detection, Mat. Ev. V. 58, N. 4, Apr. 2000
17. ISO 10303: STEP (STandard for the Exchange of Product model data), ISO 10303-1/-11/-21/-31/-43, 1996
18. L. Zheng, H.-H. S. Wu, J.-C. S. Liu, A. K. Chan: Object-oriented image coding scheme based on DWT and Markov random field, SPIE Prooc. V. 3654, Multimedia Computing and Networking, 1999
19. Y. N., M. T. Ozsu, X. Li: Two-dimensional S-tree: an index structure for content-based retrieval of images, SPIE Prooc. V. 3654, Multimedia Computing and Networking, 1999

© AIPnD , created by NDT.net

|Home|    |Top|