spherea technologyspherea-technology.co.uk/sphereatechnology/... · © 2017 spherea technology ltd...

© 2017 SPHEREA Technology Ltd - All rights reserved

SPHEREA Technology

Presentation: Diagnostic Aide Overview

Presenter: Ben Matthews


Diagnostic Aide Overview - Contents

This Presentation covers:

• Initial Requirement

• Smart Diagnostics

• 2015 TPS Lifecycle Demo

• Diagnostic Aide Objectives

• Diagnostic Aide Definition

• System Overview

• HW Requirements

• Prototype Development

• Diagnostic Session

• MMI Walkthrough

• Further Development


Initial Requirement

• UK MOD has identified the following needs which if satisfied, would result in better,

more efficient test and support cycle for equipment:

– Improve the capabilities of front line / forward deployed testing

– Reduce number of LRU’s returned (shipped to workshop for testing)

– Reduce Test Times

– Reduce NFF

– Reduce requirement for ATEs specific to LRUs / UUT

• One approach to delivering these improvements is the application of Smart

Diagnostics


Smart Diagnostics

• Some Definitions

• Using a test system’s BIT and test & support information “better” to reduce life cycle support costs

• Using already available information from an operational test and logistic system, structuring it in a standard and widely re-useable format to provide an open architecture to support diagnostic test and repair across all support levels.

• Some Aims

• Improve current BIT diagnostics – by mapping BIT codes to actual fault resolution actions

• Combine test and repair information to add and aid field and operation diagnostics

• Collect and learn system faults and failures

• Identify and preserve tests and critical results

• Correlate past results (BIT etc) with identified failures and repairs

• Identify past NFF conditions using their fault signature and resultant root cause

• Facilitate field, workshop and OEM repair information sharing across test stations


Smart Diagnostics

• Some Effects and Implications

• Providing support and gaining useful information from multiple test stations (where every service may have a different ATE). – by defining a open architecture allowing standard information interchange and implemented services for heterogeneous systems

• Providing timely smart diagnostics back into ATE systems in-service, including those at remote locations – by providing a standalone diagnostic aid that can augment existing ATS fielded equipment

• For existing and deployed systems Smart Diagnostics can be introduced at the current test and repair facility and progressively improve performance going forward over time.

• Open Systems Architecture and IEEE ATML Standards compliant data needed, to facilitate communication


Smart Diagnostics

Design & Analyze

• Optimized diagnostic strategy

• Integration of on-board and off-board diagnostics

• Closed-loop model improvement

Test & Evaluate

• Automatic code generation

• Closed-loop test requirements verification

Diagnose & Repair

• Optimized repair strategy

• Adaptive learning improves diagnostic capability and reduces No Fault Find / Retest OK / Cannot Duplicate occurrences

• Standards-Powered, COTS-Based Solution for Through-Life Support


2015 TPS Lifecycle Model Demonstration

• Existing COTS tools performing diagnostics do an excellent job, but:

• Proprietary data formats

• Heterogeneous information requirements

• 2015 TPS life cycle model demonstrated at AutoTestCon

• TPS end to end development

• Started at design phase, functional model

• ATML data ->TestStand->OSA-RTS->TestProgram

• Simulated run ->Results -> FRACAS (DSI Workbench)

• Utilised a history DB of actual repairs

• Identified most probable failures against fault signatures

• Add new fault scenarios

• Complete lifecycle from design to field maintenance and support


2015 TPS Lifecycle Model Demonstration

• Demonstration Key features

• Cohesive suite of loosely-coupled commercially available software tools adhering to Automatic Markup Language (ATML) standards

• Target different areas of a product’s life cycle

• When interfaced through standard formats, provide a complete end-to-end support solution

• Standard formats allow information to move seamlessly through the stages of a system’s life cycle

• Lots of industry Interest

• Q “How Can I apply this to my existing System?”

• A. Need ISDD information

• may be unavailable or missing

• Expensive to regenerate

• Need to integrate from Design phase onwards


MOD’s Diagnostic Aid Objectives

• Diagnostic Aid should start from a “Minimum Position” of available information, to enable legacy systems to gain benefits

• Utilise COTS tools which support ATML format (directly or indirectly)

• e.g. eXpress, TestStand, Workbench

• Build up an Improved dataset with use, over time

• Interpret and use existing BIT

• Optimise and adjust Test Flow for faster isolation of faults and failures

• Reduce test times

• Identify misdiagnosis

• Provide a framework and infrastructure for generating ATML information

• Maintain and update ATML information based upon new information (Test results, maintenance actions).

• Intention to demonstrate a prototype in 2018/19

• Seeking Candidate UUT and Test System to demonstrate real gains


Diagnostic Aide – Definition

• Portable Rack based Diagnostic Tool, using Smart Diagnostics for better outcomes

• A forward deployable diagnostic tool, capable of getting better information from

existing BIT and ATE Test data

• Independent of ATE and UUT

• Use an Open Systems Architecture, utilising existing tools and capabilities

• Use IEEE Standards for data exchange (IEEE 1641, 1671, 1636)

• Built in HW and SW ATE generic electrical test capabilities for use when no other

ATEs are available (e.g. when forward deployed)

– Load

– DC Sources for test

– Signal generation (Sig Gen, AWFG)

– Measurement (DMM, Digitiser, DAQ)

– Buses

– MMI


Diagnostic Aid

STD UUT Description

STD Test Description

STD Test Results

Maintenance Actions

UUT

ATE

Test Instruments

Test Controller

Test Program

ATML Data

Power Supplies

ATML DataInterchange

ATE UUT interface

Power connections COTSComponents

User Interface

MMI connections

Diagnostic Aid – System Overview


Diagnostic Aide – System Overview


Diagnostic Aide – Operating Space


Diagnostic Aide – Portability

Portability

• Classic 19” Rack Not portable enough

• PXI solution a possibility

• Small PXI chassis (e.g. 3U, 8 or more slots) linked to a Laptop where the OS and

Diagnostic Aid would reside. Laptop either Docked or just LAN Linked

• Not directly connected to existing ATE (data transferred instead)


Diagnostic Aide – Hardware Capability Requirements

Required Hardware Capabilities

Components

Chassis PXi, 3U, >8 slots

Controller (Pxi) Quad core, Intel, > 2.4 Ghz

DAQ 16 Bit, 16 Analogue in, 2 Analogue Out, 24 Digital IO

Digital Load 5 Channels, 0.25 Ohm resolution, Max > 2 kOhm

High Speed Digitiser

500 MHz 5GS/s, 2 channel, 256 mb/channel, capable of RF

measurements up to 2.4GHz

Interface Pxi Express 2.7 GB/s, 5 us latency,

DC sources configurable 5V to 30 V DC

AWFG AWFG 10mHz to 1MHz

DMM Max 1000V DC 700V AC, sensitivity 1pA

RF SIG Gen with FM/AM/QPSK modulation

1553 Bus One of these 3 depending on use


Diagnostic Aide – Prototype Development

• In the absence of any real UUT / ATE / Hardware items, work has so far been limited

to producing software prototypes.

• In the absence of available data, we have been developing prototypes using the ATML

Dataset from the ATC 2015 TPS Lifecycle model demonstration. This models an ECU

with a series of Pass / Fail Tests

Inputs

– Test Description Files

– Test Results Files


Diagnostic Aide – Prototype Development

2 Independent Prototypes so far:

Knowledge Base Prototype

• Reads ATML inputs (Test Results, Test Description)

• Uses a knowledge engine to evaluate facts through forward chaining and back

chaining rules

• ATML Data added to Fact Base as facts

• Rules defined in Rule Base, operate on Facts

• New Facts can be created by rules

MMI Prototype

• Reads ATML inputs (Test Results, Test Description)

• Displays Fields in a basic GUI

• Relates components, fault groups, faults

• Allows basic DRACAS data entry (relating to a specific Diagnostic Set)

• Relates Multiple Test Results Sets and Test Groups under a “Diagnostic Set”


Diagnostic Aide – Generating Fault Trees

1 2

5 6

3

A B

C

4

D

E

F

G

• Elements

• Tests

• Sequence

• Limits

• Faults Groups

• Components

• Correlate BIT to results

• Add “discovered” Faults and

Failures

• Add test steps to resolve

ambiguity groups


Diagnostic Aide – Diagnostic Session


Diagnostic Aide – MMI


Diagnostic Aide – Further Development

• Add Statistical Analysis (need real data with varying values)

• Identify ATML Constructs or produce extensions for “Diagnostic Set”, and DRACAS

(MAI) Data, as well as storing extra data (calculated statistical values etc)

• Extensions are supported in ATML

• Write Data to ATML Outputs (ATML Test Results, MAI)

• Integrate Knowledge engine, provide capability to “Fill in the Blanks” (reverse engineer

missing data) and identify new facts from multiple related test runs

• Diagnostic Stress Analysis

Need Real Datasets for SW development (real measured data)

Need HW Suppliers on board for HW development


Diagnostic Aide – Diagnostic Stress Analysis

• How close is each test to failure?

• Do perturbations in measurements lead to different diagnostic results?

• Was the repaired fault within our tree but the wrong decision led to

misdiagnosis?

• Are the limits correct?

1 2

5 6

3

A B

C

4

D

E

F

G 1 2

5 6

3

A B

C

4

D

E

F

G


Thanks

28

The reproduction, distribution and utilization of this document as well as the communication of its contents to others without express authorization is prohibited. Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a patent, utility model or design.

Thank you for your attention!


Q&A

29

The reproduction, distribution and utilization of this document as well as the communication of its contents to others without express authorization is prohibited. Offenders will be held liable for the payment of damages. All rights reserved in the event of the grant of a patent, utility model or design.

spherea technologyspherea-technology.co.uk/sphereatechnology/... · © 2017 spherea technology ltd...

Documents