Hybrid Diagnostic Model tm – An extension of diagnostic dependency modeling that allows the inter-relationships between tests, functions and failures to be captured within a single representation of a system, device or process.
One of the primary reasons why eXpress is good at supporting the entire life cycle development, and why the investment into modeling makes sense, is that eXpress is the only tool that takes a system level, multi-design discipline perspective to iteratively drive a design through the entire development cycle. Spreadsheets, flat models and commercial tools either force a late entry into modeling, or force the model to be rebuilt sometime during the process. The simple fact is that the investment into non-reusable modeling does not pay off.
The problem in supporting complex analyses, such as Testability, Reliability, etc. from a spreadsheet, is that spreadsheets do not handle a number of key functions required for such analyses. In contrast, eXpress addresses these issues:
The problem in supporting complex analyses, such as Testability, Reliability, etc. from a spreadsheet, is that spreadsheets do not handle a number of key functions required for such analyses. In contrast, eXpress addresses these issues:
Spreadsheets have attempted to move in the direction to support these problems through the incorporation of pivot tables, etc. However, the fundamental limitations of the grid arrangement of data prohibits the simplicity required for analyzing the same set of data in multiple ways. The spreadsheet user is forced to reorganize the data for different analyses.
One of the most important points of the hybrid model in eXpress is that one often models tests differently (functionally or based on failure) depending on whether you are testing nearer the system level or nearer the component level. However, there is a much more compelling reason for a hybrid model that becomes less arguable by those with competing approaches (including the spreadsheet approach). We’ve mentioned this before, but it is easily forgotten.
The earlier you are in system design, the more likely you don’t understand many of the failure modes. During conceptual trade-offs, where you have the most flexibility to make really big differences in the final supportability of the system being designed, you don’t want to be encumbered by necessarily thinking about modes of failure just to build a model. In these phases, eXpress’s functional approach allows the basic testing approach to be created, much like the ideas behind a Functional FMECA. By “allocating” the approach and being able to assess it through purely functional tests, you can begin to understand partitioning problems, problems with visibility and isolation, etc.
Now, that by itself justifies becoming involved early. However, where eXpress uniquely addresses this, is the fact that eXpress will help the engineer maintain their investment into these early models built for early trade-offs and analyses. As failure modes become more apparent, and as lower levels are built, the initial model and testing philosophy can be transitioned over to incorporating failure modes as the predominant element that the model uses. The functions drop down to forming the fabric, but no longer act as the element of highest concern. This transition would normally require an entirely new model to be built in the case of spreadsheets, or other modeling tools with the exception of eXpress. Even math models and similar approaches would require a complete rethought of the model. eXpress, however, allows test definitions to be changed piece-meal as failure modes pop up for any of the covered objects. Tests themselves can be hybrid, of course, just as the model can be.
It is this transition that maintains the investment into the model that justifies becoming involved early, since the model will “see the engineer through” from the original thoughts to the final diagnostic design. This avoids a double-hit for modeling, the possible introduction of errors when the model is rebuilt again. In addition, one of the most dangerous things that can occur is that the final design can completely diverge from the original concept. eXpress solves this problem by using a hybrid model which allows the original model to mature and evolve throughout the design phase by maintaining a single modeling environment. Without the capability to develop hybrid models, multiple models must be created as the design changes. Normally two or more different models are not easily compared to ensure the original concept has been maintained. Although different departments all try to maintain the concept, they are themselves often working to different specifications. eXpress becomes the only tool looking across the disciplines from a system perspective as the design matures through the entire development cycle.
Reference: Thomsen, Erik. 2002. OLAP Solutions, Building Multidimensional Information Systems, Second Edition, New York, NY. John Wiley & Sons, Inc. ISBN 0-471-40030-0