Greg Stanley and Associates
 Home   About Us   Products   Services   Success Stories   Tech Resources   Contact Us 
HomeTech ResourcesFault Diagnosis > Projects >

Project Implementation for Fault Detection and Diagnosis

Diagnosis Subtopics:

 

This page examines project implementation as part of the white paper
A Guide to Fault Detection and Diagnosis.

Projects to implement fault detection and diagnosis are similar to other projects for the system being monitored, such as those for process control or IT system management. 

Project implementation styles vary, depending on organizations, development processes already in place as standards, and contracting arrangements. An ideal approach is to break the project into multiple, short development cycles, achieving useful results and experience faster in a series of small steps rather than one large all-or-nothing project. In terms used by software developers, an "agile" methodology offers many benefits. This works best for in-house development efforts. But this may not always be possible, for instance, in a fixed price contract by an outside vendor allowed only limited interactions with the end users. But even in that case, the project can often be implemented as a series of smaller stages.

Prototyping is generally very valuable. It helps refine requirements, and educates both the application developers and the users. It can generate excitement, momentum, and idea generation.

Once the basic system architecture, integration and diagnostic framework is in place, each short cycle of development might, for example, address the next top N root cause problems and the top N observed symptoms, or focus on an area of a plant, or on a type of equipment. N might be 10 when scheduling fixed price updates, or much less for incremental in-house work.

Within a development cycle, the following steps are generally followed.

Functional specification (requirements and high-level architecture & design)

Typical issues addressed at this stage of the project include:

  • Identify the system being monitored
  • Identify goals of the diagnostic system
  • Identify all users of the system (end users like plant operators and managers, engineers, application developers, application maintainers, systems support, etc., and their needs for GUI and access.)
  • Identify other “actors” in the system (e.g., other software), to identify availability of data, tests, and system integration needs
  • Identify the “experts”: sources of information, such as engineers, operators, etc. They will provide models and heuristics, or review them. 
  • Identify the available models or heuristics
  • Define possible root causes that should be found, starting with the most important ones such as those that have high impact (safety, cost, etc.) and those that occur frequently
  • Define some key observed symptoms (starting with the most important ones such as those corresponding to problems with high impact (safety, cost, etc.) or those that occur frequently
  • Define the approach for metrics for monitoring application success
  • Define GUI needs at a high level
  • Identify constraints imposed on the system (e.g., required hardware & software by corporate standards)
  • Prototyping with reviews (optional, but always a good idea if possible to do)
  • Once there are approximate estimates on the scope of the system long term, define the architecture, hardware, and high level design
  • Estimate costs
  • Specification documentation, review and approval

Detailed design and implementation

Typical issues addressed at this stage of the project include:

  • Detailed design of GUI
  • Determine any parameters such as event thresholds and model parameters not already determined (including any necessary plant tests or expert interviews)
  • Build any needed models, pattern definitions, procedures, etc.
  • Complete any system integration “bridges” needed
  • Complete any other computer coding needed.
  • Detailed design and implementation of metrics
  • Test plan
  • Design documentation, review, and approval

Offsite testing and review

Typical issues addressed at this stage of the project include:

  • Set up a test environment
  • Execute test plan in the test environment using simulated values as needed
  • Review and approval
  • Followup on items identified in testing

Onsite testing and review

Typical issues addressed at this stage of the project include:

  • Install system on site with live data
  • Test with intensive monitoring by application developers
  • Tuning and fixes as needed
  • Formal system acceptance testing and approval
  • Followup on items identified in testing

Commissioning and training

Typical issues addressed at this stage of the project include:

  • Train end users
  • Run the system online with monitoring by application developers
  • Tuning and fixes as needed
  • Implement metrics monitoring application success
  • Train maintainers of the system, if different from the application developers
  • Deliver operation and maintenance documentation
  • Trial period with support on call

System operation and routine maintenance

This cycle of the project is now complete, and the system is now owned by the end user customer.

Typical issues addressed at this stage include:

  • Retune as needed
  • Modifications as needed to support plant or operational changes
  • Identification and reporting of bugs
  • Monitoring operations and metrics for evidence of problems
  • Identify possible new applications

(Start of the next development cycle)

If the project has been staged, start the next cycle.

 

Copyright 2010 - 2013, Greg Stanley

(Return to A Guide to Fault Detection and Diagnosis)

 

Share this page: Share this page via LinkedIn... Bookmark or share this page on Delicious... Share this page by e-mailing link...    

 Home   About Us   Products   Services   Success Stories   Tech Resources   Contact Us 
Enter keywords to search this site:
Now operated by Performity LLC