CETS Advantages

CETS Users

1. US Navy Seawolf Ship Control Fault Localization System - Built by Draper Labs for Newport News Shipbuilding - Integrated with Submarine by Lockheed Martin Syracuse.

STATUS: Completed

REFERENCES: US Navy, Newport News Shipbuilding, Lockheed Martin - Syracuse

2. US Army Re-Engineering (self sufficient diagnostics) Program. Ported DiagnosticianTM to micro-controller and demonstrated on Rockwell Collins GPS test system. Read built-in-test and directed CTS3 probe tests to single fault.

STATUS: Completed

REFERENCES: US Army Ft. Monmouth

3. NASA SBIR for Automated Power Controller Diagnostics - Phase II Program to read BIT with micro-controller hosted Diagnostician^TM and reconfigure power controller in real time.

STATUS: Completed

REFERENCES: Marshall Space Flight Center

4. Hughes System 2000 Advanced Maintenance Concept

An initial pilot program is being run on the Hughes Radar System installed in the Air Force F15 Fighter Plane. The Diagnostician model is utilized to enhance aircraft built-in-test and provide fault isolation without intrusive testing. This program has large visibility across the military and possible commercial airline applications.

The Hughes intent is to use commercial Hughes satellites to project maintenance information anywhere in the world.

STATUS: Underway using Sun Workstation.

REFERENCES: Hughes Radar and Communications System LA, CA

[GRAPHIC - PG12_95.PRE]

CETS Questions / Answers

Concurrent Engineering Tool Set

Diagnostician

1) Please specify the availability of your tool from the following list: a) COTS, b) GFE, c) public domain, d) service-integrated, e) proprietary.

The Concurrent Engineering Tool Set and the Diagnostician are commercial off-the-shelf products. They are Proprietary products of Giordano Automation. The run-time algorithms associated with the Diagnostician are patented. We have a standard price list which includes annual leased licenses and direct purchases for single seat, site and program licenses.

2) Does your tool provide what you feel is a significant Integrated Diagnostics specification, design, analysis or maturation function which is not covered in this breakdown? If so, what?

Yes, our tool provides a diagnostics capability / function which is not covered by the breakdown in the survey tables. The survey tables reflect the standard approach used for diagnostics development: a reliance on diagnostic flow paths or fault trees which are hard coded as part of a test program or test routine to isolate faults. CETS and Diagnostician are based upon a new paradigm - Dynamic diagnostics based upon a model of the system. It doesn't provide data for you to develop the diagnostics, it provides the diagnostic capability. The output is used directly in run-time (embedded, off-line ATE or PMA) to provide fault isolation based upon reading test results. Flow paths, and the optimization of diagnostic fault trees are the primary focus of many other tools. However, this is only useful if the output is to be hard-coded into a test program or used as a manual trouble-shooting aid in doing next best test. These do not fit well into the environment of automated testing which is represented by ATE or built-in test. Our approach is to create a software object which is intelligent and can dynamically perform diagnostics based upon test data. We have uncoupled diagnostic logic from test in the ATE and embedded worlds, where "next best test" is insignificant. Further, the intensive "analysis" performed by other tools is only correct if the output of that analysis is directly used in run-time. Since it is usually not, the analysis is inherently wrong.

Since our focus is on run-time, not analysis, many of our tool functions are focused on giving the user the ability to tailor the model to make it a very intelligent representation of the design from a diagnostics perspective.

3) What are the figures of merit which are output by your tool, categorized by function?

Figures of Merit Output by the tool include:

Test Specification:

Ambiguity Group based upon:

Fault Isolation Statistics based upon:

TPS Generation

Generate Fault Trees
We eliminate the need for Fault Trees!
Diagnostics V&V

Eliminate the need to perform physical fault insertion to verify diagnostic capability via Maintenance Simulator

Figures of Merit input to tool
Reliability Factors at the component or pin level

Test Cost:

Additionally, we have a processing engine that takes logged data from each diagnostic session and performs statistical analysis to determine if and in what manner the failure probability weighting should be modified to reflect actual field experience.

Tool Input:

4) What standards/definitions/algorithms are applicable to figures of merit input or output by your tool?

Assessment Standards: MIL-STD-2165, MIL-STD-1814

5) What CAD/CAE database formats does your tool read/translate/write, if any? Please specify the level of automation of your interface, e.g. manual text input, graphical input, automatic translation, etc.

EDIF and VHDL outputs from CAD systems are the standard inputs to our tool. The translation process from EDIF and VHDL are fully automated through a graphical user interface. For cases where a user does not have CAD outputs, we recommend they use OrCAD Schematic Capture package to graphically draw the schematic, then output an EDIF netlist for input to our translator. Since EDIF dialects differ from CAD system to CAD system, we have over the years, developed adjuncts to our translators to account for these dialects. We have used outputs from every major CAD system: Mentor, ViewLogic, Cadence and so on.

We also have a series of utilities that deal with netlist data, giving the user the capability to:

We also have the capability to generate models from a text-based (ASCII) matrix showing faults and tests.

6) What standards does your tool support or require in the areas of data repository, data interchange and operating environment (e.g., ABBET, EDIF, POSIX)?

The Diagnostic Profiler outputs a wide range of reports, all in ASCII format. Simple routines have been and may be written to extract required data and input that data into any required format.

The Diagnostic Profiler can be compiled with an optional data base which allows the user to define/configure his own data base content. The data base is keyed off of defined tests. The data base has been written in CodeBase 5, which is a data base that can be output to several standard formats, including FoxPro, DBase. Although the fields are configurable by the user, we have structured a series of fields that are based upon the LSA Data Base.

The Run-Time Diagnostician has a data log mode which generates a series of reports for each diagnostic session. The reports are somewhat tailorable and are all output in standard ASCII format. Simple routines have been and may be written to extract required data and input that data into any required format.

Data Interchange

EDIF, VHDL, ASCII, Binary Files are used to facilitate the interchange of data.

Operating Environment

Our development tool, the Diagnostic Profiler, is an X-Windows Client. It can be hosted on Unix platforms, including Sun Workstation and IBM RISC 6000 or on a PC under DOS. On a PC, the X-Windows interface is provided by either Quarterdeck's DESQview/X or Hummingbird's ExCeed 4 Windows or ExCeed for Windows 95.

Our Run-Time System consists of a C/C++ program and a binary knowledge base. The binary knowledge base (generated from the Diagnostic Profiler) can be hosted on any computer platform / operating system including a micro-processor for embedded applications. The C/C++ program is compilable to any environment as well. It is compiled as a library of functions. For Windows applications, these are in a Dynamic Link Library (DLL). In the Unix environment, these are a standard library structure. It has been hosted on PCs and workstations and micro-controllers. It operates under the following environments:

Windows 3.x: (DLL Functions, LabVIEW, GeoTest's ATEasy, HP-VEE, AIMSS and IDRIS, and can be integrated into any Windows package)

DOS
X-Windows
Unix: SCO Unix, Interactive Unix

Micro-Controller: Intermetrics Op Sys Kernal, & Custom Kernals

7) To what other tools, not covered by questions 5 or 6, does your tool provide a means for data interchange?

8) What additional inputs, not already covered above, are required for each function? What additional outputs, not covered above, are provided by each function?

The primary output of our tools, aside from reports and data, is a diagnostic knowledge base (a binary file) that is used in run-time to provide fault isolation. Our run-time algorithms read the results of tests, and dynamically provide fault isolation. Our fault isolation algorithms are based upon minimum set covering, and use both pass and fail cones of evidence to provide the fault isolation call-out. This is much more effective than simple exact-match algorithms and binary split methods. It provides better fault isolation with fewer tests required. This also allows for multiple fault situations: no longer are we constrained to a single fault assumption, which in the past, has made the test job do-able, but often unrealistic. This approach is really the only viable approach for diagnostics in complex hierarchical systems which include fault tolerance through redundant channels.

9) Is the input or output for any given function in a textual, graphical or internal database format? If input, please describe the mode of entry.

In the development environment, we have an internal data base format that we call a matrix file set. The matrix file set is viewed and modified through the graphical user interface.

In the run-time environment, the internal data base is called a Diagnostic Knowledge Base, which is a pre-processed, binary version of the matrix file set. Details of our internal format and structures are available upon request, but are generally considered proprietary information of Giordano Automation.

10) What additional information from maintenance logs and associated data bases (e.g. DMMIS and REMIS), if any, might your tool use beyond that already covered in questions 3 through 8?

11) To what extent, if any, are you participating in efforts such as CORBA, COM, etc., aimed at defining distributed, object-oriented, compound document/object/database format/protocol standards? To what extent, if any, do these efforts play a part in your future tool architecture plans?

The Diagnostician is "Object Oriented," that is, the data and software needed to isolate faults are merged into objects called Diagnosticians. The transition to object oriented programming for diagnostics will have dramatic impacts on the implementation of concurrent engineering for support using CETS. The same Diagnostician generated by the system engineer will be used as a "server" in embedded and off-line ATE environments.

We are currently looking at JAVA implications. We are constantly tracking software standards and advanced approaches and architectures. We also closely track the test and measurement industry and make sure that we fit into the primary standards (VXI, LabVIEW, HP VEE, etc., We do this, not to satisfy data requirements, but to survive in an increasingly commercial market. We believe that military systems must and will also follow this trend to use industry standards where-ever possible. We intend to continue to lead the diagnostic software marketplace in providing real solutions through advanced, and wherever possible, standard software approaches.

The CETS competes with STAT, TEAMS, STAMP and other testability analyzers. However, the "Diagnostician," which is capable of dynamic interpretation of test results, is a significant departure from the 'diagnostic flow chart' strategies inherent in GADS, TEAMMATE and Pointer approaches.

The impact of this technology is dramatic! For the first time engineers can design tests and map them to the hierarchical diagnostic knowledge base for each maintenance environment. In other words, the inference engine and knowledge base would operate with embedded tests (PM and BIT), and then with organizational tests (portable maintenance aids), followed by off-line depot test (large scale ATE). The user can simulate the diagnostic effectiveness in each maintenance environment before committing the tests or building the hardware. Concurrent engineering of support for diagnostics is now a reality!

Show me Theory of Operation

Show me Tool Set for Generation of Knowledge Bases

Send mail to webmaster@giordano.com with questions or comments about this web site.
Last modified: December 27, 2001