Compare commits
No commits in common. "ASIS_26MAR2012" and "main" have entirely different histories.
ASIS_26MAR
...
main
20
.gitignore
vendored
20
.gitignore
vendored
@ -1,20 +0,0 @@
|
||||
#
|
||||
#
|
||||
#
|
||||
# git ignore for latex
|
||||
#
|
||||
|
||||
*.aux
|
||||
*.log
|
||||
*.dvi
|
||||
*.pdf
|
||||
*.lof
|
||||
*.lot
|
||||
*.toc
|
||||
*.*~
|
||||
*.bbl
|
||||
*.blg
|
||||
|
||||
*_paper.tex
|
||||
*.txt
|
||||
|
||||
8
README.md
Normal file
8
README.md
Normal file
@ -0,0 +1,8 @@
|
||||
# ARCHIVE OF PhD files
|
||||
|
||||
|
||||
See master branch which is essentially the whole git `thesis`
|
||||
repository as stoed on 'NovaProspect'
|
||||
|
||||
|
||||
# 30APR2025 RPC
|
||||
@ -1,14 +0,0 @@
|
||||
Your rpc2 user account
|
||||
Details about your rpc2 user account are shown below.
|
||||
If you don't want to make any changes, just close this tab in your browser.
|
||||
Some data used for your computer account is supplied by Registry's Student Database, so changes to that system will affect your user account.
|
||||
Your student number is 96002640.
|
||||
|
||||
Your UniCard number is 00121240 (issue number 01).
|
||||
|
||||
|
||||
Your email address
|
||||
main email address R.P.Clark@brighton.ac.uk
|
||||
other email address rpc2@brighton.ac.uk - this is the address you should use to sign into UniMail
|
||||
email forwarding This account has an Exchange mailbox, which should not combined with email forwarding.
|
||||
|
||||
@ -1,7 +0,0 @@
|
||||
Write up detailed failure modes essay for R and OPAMP with ref to EN298, FMD-91, EN61508.
|
||||
|
||||
Get thesis template, have emailed Aidian on this.
|
||||
|
||||
Start writing up approvals backgrounds to static FMEA.
|
||||
|
||||
|
||||
14
backup.sh
14
backup.sh
@ -1,14 +0,0 @@
|
||||
|
||||
rm -rf thesis_back_up*
|
||||
|
||||
d=`date | sed 's/:/_/g' | sed 's/ /_/g' `
|
||||
echo $d
|
||||
|
||||
t=thesis_back_up.$d.tar
|
||||
echo $t
|
||||
tar cvfp $t *
|
||||
|
||||
gzip $t
|
||||
|
||||
ls -l thesis_back_up*
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 426 KiB |
@ -1,38 +0,0 @@
|
||||
|
||||
Thesis Structure Meeting -- Failure Mode Modular De-Composition
|
||||
|
||||
The meeting decided that the thesis should comprise of
|
||||
seven chapeters with the following subject areas.
|
||||
|
||||
1. Introduction - overview of the subject area
|
||||
|
||||
2. FMEA - general description, variants and context
|
||||
|
||||
3. Weaknesess of FMEA
|
||||
|
||||
4. FMMD - proposed solution, modularisation of FMEA
|
||||
|
||||
* Hierarchical modelling - functional groups --> derived components etc
|
||||
* Symptom extraction process
|
||||
* Unitary State failure modes -- only one failure mode may be active at
|
||||
a given time in a component -- definition.
|
||||
|
||||
5. Examples for various levels of problems,
|
||||
|
||||
* using examples set by C Garrett,
|
||||
* the PT100 temperature sensing circuit (double failures analysed)
|
||||
* A larger complete electronics example (possible an anbalog PID controller)
|
||||
|
||||
6. Evaluation of FMMD
|
||||
|
||||
* Unitary State failure modes.
|
||||
* Complexity Comparison
|
||||
* Problems in modelling for FMMD.
|
||||
|
||||
7. Conclusion and further work.
|
||||
|
||||
* Software modelled in terms of failure modes - follow contract programming paradigm
|
||||
* Hardware modelled in terms of failure modes (perhaps look at a servo motor, linkage, gearbox motor etc).
|
||||
|
||||
A goal has been set to submit these chapters, writing the introduction last,
|
||||
by October 2012.
|
||||
615
mybib.bib
615
mybib.bib
@ -1,615 +0,0 @@
|
||||
|
||||
|
||||
% my bib file.
|
||||
|
||||
@ARTICLE{fmd91,
|
||||
AUTHOR = "Reliability Analysis Center",
|
||||
TITLE = "Failure Mode/Mechanisms Distributions 1991",
|
||||
JOURNAL = "United States Department of Commerce",
|
||||
YEAR = "1991"
|
||||
}
|
||||
|
||||
% $Id: mybib.bib,v 1.3 2009/11/28 20:05:52 robin Exp $
|
||||
@article{Clark200519,
|
||||
title = "Failure Mode Modular De-Composition Using Spider Diagrams",
|
||||
journal = "Electronic Notes in Theoretical Computer Science",
|
||||
volume = "134",
|
||||
number = "",
|
||||
pages = "19 - 31",
|
||||
year = "2005",
|
||||
note = "Proceedings of the First International Workshop on Euler Diagrams (Euler 2004)",
|
||||
issn = "1571-0661",
|
||||
doi = "DOI: 10.1016/j.entcs.2005.02.018",
|
||||
url = "http://www.sciencedirect.com/science/article/B75H1-4G6XT71-3/2/0e3a47df2ec15bfba9f85feae81786e3",
|
||||
author = "R.P. Clark",
|
||||
keywords = "Failsafe",
|
||||
keywords = "EN298",
|
||||
keywords = "gas-safety",
|
||||
keywords = "burner",
|
||||
keywords = "control",
|
||||
keywords = "fault",
|
||||
keywords = "double-fault",
|
||||
keywords = "single-fault",
|
||||
keywords = "fault-tolerance"
|
||||
}
|
||||
@ARTICLE{bubba,
|
||||
AUTHOR = "Ron Mancini",
|
||||
TITLE = "Design of OP-Amp sine wave oscillators",
|
||||
JOURNAL = "Analog Applications Journal: Texas Instruments: August",
|
||||
YEAR = "2000"
|
||||
}
|
||||
@ARTICLE{ftahistory,
|
||||
AUTHOR = "Clifton Ericsson",
|
||||
TITLE = "Fault Tree Analysis a History",
|
||||
JOURNAL = "Proceedings of the 17th international safety conference",
|
||||
YEAR = "1999"
|
||||
}
|
||||
|
||||
@ARTICLE{fafmea,
|
||||
AUTHOR = "Zigmund Bluvband, Pavel Grabov",
|
||||
TITLE = "Failure Analysis of FMEA",
|
||||
JOURNAL = "IEEE 1-4244-2509-9/09/",
|
||||
YEAR = "2009"
|
||||
}
|
||||
@ARTICLE{fmeda,
|
||||
AUTHOR = "John C. Grebe Dr. William M. Goble",
|
||||
TITLE = "FMEDA – Accurate Product Failure Metrics",
|
||||
JOURNAL = "EXIDA publication. www.exida.com/articles/FMEDA\%20Development.pdf",
|
||||
YEAR = "2007"
|
||||
}
|
||||
@ARTICLE{canspec,
|
||||
AUTHOR = "Bosch.",
|
||||
TITLE = "CAN Specification 2.0",
|
||||
JOURNAL = "Bosch Technical Standard",
|
||||
YEAR = "1991"
|
||||
}
|
||||
|
||||
@ARTICLE{caninauto,
|
||||
AUTHOR = "H. Zeltwanger",
|
||||
TITLE = "Single Processor implementation of the CANopen Safety Protocol",
|
||||
JOURNAL = "CAN in Automation (CiA)",
|
||||
YEAR = "2008"
|
||||
}
|
||||
|
||||
@ARTICLE{valueoflife,
|
||||
AUTHOR = "W.K. Viscusi",
|
||||
TITLE = "The value of life: Estimates with risks by occupation and industry",
|
||||
JOURNAL = "Harvard John M. Olin Canter for Law ISSN 1045-6333",
|
||||
YEAR = "2003"
|
||||
}
|
||||
|
||||
|
||||
@ARTICLE{crcembedd,
|
||||
AUTHOR = "Philip Koopman, Tridib Chakravarty",
|
||||
TITLE = "Cyclic Redundancy Code (CRC) Polynomial Selection for Embedded Networks",
|
||||
JOURNAL = "The International Conference on dependable systems and networks DSN-2004",
|
||||
YEAR = "2004"
|
||||
}
|
||||
|
||||
@ARTICLE{nucfta,
|
||||
AUTHOR = "US Nuclear reg commission",
|
||||
TITLE = "Fault Tree Handbook",
|
||||
JOURNAL = "Nuclear Safety Analysis Handbook",
|
||||
YEAR = "1981"
|
||||
}
|
||||
|
||||
@ARTICLE{nasafta,
|
||||
AUTHOR = "NASA",
|
||||
TITLE = "Fault Tree Handbook with Aerospace Applications",
|
||||
JOURNAL = "NASA Handbook",
|
||||
YEAR = "2002"
|
||||
}
|
||||
|
||||
@BOOK{embupsys,
|
||||
TITLE = "Embedded Microprocessor Systems 3rd Edition ISBN 0-7506-75434-9",
|
||||
AUTHOR = "Stuart R Ball",
|
||||
PUBLISHER = "Newnes",
|
||||
YEAR = "2002"
|
||||
}
|
||||
|
||||
@BOOK{alggraph,
|
||||
AUTHOR = "Alan Gibbons",
|
||||
TITLE = "Algorithmic Graph Theory ISBN:978-0521288811 ",
|
||||
PUBLISHER = "Cambridge University PressCambridge University Press",
|
||||
YEAR = "1985"
|
||||
}
|
||||
|
||||
@BOOK{git,
|
||||
AUTHOR = "Jon Loeliger",
|
||||
TITLE = "Version Control with Git ISBN:978-0-596-52012-0",
|
||||
PUBLISHER = "O'Reilly Media",
|
||||
YEAR = "2009"
|
||||
}
|
||||
|
||||
@BOOK{ince,
|
||||
AUTHOR = "D. C. Ince",
|
||||
TITLE = "In Introduction to discrete Mathematics, Formal System specification and Z",
|
||||
PUBLISHER = "Oxford University Press",
|
||||
YEAR = "1992"
|
||||
}
|
||||
|
||||
@BOOK{safeware,
|
||||
AUTHOR = "Nancy Leveson",
|
||||
TITLE = "Safeware: System safety and Computers ISBN: 0-201-11972-2",
|
||||
PUBLISHER = "Addison-Wesley",
|
||||
YEAR = "2005"
|
||||
}
|
||||
|
||||
@BOOK{scse,
|
||||
AUTHOR = "Fortescue, Swinerd, Stark",
|
||||
TITLE = "Spacecraft Systems Engineering ISBN:978-0-470-75012-4",
|
||||
PUBLISHER = "Wiley",
|
||||
YEAR = "2011"
|
||||
}
|
||||
|
||||
@BOOK{bfmea,
|
||||
AUTHOR = "Robin E McDermot et all",
|
||||
TITLE = "The Basics of FMEA ISBN: 0-527-76320-9",
|
||||
PUBLISHER = "Productivity",
|
||||
YEAR = "1996"
|
||||
}
|
||||
|
||||
@BOOK{mil1991,
|
||||
AUTHOR = "United~States~DOD",
|
||||
TITLE = "Reliability Prediction of Electronic Equipment",
|
||||
PUBLISHER = "DOD",
|
||||
YEAR = "1991"
|
||||
}
|
||||
|
||||
|
||||
@BOOK{faa,
|
||||
AUTHOR = "Federal Aviation Administration",
|
||||
TITLE = "System Safety Handbook",
|
||||
PUBLISHER = "http://www.faa.gov/library/manuals/aviation/risk\_management/ss\_handbook/",
|
||||
YEAR = "2008"
|
||||
}
|
||||
|
||||
|
||||
@BOOK{sccs,
|
||||
AUTHOR = "Neil~Storey",
|
||||
TITLE = "Safety-Critical Computer Systems ISBN 0-201-42787-7",
|
||||
PUBLISHER = "Prentice Hall",
|
||||
YEAR = "1996"
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@PHDTHESIS{maikowski,
|
||||
AUTHOR = "Leo M Maikowski",
|
||||
TITLE = "Tolreranced Multiple Fault Diagnosis of Analog Circuits",
|
||||
SCHOOL = " Brighton University, School of Electrical Engineering",
|
||||
YEAR = "1995"
|
||||
}
|
||||
|
||||
@BOOK{sem,
|
||||
AUTHOR = "J.~Woodcock,~Martin~Loomes",
|
||||
TITLE = "Software Engineering Mathematics ISBN 0-273-02673-9",
|
||||
PUBLISHER = "Pitman",
|
||||
YEAR = "1988"
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@BOOK{allfour,
|
||||
AUTHOR = "Betty Tootell",
|
||||
TITLE = "All Four Engines Have Failed ISBN 0-233-97758-9",
|
||||
PUBLISHER = "Andre deutsch",
|
||||
YEAR = "1985"
|
||||
}
|
||||
|
||||
|
||||
@BOOK{f77,
|
||||
AUTHOR = "A.~Balfour D.H.~Marwick",
|
||||
TITLE = "Programming in Standard Fortran 77 ISBN 0-435-77486-7",
|
||||
PUBLISHER = "Heinemann Educational Books",
|
||||
YEAR = "1979"
|
||||
}
|
||||
|
||||
@BOOK{ctw,
|
||||
AUTHOR = "Gregory~J.E.~Rawlins",
|
||||
TITLE = "Compared to What ? An introduction to the analysis of algorithms ISBN 0-7167-8243-x",
|
||||
PUBLISHER = "Computer Science Press",
|
||||
YEAR = "1991"
|
||||
}
|
||||
|
||||
|
||||
|
||||
@BOOK{alg,
|
||||
AUTHOR = "Alan~Gibbons",
|
||||
TITLE = "Algorithmic Graph Theory ISBN 0-521-28881-9",
|
||||
PUBLISHER = "Cambridge University Press",
|
||||
YEAR = "1985"
|
||||
}
|
||||
|
||||
@BOOK{found,
|
||||
AUTHOR = "Ian~Stewart, David~Tall",
|
||||
TITLE = "The Foundations of Mathematics : ISBN 0-19-853165-6",
|
||||
PUBLISHER = "Oxford University Press",
|
||||
YEAR = "1977"
|
||||
}
|
||||
|
||||
@BOOK{shin,
|
||||
AUTHOR = "Sun-Joo~Shin",
|
||||
TITLE = "The Iconic Logic of Peirces Graphs",
|
||||
PUBLISHER = "Bradford",
|
||||
YEAR = "2002"
|
||||
}
|
||||
|
||||
|
||||
@BOOK{probstat,
|
||||
AUTHOR = " M~R~Spiegel",
|
||||
TITLE = "Probability and Statistics Second edition : SHCAUM'S : ISBN 0-07-135004-7",
|
||||
PUBLISHER = "Oxford University Press",
|
||||
YEAR = "1988"
|
||||
}
|
||||
|
||||
@BOOK{idmfssz,
|
||||
AUTHOR = " D~C~Ince",
|
||||
TITLE = " An Introduction to Discrete Mathematics, Formal System Specification and Z : Oxford : ISBN 0-19-853836-7",
|
||||
PUBLISHER = "Oxford University Press",
|
||||
YEAR = "1988"
|
||||
}
|
||||
|
||||
|
||||
@BOOK{wdycwopt,
|
||||
AUTHOR = " Richard~P~Feynman",
|
||||
TITLE = " What do you care what other people think: Harper Collins : ISBN 0-586-21855-6",
|
||||
PUBLISHER = " harpercollins",
|
||||
YEAR = "1988"
|
||||
}
|
||||
|
||||
@BOOK{joyofsets,
|
||||
AUTHOR = " Keith~devlin",
|
||||
TITLE = " The Joy of Sets: 2nd edition: ISBN 978-0-387-94094-6",
|
||||
PUBLISHER = " Springer",
|
||||
YEAR = "1993"
|
||||
}
|
||||
|
||||
|
||||
@MISC{microchip,
|
||||
author = "Microchip",
|
||||
title = "Microchip technology Inc. Home Page",
|
||||
howpublished = "Available from http://www.microchip.com/",
|
||||
year = "2009"
|
||||
}
|
||||
|
||||
@MISC{gnuplot,
|
||||
author = "Various Open~source~Project",
|
||||
title = "",
|
||||
howpublished = "Available from http://www.gnuplot.info/",
|
||||
year = "2005"
|
||||
}
|
||||
|
||||
@MISC{eulerviz,
|
||||
author = "Peter~Rodgers, John~Howse, Andrew~Fish",
|
||||
title = "Visualization of Euler Diagrams",
|
||||
howpublished = "http://www.cmis.bton.ac.uk/research/vmg/papers/EulerViz.pdf",
|
||||
year = "2005"
|
||||
}
|
||||
|
||||
@MISC{eulerprop,
|
||||
author = "Peter~Rodgers, John~Howse, Gem~Stapleton",
|
||||
title = "Properties of Euler Diagrams",
|
||||
howpublished = "http://www.cmis.bton.ac.uk/research/vmg/papers/",
|
||||
year = "2007"
|
||||
}
|
||||
|
||||
@MISC{en161,
|
||||
author = "E N Standard",
|
||||
title = "EN161:2007 Automatic shutoff valves for gas burners and gas appliances",
|
||||
howpublished = "British standards Institution http://www.bsigroup.com/",
|
||||
year = "2003"
|
||||
}
|
||||
|
||||
@MISC{en298,
|
||||
author = "E N Standard",
|
||||
title = "EN298:2003 Gas Burner Controllers with forced draft",
|
||||
howpublished = "British standards Institution http://www.bsigroup.com/",
|
||||
year = "2003"
|
||||
}
|
||||
|
||||
@MISC{en60730,
|
||||
author = "E N Standard",
|
||||
title = "EN60730: Automatic Electrical controls for household and similar use",
|
||||
howpublished = "British standards Institution http://www.bsigroup.com/",
|
||||
year = "1994"
|
||||
}
|
||||
|
||||
@MISC{challenger,
|
||||
author = "U.S. Presidential Commission",
|
||||
title = "Report of the SpaceShuttle Challanger Accident",
|
||||
howpublished = "Available from http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/table-of-contents.html",
|
||||
year = "1986"
|
||||
}
|
||||
|
||||
@MISC{en61508,
|
||||
author = "E N Standard",
|
||||
title = "EN61508:2002 Functional safety of electrical/electronic/programmable electronic safety related systems",
|
||||
howpublished = "British standards Institution http://www.bsigroup.com/",
|
||||
year = "2002"
|
||||
}
|
||||
|
||||
@MISC{javaarea,
|
||||
author = "Sun~Micro~Systems",
|
||||
title = "Java Area Operations",
|
||||
howpublished = "Available from http://java.sun.com/j2se/1.3/docs/api/java/awt/geom/Area.html",
|
||||
year = "2000"
|
||||
}
|
||||
|
||||
|
||||
@Manual{tlp181,
|
||||
title = {TLP 181 Datasheet},
|
||||
key = {TOSHIBA Photocoupler GaAs Ired and Photo−Transistor},
|
||||
author = {Toshiba inc.},
|
||||
OPTorganization = {},
|
||||
address = {http://www.toshiba.com/taec/components2/Datasheet\_Sync//206/4191.pdf},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
year = {2009},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@Manual{pic18f2523,
|
||||
title = {PIC18F2523 Datasheet},
|
||||
OPTkey = {},
|
||||
author = {Microchip inc},
|
||||
OPTorganization = {},
|
||||
address = {http://ww1.microchip.com/downloads/en/DeviceDoc/39755c.pdf},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
year = {2009},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
|
||||
@Book{wt,
|
||||
title = {Water Treatment Essentials for Boiler Plant Operation},
|
||||
publisher = {Mc Graw Hill ISBN 0-07-048291-5},
|
||||
year = {1997},
|
||||
author = {Robert G Nunn},
|
||||
ALTALTeditor = {},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {ISBN 0-07-048291-5},
|
||||
OPTlocalfile = {},
|
||||
OPTabstracts = {},
|
||||
}
|
||||
|
||||
|
||||
@TechReport{spiraxsarco,
|
||||
author = {Spirax Sarco},
|
||||
title = {http://www.spiraxsarco.com/resources/steam-engineering-tutorials.asp},
|
||||
institution = {Spirax Sarco},
|
||||
year = {2010},
|
||||
OPTkey = {},
|
||||
OPTtype = {},
|
||||
OPTnumber = {},
|
||||
OPTaddress = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
@Book{aoe,
|
||||
title = {The Art of Electronics},
|
||||
publisher = {Cambridge},
|
||||
year = {1989},
|
||||
author = {Paul Horowitz, Winfield Hill},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {},
|
||||
OPTaddress = {},
|
||||
OPTedition = {2nd},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {ISBN 0-521-37095-7},
|
||||
OPTlocalfile = {},
|
||||
OPTabstracts = {},
|
||||
}
|
||||
|
||||
|
||||
@TechReport{eurothermtables,
|
||||
author = {Eurotherm Ltd.},
|
||||
title = {Thermocouple Emf TABLES and PLATINUM 100 RESISTANCE THERMOMETER TABLES},
|
||||
institution = {Eurotherm, UK},
|
||||
year = {1973},
|
||||
OPTkey = {},
|
||||
OPTtype = {},
|
||||
OPTnumber = {},
|
||||
OPTaddress = {},
|
||||
OPTmonth = {June},
|
||||
OPTnote = {Bulletin TT-1},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
|
||||
@Book{ldd,
|
||||
author = {Jonathon Corbet},
|
||||
ALTeditor = {Alessandro Rubini},
|
||||
ALTeditor = {Greg Kroah-Hartman},
|
||||
title = {Linux Device Drivers},
|
||||
publisher = {O'Reilly ISBN 0-596-00590-3},
|
||||
year = {1998},
|
||||
OPTkey = {ISBN 0-596-00590-3},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {3rd},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
|
||||
@Book{bash,
|
||||
author = {Carl Albing},
|
||||
title = {Bash Cookbook},
|
||||
publisher = {O'Reilly ISBN 0-596-52678-4},
|
||||
year = {2007},
|
||||
OPTkey = {ISBN 0-596-52678-4},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {unix/linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{sedawk,
|
||||
author = {Dale Dougherty, Arnold Robbins},
|
||||
title = {Sed and Awk},
|
||||
publisher = {O'Reilly ISBN 1-56592-225-5},
|
||||
year = {1997},
|
||||
OPTkey = {ISBN 1-56592-225-5},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {unix/linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{bels,
|
||||
author = {Karim Yaghmour},
|
||||
title = {Building Embedded LINUX systems},
|
||||
publisher = {O'Reilly ISBN ISBN 0-596-00222-X},
|
||||
year = {2003},
|
||||
OPTkey = {ISBN 0-596-00222-X},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {3rd},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{can,
|
||||
author = {Olaf Pfeiffer},
|
||||
ALTeditor = {Andrew Ayre},
|
||||
ALTeditor = {Christian Keydel},
|
||||
title = {Embedded networking with CAN and CANopen},
|
||||
publisher = {RTC ISBN 0-929392-78-7},
|
||||
year = {2003},
|
||||
OPTkey = { },
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {Embedded Systems},
|
||||
OPTaddress = {},
|
||||
OPTedition = {1st},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.rtcbooks.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Article{article,
|
||||
author = {dd},
|
||||
title = {dd},
|
||||
journal = {dd},
|
||||
year = {2008},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTpages = {1,2},
|
||||
OPTmonth = {JAN},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{sqlite,
|
||||
author = {Micheal Owens},
|
||||
title = {The definitive guide to SQLite},
|
||||
publisher = {Apres ISBN 1-59059-673-0},
|
||||
year = {2006},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {Databases/SQLite},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@ -1,17 +0,0 @@
|
||||
|
||||
PNG =
|
||||
|
||||
pdf:
|
||||
pdflatex thesis
|
||||
acroread thesis.pdf &
|
||||
|
||||
|
||||
bib:
|
||||
bibtex thesis
|
||||
makeindex thesis.glo -s thesis.ist -t thesis.glg -o thesis.gls
|
||||
|
||||
|
||||
puzzle:
|
||||
pdflatex puzzle.tex
|
||||
pdflatex puzzle.tex
|
||||
acroread puzzle.pdf
|
||||
15
old_thesis/burner/.gitignore
vendored
15
old_thesis/burner/.gitignore
vendored
@ -1,15 +0,0 @@
|
||||
#
|
||||
#
|
||||
#
|
||||
# git ignore for latex
|
||||
#
|
||||
|
||||
*.aux
|
||||
*.log
|
||||
*.dvi
|
||||
*.pdf
|
||||
*.lof
|
||||
*.lot
|
||||
*.toc
|
||||
*.*~
|
||||
|
||||
@ -1,17 +0,0 @@
|
||||
|
||||
#
|
||||
# Make the propositional logic diagram a paper
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex burner_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
okular paper.pdf
|
||||
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
burner_paper.tex: burner.tex
|
||||
cat burner.tex | sed 's/burner\///' > burner_paper.tex
|
||||
@ -1,70 +0,0 @@
|
||||
%
|
||||
% Make the revision and doc number macro's then they are defined in one place
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
|
||||
\begin{abstract}
|
||||
things can get very abstract
|
||||
\end{abstract}
|
||||
|
||||
}
|
||||
{
|
||||
\section{Overview}
|
||||
}
|
||||
|
||||
\section{Overview of A Burner Controller : Safety Perspective}
|
||||
|
||||
\section{Background to the Industrial Burner Safety Analysis Problem}
|
||||
|
||||
An industrial burner is a good example of a safety critical system.
|
||||
It has the potential for devistating explosions due to boiler overpressure, low water, or
|
||||
ignition of an explosive mixture, and, because of the large amounts of fuel used,
|
||||
is also a fire hazard. Industrial boilers are often left running unattended
|
||||
for long periods of time (typically days).
|
||||
|
||||
To add to these problems
|
||||
Operators are often under pressure to keep them running. A boiler supplying
|
||||
heat to a large greenhouse complex could ruin crops
|
||||
should it go off-line. Similarly a production line relying on heat or steam
|
||||
can be very expensive in production down-time should it fail.
|
||||
This places extra responsibility on the burner controller.
|
||||
|
||||
|
||||
These are common place and account for a very large proportion of the enery usage
|
||||
in the world today (find and ref stats)
|
||||
Industrial burners are common enough to have different specific standards
|
||||
written for the fuel types they use \ref{EN298} \ref{EN230} \ref{EN12067}.
|
||||
|
||||
A modern industrial burner has mechanical, electronic and software
|
||||
elements, that are all safety critical. That is to say
|
||||
unhandled failures could create dangerous faults.
|
||||
|
||||
A more detailed description of industrial burner controllers
|
||||
is dealt with in chapter~\ref{burnercontroller}.
|
||||
|
||||
|
||||
Systems such as industrial burners have been partially automated for some time.
|
||||
A mechanical cam arrangement controls the flow of air and fuel for the range of
|
||||
firing rate (output of the boiler).
|
||||
|
||||
These mechanical systems could suffer failures (such as a mechanical linkage beoming
|
||||
detached) and could then operate in a potentially dangerous state.
|
||||
|
||||
More modern burner controllers use a safety critical computer controlling
|
||||
motors to operate the fuel and air mixture and to control the safety
|
||||
valves.
|
||||
|
||||
In working in the industrial burner industry and submitting product for
|
||||
North American and European safety approval, it was apparent that
|
||||
formal techniques could be applied to aspects of the ciruit design.
|
||||
Some safety critical circuitry would be subjected to thought experiments, where
|
||||
the actions of one or more components failing would be examined.
|
||||
As a simple example a milli-volt input could become disconnected.
|
||||
A milli-volt input is typically amplified so that its range matches that
|
||||
of the A->D converter that you are reading. were this signal source to become disconnected
|
||||
the systems would see a floating, amplified signal.
|
||||
A high impedance safety resistor can be added to the circuit,
|
||||
to pull the signal high (or out of nornal range) upon disconnection.
|
||||
The system then knows that a fault has occurred and will not use
|
||||
that sensor reading (see \ref{fig:millivolt}).
|
||||
@ -1,404 +0,0 @@
|
||||
%
|
||||
%
|
||||
% $Id: mybib.bib,v 1.5 2008/12/18 17:05:23 robin Exp $
|
||||
%
|
||||
%
|
||||
|
||||
@TechReport{db,
|
||||
author = {R Clark, D Legge},
|
||||
title = {ETC6000 Daughterboard Design notes},
|
||||
institution = {ETC HR221850},
|
||||
year = {2004},
|
||||
key = {},
|
||||
OPTtype = {},
|
||||
OPTnumber = {},
|
||||
OPTaddress = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
issn = {HR221850},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
@TechReport{mil1991,
|
||||
author = {U.S. Department of Defence},
|
||||
title = {Reliability Prediction of Electronic Equipment},
|
||||
institution = {DOD},
|
||||
year = {1991},
|
||||
key = {MIL-HDBK-217F},
|
||||
OPTtype = {},
|
||||
OPTnumber = {},
|
||||
OPTaddress = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
@Manual{tlp181,
|
||||
title = {TLP 181 Datasheet},
|
||||
key = {TOSHIBA Photocoupler GaAs Ired & Photo−Transistor},
|
||||
author = {Toshiba inc.},
|
||||
OPTorganization = {},
|
||||
%address = {http://www.toshiba.com/taec/components2/Datasheet\_Sync//206/4191.pdf},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
year = {2009},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@Manual{pic18f2523,
|
||||
title = {PIC18F2523 Datasheet},
|
||||
OPTkey = {},
|
||||
author = {Microchip inc},
|
||||
OPTorganization = {},
|
||||
address = {http://ww1.microchip.com/downloads/en/DeviceDoc/39755c.pdf},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
year = {2009},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
|
||||
@Book{wt,
|
||||
title = {Water Treatment Essentials for Boiler Plant Operation},
|
||||
publisher = {Mc Graw Hill ISBN 0-07-048291-5},
|
||||
year = {1997},
|
||||
author = {Robert G Nunn},
|
||||
ALTALTeditor = {},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {ISBN 0-07-048291-5},
|
||||
OPTlocalfile = {},
|
||||
OPTabstracts = {},
|
||||
}
|
||||
|
||||
@TechReport{pcbAI222562,
|
||||
author = {C Talmay},
|
||||
title = {Circuit Schematic TDS Daughterboard AI222562},
|
||||
institution = {ETC},
|
||||
year = {2010},
|
||||
OPTkey = {},
|
||||
OPTtype = {},
|
||||
OPTnumber = {AI222562},
|
||||
OPTaddress = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
@TechReport{spiraxsarco,
|
||||
author = {Spirax Sarco},
|
||||
title = {http://www.spiraxsarco.com/resources/steam-engineering-tutorials.asp},
|
||||
institution = {Spirax Sarco},
|
||||
year = {2010},
|
||||
OPTkey = {},
|
||||
OPTtype = {},
|
||||
OPTnumber = {},
|
||||
OPTaddress = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
@Book{aoe,
|
||||
title = {The Art of Electronics},
|
||||
publisher = {Cambridge},
|
||||
year = {1989},
|
||||
author = {Paul Horowitz, Winfield Hill},
|
||||
%author = {},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {},
|
||||
OPTaddress = {},
|
||||
OPTedition = {2nd},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {ISBN 0-521-37095-7},
|
||||
OPTlocalfile = {},
|
||||
OPTabstracts = {},
|
||||
}
|
||||
|
||||
@TechReport{eurothermtables,
|
||||
author = {},
|
||||
title = {Thermocouple Emf TABLES and PLATINUM 100 RESISTANCE THERMOMETER TABLES},
|
||||
institution = {Eurotherm},
|
||||
year = {1973},
|
||||
OPTkey = {},
|
||||
OPTtype = {},
|
||||
OPTnumber = {},
|
||||
OPTaddress = {},
|
||||
OPTmonth = {June},
|
||||
OPTnote = {Bulletin TT-1},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {},
|
||||
}
|
||||
|
||||
@MISC{iso639-1,
|
||||
title = "ISO 639-1: Code for the Representation of Names of Languages",
|
||||
author = "International Standardization Organization",
|
||||
howpublished = "http://www.loc.gov/standards/iso639-2/criteria1.html"
|
||||
year = "1998"
|
||||
}
|
||||
|
||||
@MISC{nano-x,
|
||||
title = "The nano-X windowing system",
|
||||
author = "Greg Haerr",
|
||||
howpublished = "http://www.microwindows.org/"
|
||||
year = "2003"
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
@MISC{X11,
|
||||
title = "The XFree86 Project, Inc",
|
||||
author = "Open Source",
|
||||
howpublished = "http://www.xfree86.org/"
|
||||
year = "1992"
|
||||
}
|
||||
|
||||
|
||||
http://www.xfree86.org/
|
||||
|
||||
@MISC{iso639-2,
|
||||
title = "ISO 639-2: Code for the Representation of Names of Languages",
|
||||
author = "International Standardization Organization",
|
||||
howpublished = "http://www.loc.gov/standards/iso639-2/criteria1.html"
|
||||
year = "1998"
|
||||
}
|
||||
|
||||
|
||||
@misc{ touchscreenprod,
|
||||
author = "M. Thirsk",
|
||||
title = "Touchscreen Production Procedure : HR~222165",
|
||||
howpublished = "Internal ETC Document",
|
||||
year = "2008" };
|
||||
|
||||
|
||||
@misc{ touchscreensoftware,
|
||||
author = "ETC Software Dept.",
|
||||
title = "Touchscreen Software released to Production : HR~222162",
|
||||
howpublished = "Internal ETC Software (medium: 2 MMC cards)",
|
||||
year = "2008" };
|
||||
|
||||
@misc{ touchscreengui,
|
||||
author = "D.J. Legge, R.P.Clark",
|
||||
title = "Touchscreen GUI Design Document : HR~222163",
|
||||
howpublished = "Internal ETC Document",
|
||||
year = "2008" };
|
||||
|
||||
|
||||
@misc{ gumstix,
|
||||
author = "Gumstix Inc",
|
||||
title = "Gumstix Home Page",
|
||||
howpublished = "WEB http://www.gumstix.com/",
|
||||
year = "2008" };
|
||||
|
||||
|
||||
@misc{ fltk,
|
||||
author = "FLTK open Source Developers",
|
||||
title = "Fast Light Toolkit",
|
||||
howpublished = "WEB http://www.fltk.org/",
|
||||
year = "2008" };
|
||||
|
||||
|
||||
@Book{ldd,
|
||||
author = {Jonathon Corbet},
|
||||
ALTeditor = {Alessandro Rubini},
|
||||
ALTeditor = {Greg Kroah-Hartman},
|
||||
title = {Linux Device Drivers},
|
||||
publisher = {O'Reilly ISBN 0-596-00590-3},
|
||||
year = {1998},
|
||||
OPTkey = {ISBN 0-596-00590-3},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {3rd},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
|
||||
@Book{bash,
|
||||
author = {Carl Albing},
|
||||
title = {Bash Cookbook},
|
||||
publisher = {O'Reilly ISBN 0-596-52678-4},
|
||||
year = {2007},
|
||||
OPTkey = {ISBN 0-596-52678-4},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {unix/linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{sedawk,
|
||||
author = {Dale Dougherty, Arnold Robbins},
|
||||
title = {Sed and Awk},
|
||||
publisher = {O'Reilly ISBN 1-56592-225-5},
|
||||
year = {1997},
|
||||
OPTkey = {ISBN 1-56592-225-5},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {unix/linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{bels,
|
||||
author = {Karim Yaghmour},
|
||||
title = {Building Embedded LINUX systems},
|
||||
publisher = {O'Reilly ISBN ISBN 0-596-00222-X},
|
||||
year = {2003},
|
||||
OPTkey = {ISBN 0-596-00222-X},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {linux},
|
||||
OPTaddress = {},
|
||||
OPTedition = {3rd},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.oreilly.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{can,
|
||||
author = {Olaf Pfeiffer},
|
||||
ALTeditor = {Andrew Ayre},
|
||||
ALTeditor = {Christian Keydel},
|
||||
title = {Embedded networking with CAN and CANopen},
|
||||
publisher = {RTC ISBN 0-929392-78-7},
|
||||
year = {2003},
|
||||
OPTkey = { },
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {Embedded Systems},
|
||||
OPTaddress = {},
|
||||
OPTedition = {1st},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {www.rtcbooks.com},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Article{article,
|
||||
author = {dd},
|
||||
title = {dd},
|
||||
journal = {dd},
|
||||
year = {2008},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTpages = {1,2},
|
||||
OPTmonth = {JAN},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@Book{sqlite,
|
||||
author = {Micheal Owens},
|
||||
title = {The definitive guide to SQLite},
|
||||
publisher = {Apres ISBN 1-59059-673-0},
|
||||
year = {2006},
|
||||
OPTkey = {},
|
||||
OPTvolume = {},
|
||||
OPTnumber = {},
|
||||
OPTseries = {Databases/SQLite},
|
||||
OPTaddress = {},
|
||||
OPTedition = {},
|
||||
OPTmonth = {},
|
||||
OPTnote = {},
|
||||
OPTannote = {},
|
||||
OPTurl = {},
|
||||
OPTdoi = {},
|
||||
OPTissn = {},
|
||||
OPTlocalfile = {},
|
||||
OPTabstract = {}
|
||||
};
|
||||
|
||||
@ -1,33 +0,0 @@
|
||||
|
||||
\documentclass[a4paper,10pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
|
||||
\input{../style}
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
|
||||
\outerhead{{\small\bf PT100 FMMD analysis}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
\title{PT100 FMMD analysis}
|
||||
\maketitle
|
||||
\input{burner_paper}
|
||||
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{vmgbibliography,mybib}
|
||||
|
||||
\today
|
||||
\end{document}
|
||||
@ -1,20 +0,0 @@
|
||||
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex common_mode_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
mv paper.pdf common_mode.pdf
|
||||
okular common_mode.pdf
|
||||
|
||||
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
common_mode_paper.tex: common_mode.tex paper.tex
|
||||
cat common_mode.tex | sed 's/common_mode\///' > common_mode_paper.tex
|
||||
|
||||
bib:
|
||||
bibtex paper
|
||||
@ -1,100 +0,0 @@
|
||||
|
||||
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\abstract{
|
||||
This paper describes how the Failure Mode Modular De-composition (FMMD) methodology
|
||||
can be applied to the problems of common mode failure
|
||||
analysis.
|
||||
%
|
||||
Common mode failures are often difficult to
|
||||
determine in embedded real time systems.
|
||||
%
|
||||
Environmental effects can lead to component failure
|
||||
modes, that can occur in separate sub-systems
|
||||
in a system, but interact to create unexpected fault.
|
||||
% WHAT IS DID
|
||||
The FMMD methodology can model and warn for two types of common mode failures.
|
||||
Failures caused by separate sub-systems relying on
|
||||
a common component, and environmental effects that can induce failure
|
||||
modes in components in separate sub-systems.
|
||||
% WHAT I FOUND
|
||||
From the FMMD data model it is possible to link the environmental effects
|
||||
and ensure determine the weak points in a design, where the failure modes may interact.
|
||||
For the component dependency case, the dependent component
|
||||
can be automatically highlighted by traversing the data model.
|
||||
% WHY YOU WOULD WANT TO READ IT
|
||||
This feature of FMMD proides another tool in the safety engineers
|
||||
repotiore, one that can shake out difficult to find common mode failure
|
||||
effects.
|
||||
}
|
||||
}
|
||||
{
|
||||
\paragraph{Chapter overview}
|
||||
This chapter describes how the % Failure Mode Modular De-composition (FMMD)
|
||||
FMMD methodology
|
||||
can be applied to the problems of common mode failure
|
||||
analysis.
|
||||
%
|
||||
Common mode failures are often difficult to
|
||||
determine in embedded real time systems.
|
||||
%
|
||||
Environmental effects can lead to component failure
|
||||
modes, that can occur in separate sub-systems
|
||||
in a system, but interact to create unexpected fault.
|
||||
% WHAT IS DID
|
||||
The FMMD methodology can model and warn for two types of common mode failures.
|
||||
Failures caused by separate sub-systems relying on
|
||||
a common component, and environmental effects that can induce failure
|
||||
modes in components in separate sub-systems.
|
||||
% WHAT I FOUND
|
||||
From the FMMD data model it is possible to link the environmental effects
|
||||
and ensure determine the weak points in a design, where the failure modes may interact.
|
||||
For the component dependency case, the dependent component
|
||||
can be automatically highlighted by traversing the data model.
|
||||
% WHY YOU WOULD WANT TO READ IT
|
||||
This feature of FMMD proides another tool in the safety engineers
|
||||
repotiore, one that can shake out difficult to find common mode failure
|
||||
effects.
|
||||
|
||||
}
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
{\huge MIGHT BECOME A PAPER IN ITS OWN RIGHT. WILL PROB BE PART OF DATA MODEL CHAPTER FOR NOW 22NOV2010 }
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
paper
|
||||
}
|
||||
{
|
||||
chapter
|
||||
}
|
||||
|
||||
|
||||
Outline the fmmd process.
|
||||
|
||||
|
||||
Show modules with common dependencies (like on a power supply, a powersupply could have a fault
|
||||
like nopisy output)
|
||||
|
||||
|
||||
Trace a theoretical example and show how FMMD detects this (common dependency - like two
|
||||
{\dc}s being depemdent on the same failure mode.
|
||||
|
||||
|
||||
Then show an environmental effect, such as temperature and how
|
||||
it can induce faults in sepatate modulkes that
|
||||
would not be obviously related.
|
||||
|
||||
Trace a theoretical example and show how FMMD detects this
|
||||
i.e. the environmental factor affecting both systems and causing a problem.
|
||||
|
||||
|
||||
what about the third way it can be affected.
|
||||
|
||||
Like a chain of relays...... all could get welded .... think about that one.....
|
||||
|
||||
@ -1,31 +0,0 @@
|
||||
|
||||
\documentclass[a4paper,10pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\input{../style}
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
|
||||
%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
\title{Modelling and Uncovering Common Mode Failures using FMMD}
|
||||
\maketitle
|
||||
\input{common_mode_paper}
|
||||
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{../vmgbibliography,../mybib}
|
||||
|
||||
\today
|
||||
\end{document}
|
||||
@ -1,15 +0,0 @@
|
||||
#
|
||||
#
|
||||
#
|
||||
# git ignore for latex
|
||||
#
|
||||
|
||||
*.aux
|
||||
*.log
|
||||
*.dvi
|
||||
*.pdf
|
||||
*.lof
|
||||
*.lot
|
||||
*.toc
|
||||
*.*~
|
||||
|
||||
@ -1,22 +0,0 @@
|
||||
|
||||
#
|
||||
# Make the propositional logic diagram a paper
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex component_failure_modes_definition_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
mv paper.pdf component_failure_modes_definition_paper.pdf
|
||||
okular component_failure_modes_definition_paper.pdf
|
||||
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
component_failure_modes_definition_paper.tex: component_failure_modes_definition.tex paper.tex
|
||||
cat component_failure_modes_definition.tex | sed 's/component_failure_modes_definition\///' > component_failure_modes_definition_paper.tex
|
||||
|
||||
|
||||
bib:
|
||||
bibtex paper
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 20 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 8.4 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 9.8 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 9.0 KiB |
File diff suppressed because it is too large
Load Diff
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 6.9 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 38 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
@ -1,43 +0,0 @@
|
||||
|
||||
\documentclass[a4paper,10pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\usepackage{lastpage}
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
\input{../style}
|
||||
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
%\renewcommand{\chaptermark}[1]{\markboth{ \emph{#1}}{}}
|
||||
\fancyhead[LO]{}
|
||||
\fancyhead[RE]{\leftmark}
|
||||
%\fancyfoot[LE,RO]{\thepage}
|
||||
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
||||
\rfoot{\today}
|
||||
\lhead{Definitions, Components, Functional Groups and Unitary State Failure Mode Sets}
|
||||
|
||||
%\outerhead{{\small\bf Definitions, Components, Functional Groups and Unitary State Failure Mode Sets}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
\title{Definitions, Components, Functional Groups and Unitary State Failure Mode Sets}
|
||||
\maketitle
|
||||
\input{component_failure_modes_definition_paper}
|
||||
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{../vmgbibliography,../mybib}
|
||||
|
||||
\today
|
||||
\end{document}
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 16 KiB |
@ -1,160 +0,0 @@
|
||||
%
|
||||
%============= Definition of {asyoulikeit} page style ======================*
|
||||
%
|
||||
% Jonathan Burch This is the terse form - expanded, formatted,
|
||||
% 20-Jan-1989 commented version in TEX$LATEX:ASYOULIKEIT.FULL
|
||||
%
|
||||
\catcode`\@=11\def\ps@asyoulikeit{\def\@oddhead{\hbox{}\lp@innerhead
|
||||
\lp@headfill\lp@middlehead\lp@headfill\lp@outerhead}\def\@evenhead
|
||||
{\hbox{}\lp@outerhead\lp@headfill\lp@middlehead\lp@headfill\lp@innerhead}
|
||||
\def\@oddfoot{\hbox{}\lp@innerfoot\lp@footfill\lp@middlefoot\lp@footfill
|
||||
\lp@outerfoot}\def\@evenfoot{\hbox{}\lp@outerfoot\lp@footfill\lp@middlefoot
|
||||
\lp@footfill\lp@innerfoot}\def\sectionmark##1{}\def\subsectionmark##1{}}
|
||||
\def\lp@innerhead{}\def\lp@middlehead{}\def\lp@outerhead{}\def\lp@innerfoot{}
|
||||
\def\lp@middlefoot{ {\thepage} }\def\lp@outerfoot{}\def\lp@headfill{\hfil}
|
||||
\def\lp@footfill{\hfil}\newcommand{\lp@linefill}{\leaders\hrule height 0.55ex
|
||||
depth -0.5ex\hfill}\newcommand{\innerhead}[1]{\def\lp@innerhead{#1}}
|
||||
\newcommand{\middlehead}[1]{\def\lp@middlehead{#1}}\newcommand{\outerhead}[1]
|
||||
{\def\lp@outerhead{#1}}\newcommand{\innerfoot}[1]{\def\lp@innerfoot{#1}}
|
||||
\newcommand{\middlefoot}[1]{\def\lp@middlefoot{#1}}\newcommand{\outerfoot}[1]
|
||||
{\def\lp@outerfoot{#1}}\newcommand{\lineheadfill}{\def\lp@headfill
|
||||
{\lp@linefill}}\newcommand{\linefootfill}{\def\lp@footfill{\lp@linefill}}
|
||||
\newcommand{\blankheadfill}{\def\lp@headfill{\hfill}}\newcommand
|
||||
{\blankfootfill}{\def\lp@footfill{\hfill}}\newcommand{\documentnumber}[1]
|
||||
{\def\lp@docno{#1}\outerhead{\lp@docno}}\def\lp@docno{}\def\@maketitlet
|
||||
{\newpage\null\vskip -14ex\hbox{}\hfill\lp@docno\vskip 13ex\begin{center}
|
||||
{\LARGE\@title\par}\vskip 1.5em{\large\lineskip .5em\begin{tabular}[t]{c}
|
||||
\@author\end{tabular}\par}\vskip 1em{\large\@date}\end{center}\par\vskip 3em}
|
||||
\def\abstract{\if@twocolumn\section*{Abstract}\else\small\begin{center}
|
||||
{\bf Abstract\vspace{-.5em}\vspace{0pt}}\end{center}\quotation\fi}\def
|
||||
\endabstract{\if@twocolumn\else\endquotation\fi}\ps@asyoulikeit\catcode`\@=12
|
||||
%
|
||||
%=========== End of {asyoulikeit} page style definition ====================*
|
||||
|
||||
\DeclareSymbolFont{AMSb}{U}{msb}{m}{n}
|
||||
\DeclareMathSymbol{\N}{\mathbin}{AMSb}{"4E}
|
||||
\DeclareMathSymbol{\Z}{\mathbin}{AMSb}{"5A}
|
||||
\DeclareMathSymbol{\R}{\mathbin}{AMSb}{"52}
|
||||
\DeclareMathSymbol{\Q}{\mathbin}{AMSb}{"51}
|
||||
\DeclareMathSymbol{\I}{\mathbin}{AMSb}{"49}
|
||||
\DeclareMathSymbol{\C}{\mathbin}{AMSb}{"43}
|
||||
|
||||
|
||||
% Page layout definitions to suit A4 paper
|
||||
\setcounter{secnumdepth}{3} \setcounter{tocdepth}{4}
|
||||
\setlength{\topmargin}{0mm}
|
||||
\setlength{\textwidth}{160mm} \setlength{\textheight}{220mm}
|
||||
\setlength{\oddsidemargin}{0mm} \setlength{\evensidemargin}{0mm}
|
||||
%
|
||||
% Local definitions
|
||||
% -----------------
|
||||
\newcommand{\eg}{{\it e.g.}}
|
||||
\newcommand{\etc}{{\it etc.}}
|
||||
\newcommand{\ie}{{\it i.e.}}
|
||||
\newcommand{\qv}{{\it q.v.}}
|
||||
\newcommand{\viz}{{\it viz.}}
|
||||
\newcommand{\degs}[1]{$#1^\circ$} % Degrees symbol
|
||||
\newcommand{\mins}[1]{$#1^{\scriptsize\prime}$} % Minutes symbol
|
||||
\newcommand{\secs}[1]{$#1^{\scriptsize\prime\prime}$} % Seconds symbol
|
||||
\newcommand{\key}[1]{\fbox{\sc#1}} % Box for keys
|
||||
\newcommand{\modulus}[1]{\ensuremathmode{|#1|}}
|
||||
\newcommand{\?}{\_\hspace{0.115em}} % Proper spacing for
|
||||
% underscore
|
||||
\newcommand{\rev}{PA5}
|
||||
\newcommand{\etcdoc}{ HR222975 }
|
||||
\newcommand{\wlc}{{Water~Level~Controller~Unit}}
|
||||
\newcommand{\ft}{{\em 4 $\rightarrow$ 20mA } }
|
||||
\newcommand{\tds}{TDS Daughterboard}
|
||||
\newcommand{\oc}{$^{o}{C}$}
|
||||
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
|
||||
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
|
||||
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
|
||||
%----- Display example text (#1) in typewriter font
|
||||
|
||||
%\newcommand{\example}[1]{\\ \smallskip\hspace{1in}{\tt #1}\hfil\\
|
||||
% \smallskip\noindent}
|
||||
%
|
||||
%----- Enclose text (#2) in ruled box of given thickness (#1)
|
||||
|
||||
\def\boxit#1#2{\vbox{\hrule height #1pt\hbox{\vrule width #1pt\hskip 5pt
|
||||
\vbox{\vskip 5pt #2 \vskip 5pt}\hskip 5pt
|
||||
\vrule width #1pt}\hrule height #1pt}}
|
||||
|
||||
%----- Display boxed warning text (#1)
|
||||
|
||||
\def\warning#1{\bigskip
|
||||
\setbox1=\vbox{\tolerance=5000\parfillskip=0pt
|
||||
\hsize=3in\noindent#1}
|
||||
\centerline{\boxit{1.0}{\box1}}
|
||||
\bigskip}
|
||||
|
||||
%----- Definitions to aid display of help text
|
||||
% (modelled on \item and \itemitem)
|
||||
|
||||
\def\helpindent#1{\setbox2=\hbox to\parindent{{\it #1}\hfil}
|
||||
\indent\llap{\box2}\ignorespaces}
|
||||
\def\helpitem{\parindent=70pt\par\hang\helpindent}
|
||||
\def\helpitemitem{\parindent=70pt\par\indent \parindent=80pt
|
||||
\hangindent2\parindent \helpindent}
|
||||
|
||||
%----- Tables and footnotes to tables
|
||||
%
|
||||
\newcommand{\spacerA}{\rule{0mm}{4mm}}
|
||||
\newcommand{\spacerB}{\rule[-2mm]{0mm}{5mm}}
|
||||
\footnotesep=5mm
|
||||
\renewcommand{\footnoterule}{{\small Notes:}}
|
||||
|
||||
%% Robin 01AUG2008
|
||||
%%
|
||||
|
||||
\newcounter{examplec}
|
||||
\newcounter{definitionc}
|
||||
\newcounter{summaryc}
|
||||
|
||||
%\@addtoreset{examplec}{chapter}\renewcommand\theexamplec{\thechapter.arabic{examplec}}
|
||||
%\@addtoreset{definitionc}{chapter}
|
||||
%\@addtoreset{summaryc}{chapter}
|
||||
|
||||
%\renewcommand\examplec{\arabic{examplec}}
|
||||
|
||||
%\newenvironment{example}
|
||||
%{
|
||||
% \stepcounter{examplec} \vspace{10pt} \normalfont\bfseries Example:\normalfont\[{\arabic{chapter}.\arabic{examplec}}\]
|
||||
% \normalfont \begin{quote}}{\end{quote}\par}
|
||||
%\newenvironment{definition}
|
||||
%\newenvironment{example}
|
||||
%{
|
||||
% \stepcounter{examplec} \vspace{10pt} \normalfont\bfseries Example:\normalfont\[{\arabic{chapter}.\arabic{examplec}}\]
|
||||
% \normalfont \begin{quote}}{\end{quote}\par}
|
||||
\usepackage{amsthm}
|
||||
|
||||
\newtheorem{example}{Example:}
|
||||
\newtheorem{definition}{Definition:}
|
||||
\newtheorem*{summary}{Summary:}
|
||||
|
||||
|
||||
%
|
||||
\newcommand{\Fam}{{\mathbb F}}
|
||||
\newcommand{\Pow}{{\mathbb P}}
|
||||
\newcommand{\Dis}{{\vee}}
|
||||
\newcommand{\Con}{{\wedge}}
|
||||
\newcommand{\FMEA}{{\bowtie}}
|
||||
%
|
||||
\newcommand{\Nat}{{\mathbb N}}
|
||||
\newcommand{\Real}{{\mathbb R}}
|
||||
\newcommand{\Complex} {{\mathbb C}}
|
||||
\newcommand{\Rational} {{\mathbb Q}}
|
||||
%
|
||||
%\newenvironment{example}
|
||||
%{ \stepcounter{examplec} \vspace{10pt} \normalfont\bfseries Example:(\arabic{chapter}.\arabic{examplec})
|
||||
% \normalfont \begin{quote}}{\end{quote}\par}
|
||||
|
||||
%
|
||||
%\newenvironment{definition}
|
||||
%{ \stepcounter{definitionc} \vspace{10pt} \normalfont\bfseries Definition:(\arabic{chapter}.\arabic{definitionc})
|
||||
% \normalfont \begin{quote}}{\end{quote}\par}
|
||||
%
|
||||
%\newenvironment{summary}
|
||||
%{ \vspace{10pt} \normalfont\bfseries Summary:
|
||||
% \normalfont \begin{quote}}{\end{quote}\par}
|
||||
%
|
||||
@ -1,45 +0,0 @@
|
||||
# NOT FINISHED YET !!!!
|
||||
|
||||
# define a factorial function
|
||||
# gives 1 for negative values as well
|
||||
define f(x) {
|
||||
if (x>1) {
|
||||
return (x * f (x-1))
|
||||
}
|
||||
return (1)
|
||||
}
|
||||
|
||||
# determine how many combinations would be dis-allowed
|
||||
# from a cardinality constrained powerset
|
||||
# given unitary state failure mode conditions
|
||||
define uc(c,k,x) {
|
||||
aa = 0;
|
||||
#for(i=2; i<=c; i++) aa += k * f(k)/(f(i)*f(k-i));
|
||||
if ( c>2 ) {
|
||||
return aa + uc(c-1,k,x);
|
||||
}
|
||||
return aa;
|
||||
}
|
||||
|
||||
# cardinality constrained powerset
|
||||
# how many combinations of cardinality k
|
||||
# can we have from c number of components
|
||||
# with x number of failure modes
|
||||
define ccps(c,k,x) {
|
||||
return f(k*x)/(f(c)*f(k*x-c))
|
||||
}
|
||||
|
||||
|
||||
|
||||
define us(c,k,x) {
|
||||
a=0;
|
||||
for(i=1;i<=c;i++) a += ccps(i,c,x);
|
||||
# a now holds all combinations
|
||||
# we must now subtract those combinations
|
||||
# dis-allowed under unitary state conditions.
|
||||
a -= uc(cc,c,x);
|
||||
return a;
|
||||
}
|
||||
|
||||
|
||||
us(2,3,3);
|
||||
15
old_thesis/components_as_plds/.gitignore
vendored
15
old_thesis/components_as_plds/.gitignore
vendored
@ -1,15 +0,0 @@
|
||||
#
|
||||
#
|
||||
#
|
||||
# git ignore for latex
|
||||
#
|
||||
|
||||
*.aux
|
||||
*.log
|
||||
*.dvi
|
||||
*.pdf
|
||||
*.lof
|
||||
*.lot
|
||||
*.toc
|
||||
*.*~
|
||||
|
||||
@ -1,205 +0,0 @@
|
||||
%\documentclass[a4paper,10pt]{article}
|
||||
%\usepackage{graphicx}
|
||||
%
|
||||
%%opening
|
||||
%\title{Electronic Component Failure Analysis}
|
||||
%\author{R.P. Clark ~ Energy Technology Control}
|
||||
%
|
||||
%\bibliographystyle{unsrt}
|
||||
%
|
||||
%\begin{document}
|
||||
%
|
||||
%\maketitle
|
||||
%
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
This chapter describes the analysis of electrical components in terms of their operational and failure modes.
|
||||
When analysed a component can be represented by a set of `fault modes'.
|
||||
The fault modes can be considered as logical states for the component.
|
||||
These can be represented as
|
||||
logical states (respresented as contours) in a `propositional logic diagram'.
|
||||
Components can then be combined by bringing the contours from
|
||||
several components onto the same diagram.
|
||||
Logical analysis of how the failure modes of the components interact
|
||||
in a sub-system or module, can now be undertaken.
|
||||
\end{abstract}
|
||||
}
|
||||
{}
|
||||
|
||||
|
||||
%
|
||||
\section{Introduction}
|
||||
|
||||
Every component in a electrical circuit may fail in several ways.
|
||||
The most obvious ways for them to fail are that legs of the
|
||||
circuit become disconnected or are shorted.
|
||||
|
||||
Components may fail internally. Some may have failure modes due to environmental factors.
|
||||
% SPACE SOLDER EVAPORATING
|
||||
% TEMPERATURE EFFECTS SUCH AS INACCURACY, LEAKAGE OF CURRENT ETC
|
||||
|
||||
Each component thus has a set of possible failure modes.
|
||||
Looking at this independently of cause, we can in the worst case
|
||||
consider that any of these errors could occur at any time.
|
||||
|
||||
In analysing a circuit we should take into consideration
|
||||
all possible failure modes, and where appropriate, how
|
||||
these failure modes will affect other components in the circuit.
|
||||
|
||||
Safety analysis of components forming critical circuitry,
|
||||
is currently performed using scenario based test cases\cite{en298}, % \cite{gastec}, \cite{tuv}.
|
||||
These involve experts checking a circuit for failure modes on a circuit and how these will
|
||||
affect the system, based on their expertise.
|
||||
Because this is a human process,
|
||||
this means that unlikely or very rare test cases may not be considered, but also
|
||||
that some test cases may be missed.
|
||||
By taking all possible failure modes and laying these out in a logic diagram,
|
||||
a computer can check that an analysis entry has been made for all
|
||||
failure mode combinations deemed possible in the diagram.
|
||||
|
||||
This paper is concerned with the analysis phase that takes a component
|
||||
and from it produces a set of failure modes. PLD diagram configurations
|
||||
will be dealt with in the chapter \ref{pldconfig}.
|
||||
|
||||
|
||||
\section{A resistor}
|
||||
|
||||
A resistor is a simple component, and according to MIL1991 has two failure modes OPEN and SHORT.
|
||||
Let us consider what can happen to a resistor soldered onto a PCB.
|
||||
It could become de-soldered at one pin or the other. The effect would be the same. The resistor would appear to
|
||||
be OPEN circuit.This again would create an OPEN circuit.
|
||||
It could become shorted by some foreign material, or in the production soldering process.
|
||||
This again would have the same effect. It would appear to be a SHORT circuit.
|
||||
It could be overstressed and burnt out, (by the application of an out of spec current for instance).
|
||||
Resistors typically drift slightly in value with temperature. For some applications this may not be important.
|
||||
The manufacturers data-sheet will describe the temperature drift co-effecients and operating ranges.
|
||||
|
||||
\paragraph{discusion on $P\_CHANGE$ as a resistor failure mode.}
|
||||
HERE reference EN298 and RAC.
|
||||
Talk about the differences, why en298 only looks for OPEN in most cases
|
||||
and OPEN AND SHORT in one but not $P\_CHANGE$ .
|
||||
RAC gives $P\_CHANGE$ for single resistors but not for resistor networks.
|
||||
It is interesting to determine why this is.
|
||||
A network of resistors would be less prone to batch
|
||||
problems where a parameter drift would all be in the sam direction (with age perhaps)
|
||||
.
|
||||
But also a network of resistors means a load sharing where resistors will be
|
||||
under less electrical stress.
|
||||
|
||||
This is because components in EN298 must be 60\% under any environemntal electrical or mechanical
|
||||
stress safe rating as given by a manufacturer.
|
||||
Thus a resistor rated for 50V would not be allowed in a ciruit with a 100V rail,
|
||||
even though in normal operation, the resistor would never have more than say 30V applied to it.
|
||||
|
||||
For most safety critical applications components are downrated, and for resistors this means $P\_CHANGE$
|
||||
does not have to be cosidered.
|
||||
|
||||
|
||||
We can represent our resistor then to be in four operational states, $R_s = \{ OK, OPEN, SHORT, P\_CHANGE \}$.
|
||||
Because we are interested in failure analysis we assume that every component has an OK state
|
||||
but this is not of interest. When every component on a board is in the $OK$ state
|
||||
the sub-system will function correctly.
|
||||
We are interested in failures and how that affects the sub-system, so we
|
||||
can ignore the $OK$ state and represent our resistor thus for the purpose of fault analysis.
|
||||
|
||||
$$R_s = \{ OPEN, SHORT, P\_CHANGE \}$$
|
||||
|
||||
|
||||
This can be represented in a PLD thus
|
||||
IMAGE HERE
|
||||
|
||||
For a resistor in a safety critical regime demanding rigorous downrating, we can model our
|
||||
rsistor with
|
||||
|
||||
IMAGE HERE
|
||||
$$R_s = \{ OPEN, SHORT \}$$
|
||||
|
||||
|
||||
\section{ PNP Transistor }
|
||||
|
||||
Each leg open : each leg shorted all combinations.
|
||||
Dud no HFE.
|
||||
TEMPERATURE, operating range
|
||||
{ \huge Look in MIL 1991}
|
||||
Resultant failure modes ==
|
||||
|
||||
\section { IR Photo-diode}
|
||||
|
||||
|
||||
each leg open, each leg shorted combination.
|
||||
NO effect or always on.
|
||||
|
||||
Resultant failure modes ==
|
||||
|
||||
|
||||
% \section{On / Off Switch}
|
||||
|
||||
% A simple on / off switch can fail in two ways again, OPEN or SHORT.
|
||||
|
||||
|
||||
%
|
||||
% \begin{figure}
|
||||
% \centering
|
||||
% \includegraphics[scale=0.4]{components_as_plds/ir_det.eps}
|
||||
% % ir_det.eps: 0x0 pixel, 300dpi, 0.00x0.00 cm, bb=0 0 582 304
|
||||
% \caption{IR detector circuit}
|
||||
% \label{fig:irdet}
|
||||
% \end{figure}
|
||||
%
|
||||
%
|
||||
% \section { Sample circuit : An Infra Red Detector }
|
||||
%
|
||||
% This circuit for discussion is for a infra-red detector (see figure \ref{fig:ir_det}).
|
||||
% It simply draws current through the PNP resistor when infra-red light falls onto the detector.
|
||||
% When IR light is detected at the detector, TR1 (IR photo transistor) turns on, lowering the voltage at the base of TR2.
|
||||
% This turns on TR2 which raise the voltage at the collector of TR2.
|
||||
% A high voltage at the collector of TR2 thus indicates the presence of IR light on the detector.
|
||||
% This could be connected to a visible LED or a micro-processor.
|
||||
% For the purpose of discussion we are only interested in the detection part of this circuit.
|
||||
% By analysing the failure modes for all its components
|
||||
% we can can combine the failure modes for all the parts,
|
||||
% and analyse how these failures affect the detector.
|
||||
% We can also look at how the diagrams can help in the analysis
|
||||
% phase.
|
||||
%
|
||||
% \subsection { IR detector in use }
|
||||
%
|
||||
% In use the IR photo transistor would be mounted on a probe, used to detect IR.
|
||||
% The user would switch the detector on, check that the ON LED was lit,
|
||||
% and then use the probe. On detection of IR at the probe the IR detect LED will light.
|
||||
% This is a real circuit and has been used for debugging
|
||||
% and validating IR position detection circuitry.
|
||||
%
|
||||
% %\bibliography{vmgbibliography,mybib}
|
||||
% %Typeset in \ \ {\huge \LaTeX} \ \ on \ \ \today
|
||||
% %\section{}
|
||||
% %\end{document}
|
||||
%
|
||||
% \subsection{ Components and Fault Modes }
|
||||
%
|
||||
% Below is a list of the failure modes that can occur in the
|
||||
% circuit above. A detailed discussion on determing the possible fault modes
|
||||
% for components are given in chapter \ref{chapfaultdet}.
|
||||
% Failure modes here have been determeined from the MIL 1991\ref{MIL1991} handbook.
|
||||
%
|
||||
% \begin{itemize}
|
||||
% \item TR1 = \{ OPEN\_CE, SHORT\_CE \}
|
||||
% \item TR2 = \{ OPEN\_CE, SHORT\_CE, SHORT\_BE SHORT\_BC\}
|
||||
% \item R1 = \{ OPEN\_R, SHORT\_R \}
|
||||
% \item R2 = \{ OPEN\_R, SHORT\_R \}
|
||||
% \item D1 = \{ OPEN\_D, SHORT\_D \}
|
||||
% \item D2 = \{ OPEN\_D, SHORT\_D \}
|
||||
% \item B1 = \{ OPEN\_B, FLAT\_B \}
|
||||
% \item SW1 = \{ ALWAYSOPEN\_SW1, ALWAYSCLOSED\_SW1 \}
|
||||
% \end{itemize}
|
||||
%
|
||||
% With this information we can now begin to analyse the circuit.
|
||||
% Firstly we can look at the overall effect of any one component
|
||||
% on the rest of the circuit. After that we can look at combinations
|
||||
% of component failure modes.
|
||||
%
|
||||
% \subsection{FMEA : Failure Mode Effcets Analysis}
|
||||
%
|
||||
@ -1,277 +0,0 @@
|
||||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<dia:diagram xmlns:dia="http://www.lysator.liu.se/~alla/dia/">
|
||||
<dia:diagramdata>
|
||||
<dia:attribute name="background">
|
||||
<dia:color val="#ffffff"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="pagebreak">
|
||||
<dia:color val="#000099"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="paper">
|
||||
<dia:composite type="paper">
|
||||
<dia:attribute name="name">
|
||||
<dia:string>#A4#</dia:string>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="tmargin">
|
||||
<dia:real val="2.8222000598907471"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="bmargin">
|
||||
<dia:real val="2.8222000598907471"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="lmargin">
|
||||
<dia:real val="2.8222000598907471"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="rmargin">
|
||||
<dia:real val="2.8222000598907471"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="is_portrait">
|
||||
<dia:boolean val="true"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="scaling">
|
||||
<dia:real val="1"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="fitto">
|
||||
<dia:boolean val="false"/>
|
||||
</dia:attribute>
|
||||
</dia:composite>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="grid">
|
||||
<dia:composite type="grid">
|
||||
<dia:attribute name="width_x">
|
||||
<dia:real val="1"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="width_y">
|
||||
<dia:real val="1"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="visible_x">
|
||||
<dia:int val="1"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="visible_y">
|
||||
<dia:int val="1"/>
|
||||
</dia:attribute>
|
||||
<dia:composite type="color"/>
|
||||
</dia:composite>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="color">
|
||||
<dia:color val="#d8e5e5"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="guides">
|
||||
<dia:composite type="guides">
|
||||
<dia:attribute name="hguides"/>
|
||||
<dia:attribute name="vguides"/>
|
||||
</dia:composite>
|
||||
</dia:attribute>
|
||||
</dia:diagramdata>
|
||||
<dia:layer name="Background" visible="true">
|
||||
<dia:object type="Standard - Ellipse" version="0" id="O0">
|
||||
<dia:attribute name="obj_pos">
|
||||
<dia:point val="5.25,3.7"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="obj_bb">
|
||||
<dia:rectangle val="5.2,3.65;12.3,15.3"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_corner">
|
||||
<dia:point val="5.25,3.7"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_width">
|
||||
<dia:real val="7"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_height">
|
||||
<dia:real val="11.550000000000001"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="border_color">
|
||||
<dia:color val="#190707"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="show_background">
|
||||
<dia:boolean val="false"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="line_style">
|
||||
<dia:enum val="2"/>
|
||||
</dia:attribute>
|
||||
</dia:object>
|
||||
<dia:object type="Standard - Ellipse" version="0" id="O1">
|
||||
<dia:attribute name="obj_pos">
|
||||
<dia:point val="13.65,3.7"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="obj_bb">
|
||||
<dia:rectangle val="13.6,3.65;21.05,15.5"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_corner">
|
||||
<dia:point val="13.65,3.7"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_width">
|
||||
<dia:real val="7.3500000000000014"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_height">
|
||||
<dia:real val="11.749999999999996"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="border_color">
|
||||
<dia:color val="#190707"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="show_background">
|
||||
<dia:boolean val="false"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="line_style">
|
||||
<dia:enum val="2"/>
|
||||
</dia:attribute>
|
||||
</dia:object>
|
||||
<dia:object type="Standard - Text" version="1" id="O2">
|
||||
<dia:attribute name="obj_pos">
|
||||
<dia:point val="6.3,2.7"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="obj_bb">
|
||||
<dia:rectangle val="6.3,1.3125;10.645,3.7375"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="text">
|
||||
<dia:composite type="text">
|
||||
<dia:attribute name="string">
|
||||
<dia:string>#OPEN#</dia:string>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="font">
|
||||
<dia:font family="sans" style="0" name="Helvetica"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="height">
|
||||
<dia:real val="2.1000000000000001"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="pos">
|
||||
<dia:point val="6.3,2.7"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="color">
|
||||
<dia:color val="#000000"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="alignment">
|
||||
<dia:enum val="0"/>
|
||||
</dia:attribute>
|
||||
</dia:composite>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="valign">
|
||||
<dia:enum val="3"/>
|
||||
</dia:attribute>
|
||||
</dia:object>
|
||||
<dia:object type="Standard - Text" version="1" id="O3">
|
||||
<dia:attribute name="obj_pos">
|
||||
<dia:point val="6.95,2.55"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="obj_bb">
|
||||
<dia:rectangle val="6.95,2.15;6.95,3.35"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="text">
|
||||
<dia:composite type="text">
|
||||
<dia:attribute name="string">
|
||||
<dia:string>##</dia:string>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="font">
|
||||
<dia:font family="sans" style="0" name="Helvetica"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="height">
|
||||
<dia:real val="0.80000000000000004"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="pos">
|
||||
<dia:point val="6.95,2.55"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="color">
|
||||
<dia:color val="#000000"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="alignment">
|
||||
<dia:enum val="0"/>
|
||||
</dia:attribute>
|
||||
</dia:composite>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="valign">
|
||||
<dia:enum val="3"/>
|
||||
</dia:attribute>
|
||||
</dia:object>
|
||||
<dia:object type="Standard - Text" version="1" id="O4">
|
||||
<dia:attribute name="obj_pos">
|
||||
<dia:point val="14.48,2.7075"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="obj_bb">
|
||||
<dia:rectangle val="14.4372,1.27719;19.8175,3.83062"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="text">
|
||||
<dia:composite type="text">
|
||||
<dia:attribute name="string">
|
||||
<dia:string>#SHORT#</dia:string>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="font">
|
||||
<dia:font family="sans" style="0" name="Helvetica"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="height">
|
||||
<dia:real val="2.1000000000000001"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="pos">
|
||||
<dia:point val="14.48,2.7075"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="color">
|
||||
<dia:color val="#000000"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="alignment">
|
||||
<dia:enum val="0"/>
|
||||
</dia:attribute>
|
||||
</dia:composite>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="valign">
|
||||
<dia:enum val="3"/>
|
||||
</dia:attribute>
|
||||
</dia:object>
|
||||
<dia:object type="Standard - Ellipse" version="0" id="O5">
|
||||
<dia:attribute name="obj_pos">
|
||||
<dia:point val="22.475,3.925"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="obj_bb">
|
||||
<dia:rectangle val="22.425,3.875;29.875,15.725"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_corner">
|
||||
<dia:point val="22.475,3.925"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_width">
|
||||
<dia:real val="7.3500000000000014"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="elem_height">
|
||||
<dia:real val="11.749999999999996"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="border_color">
|
||||
<dia:color val="#190707"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="show_background">
|
||||
<dia:boolean val="false"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="line_style">
|
||||
<dia:enum val="2"/>
|
||||
</dia:attribute>
|
||||
</dia:object>
|
||||
<dia:object type="Standard - Text" version="1" id="O6">
|
||||
<dia:attribute name="obj_pos">
|
||||
<dia:point val="22.99,2.8675"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="obj_bb">
|
||||
<dia:rectangle val="22.99,1.43719;29.3303,3.99063"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="text">
|
||||
<dia:composite type="text">
|
||||
<dia:attribute name="string">
|
||||
<dia:string>#T_DRIFT#</dia:string>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="font">
|
||||
<dia:font family="sans" style="0" name="Helvetica"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="height">
|
||||
<dia:real val="2.1000000000000001"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="pos">
|
||||
<dia:point val="22.99,2.8675"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="color">
|
||||
<dia:color val="#000000"/>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="alignment">
|
||||
<dia:enum val="0"/>
|
||||
</dia:attribute>
|
||||
</dia:composite>
|
||||
</dia:attribute>
|
||||
<dia:attribute name="valign">
|
||||
<dia:enum val="3"/>
|
||||
</dia:attribute>
|
||||
</dia:object>
|
||||
</dia:layer>
|
||||
</dia:diagram>
|
||||
@ -1,24 +0,0 @@
|
||||
|
||||
#
|
||||
# Make the propositional logic diagram a paper
|
||||
#
|
||||
SOURCE = eulerg.tex
|
||||
|
||||
paper: paper.tex eulerg_paper.tex $(SOURCE)
|
||||
#cat introduction.tex | sed s/chapter/paper/ > introduction.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
mv paper.pdf eulerg_paper.pdf
|
||||
okular eulerg_paper.pdf
|
||||
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
eulerg_paper.tex: eulerg.tex paper.tex $(SOURCE)
|
||||
cat eulerg.tex | sed 's/eulerg\///' > eulerg_paper.tex
|
||||
|
||||
|
||||
bib: $(SOURCE)
|
||||
bibtex paper
|
||||
|
||||
@ -1,336 +0,0 @@
|
||||
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\abstract{
|
||||
This paper discusses representing Euler Diagrams as graphs, or sets of relationships.
|
||||
By representing Euler diagrams in this way,
|
||||
algorithms to investigate properties of the diagrams, are possible, without
|
||||
having to resort
|
||||
to extra unnecessary CPU expensive area operations on the concrete diagrams.
|
||||
|
||||
The graph representations presented here form the basis for several algorithms
|
||||
and time saving procedures, implemented in the FMMD analysis tool.
|
||||
|
||||
}
|
||||
}
|
||||
{ %% Introduction
|
||||
\section{Introduction}
|
||||
This chapter discusses representing Euler Diagrams as graphs, or sets of relationships.
|
||||
By representing Euler diagrams in this way,
|
||||
algorithms to investigate properties of the diagrams, are possible, without
|
||||
having to resort
|
||||
to extra unnecessary CPU expensive area operations on the concrete diagrams.
|
||||
|
||||
The graph representations presented here form the basis for several algorithms
|
||||
and time saving procedures, implemented in the FMMD analysis tool.
|
||||
}
|
||||
|
||||
|
||||
\section{Introduction : Euler Diagram }
|
||||
|
||||
Classical Euler diagrams consist of closed curves in the plane which are used to represent sets.
|
||||
The spatial relationship between the curves defines the set theoretic relationships, as defined below.
|
||||
\begin{itemize}
|
||||
\item Intersection - if the curves defining the area within curves overlap
|
||||
\item Sub-set - if a curve is enclosed by another
|
||||
\item disjoint - if the curves are separate
|
||||
\end{itemize}
|
||||
|
||||
The definitions above allow us to read an Euler diagram
|
||||
and write down set theory equations.
|
||||
The interest here though, is to define relationships between the contours, that allow
|
||||
processing and parsing of the diagram without resorting to extra area operations in the concrete plane.
|
||||
|
||||
\section{Defining `pair-wise intersection' \\ and `enclosure'}
|
||||
|
||||
\begin{figure}[ht]
|
||||
\centering
|
||||
\subfigure[Euler Diagram]{
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./eulerg/eulerg1.jpg}
|
||||
\label{fig:subfig1}
|
||||
}
|
||||
|
||||
\subfigure[Graph Representation]{
|
||||
\includegraphics[width=50pt,keepaspectratio=true]{./eulerg/eulerg_g.jpg}
|
||||
\label{fig:subfig2}
|
||||
}
|
||||
|
||||
% \subfigure[Subfigure 3 caption]{
|
||||
% \includegraphics[width=100pt,keepaspectratio=true]{./eulerg/eulerg1.jpg}
|
||||
% \label{fig:subfig3}
|
||||
% }
|
||||
|
||||
\caption{An Euler Diagram showing enclosure and Pair-wise Intersection}
|
||||
\label{fig:eulerg1}
|
||||
|
||||
\end{figure}
|
||||
|
||||
|
||||
|
||||
The set theory term `intersection' can apply to both the curves overlapping and to the sub-set case.
|
||||
Intersection in a concrete diagram can mean two curves bisecting.
|
||||
For instance in figure \ref{fig:eulerg1} the set theoretic intersection between
|
||||
$A$ and $B$ exists, even though the curves do not bisect in the concrete plane.
|
||||
|
||||
$$ A \cap B \neq \emptyset $$
|
||||
|
||||
as does the intersection $D$ and $E$
|
||||
|
||||
$$ D \cap E \neq \emptyset $$
|
||||
|
||||
Clearly though these intersections are different, because
|
||||
in the $A$, $B$ case
|
||||
$ A \backslash B = \emptyset \wedge B \backslash A \neq \emptyset $
|
||||
This is not the case for $D$, $E$ where:
|
||||
$ D \backslash E \neq \emptyset \wedge E \backslash D \neq \emptyset $.
|
||||
Another way of expressing this is that $D \cap E \neq \emptyset$ and
|
||||
$ A \subset B$.
|
||||
|
||||
\paragraph{Enclosure}
|
||||
To distinguish between these we can term the $A$, $B$ case to be
|
||||
$A$ `enclosed' by $B$. We can express this as a directed relationship.
|
||||
|
||||
$$ B {\enc} A $$
|
||||
|
||||
%\clearpage
|
||||
\paragraph{Pair-wise Intersection}
|
||||
In the $D$, $E$ case we have
|
||||
|
||||
We can say that where the areas defined by the curves intersect but no one curve encloses the
|
||||
other, we can term this `pair-wise intersection'.
|
||||
We can express this as a non directed relationship.
|
||||
|
||||
$$ D \pin E $$
|
||||
|
||||
|
||||
\paragraph{Mutual exclusivity of `pair-wise intersection' and `enclosure'}
|
||||
|
||||
Clearly these two properties are mutually exclusive. No
|
||||
contour can be both pair-wisely intersected and enclosed with the same contour.
|
||||
Also enclosure, is transitive. That is to say if B encloses A, and A encloses C
|
||||
then B encloses C, see figure \ref{fig:eulerg_enc}.
|
||||
|
||||
\begin{definition}
|
||||
\label{def:mutex}
|
||||
No contour can be both pair-wisely intersected and enclosed with the same contour.
|
||||
\end{definition}
|
||||
|
||||
\clearpage
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
|
||||
\subfigure[Euler Diagram]{
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./eulerg/eulerg_enc.jpg}
|
||||
% eulerg_enc.jpg: 315x269 pixel, 72dpi, 11.11x9.49 cm, bb=0 0 315 269
|
||||
\label{eulerenc}
|
||||
}
|
||||
|
||||
\subfigure[Graph Representation]{
|
||||
\includegraphics[width=100pt,bb=0 0 240 43,keepaspectratio=true]{./eulerg/eulerg_enc_g.jpg}
|
||||
% eulerg_enc_g.jpg: 240x43 pixel, 72dpi, 8.47x1.52 cm, bb=0 0 240 43
|
||||
\label{graphenc}
|
||||
}
|
||||
\caption{Enclosure, a transitive relationship}
|
||||
\label{fig:eulerg_enc}
|
||||
\end{figure}
|
||||
|
||||
$$ B {\enc} A \wedge A {\enc} C \implies B {\enc} C $$
|
||||
|
||||
\begin{definition}
|
||||
\label{def:enctrans}
|
||||
Enclosure relationships are transitive.
|
||||
\end{definition}
|
||||
|
||||
|
||||
\pagebreak[1]
|
||||
\section{Representing Euler Diagrams \\ as sets of relationships}
|
||||
|
||||
The diagram in figure \ref{fig:eulerg1} can be represented by the following relationships.
|
||||
|
||||
$$ B {\enc} A $$
|
||||
$$ D {\pin} E $$
|
||||
|
||||
|
||||
The diagram in figure \ref{fig:eulerg_enc} can be represented by the following relationships.
|
||||
|
||||
$$ B {\enc} A $$
|
||||
$$ A {\enc} C $$
|
||||
|
||||
\section{Representing Euler diagrams as graphs}
|
||||
|
||||
As the relationships {\em enclosure} and {\em pair-wise intersection} are mutually exclusive
|
||||
and {\em enclosure} is transitive and {\em pair-wise intersection} is not, we can represent
|
||||
an {\em enclosure} relationship as a directed vertice and
|
||||
{\pic} as non-directed on the same graph.
|
||||
Figures \ref{fig:eulerg1} and \ref{fig:eulerg_enc} show Euler diagrams with corresponding
|
||||
graphs. The next section will introduce the concept of a {\pic}
|
||||
and will present graphs where both enclosure and pair-wise
|
||||
intersection are represented on the same graph.
|
||||
|
||||
\pagebreak[1]
|
||||
\section{The {\pic}}
|
||||
In graph theory a node is said to be reachable from another node
|
||||
if you can start at the one node, travel via the edges
|
||||
and arrive at the other.
|
||||
Contours may be connected via `pair-wise intersection' relationships to form
|
||||
`chains' of contours reachable by pair-wise intersection.
|
||||
These are termed {\pic}s.
|
||||
Figure \ref{fig:eulerg_pic} shows a {\pic} consisting of contours $M,N,O,P$ and $Q$.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,keepaspectratio=true]{./eulerg/eulerg_pic.jpg}
|
||||
% eulerg_pic.jpg: 955x286 pixel, 72dpi, 33.69x10.09 cm, bb=0 0 955 286
|
||||
\caption{{\pic} with Enclosure}
|
||||
\label{fig:eulerg_pic}
|
||||
\end{figure}
|
||||
|
||||
%\textbf{rule:}
|
||||
\begin{definition}
|
||||
\label{def:encpic}
|
||||
If any contour in a {\pic} is enclosed by any contour not belonging to the chain,
|
||||
all the contours within the
|
||||
{\pic} will be enclosed by it.
|
||||
\end{definition}
|
||||
|
||||
Note that any contour
|
||||
which bisects another contour in a {\pic}
|
||||
becomes part of the pair-wise~intersection~chain.
|
||||
% Hmmmm thats true but a better way to say it ????
|
||||
%The diagram in figure \ref{fig:eulerg_enc} can be represented by the following relationships.
|
||||
|
||||
|
||||
\vbox{
|
||||
The diagram in figure \ref{fig:eulerg_pic} can be represented by the following relationships.
|
||||
|
||||
$$ M {\pin} N $$
|
||||
$$ N {\pin} O $$
|
||||
$$ O {\pin} P $$
|
||||
$$ O {\pin} Q $$
|
||||
$$ Q {\enc} P $$
|
||||
$$ A {\enc} M $$
|
||||
$$ A {\enc} N $$
|
||||
$$ A {\enc} O $$
|
||||
$$ A {\enc} P $$
|
||||
$$ A {\enc} Q $$
|
||||
}
|
||||
|
||||
To form the {\pic} we can follow
|
||||
reachable pair-wise intersection relationships.
|
||||
|
||||
$ M {\pin} N {\pin} O {\pin} P $ are part of the same chain.
|
||||
following from $O$, $O {\pin} Q$.
|
||||
Thus by the definition of being reachable by pair-wise intersection relationships,$M,N,O,P,Q$
|
||||
are in the same {\pic}, even though $Q$ encloses $P$.
|
||||
|
||||
We can define this {\pic} as $PIC1$ as a set of contours.
|
||||
|
||||
$$ PIC1 = \{ M,N,O,P,Q \} $$
|
||||
|
||||
Contour $A$, by virtue of not bisecting any contour in the pair-wise intersection
|
||||
chain $PIC1$, does not belong to $PIC1$. Because it encloses one of the contours, it
|
||||
encloses all contours in the chain.
|
||||
Knowing this can save on unnecessary area operations on the concrete diagram.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,bb=0 0 330 158,keepaspectratio=true]{./eulerg/eulerg_pic_g.jpg}
|
||||
% eulerg_pic_g.jpg: 330x158 pixel, 72dpi, 11.64x5.57 cm, bb=0 0 330 158
|
||||
\caption{Pair-wise Intersection chain PIC1 as a graph}
|
||||
\label{fig:eulerg_pic_g}
|
||||
\end{figure}
|
||||
% \subsection{The Pair-wise intersection chain PIC1}
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[width=200pt,bb=0 0 955 286,keepaspectratio=true]{./eulerg_pic_g.jpg}
|
||||
% % eulerg_pic.jpg: 955x286 pixel, 72dpi, 33.69x10.09 cm, bb=0 0 955 286
|
||||
% \caption{The pair-wise Intersection PIC1 as a graph}
|
||||
% \label{fig:eulerg_pic1}
|
||||
% \end{figure}
|
||||
|
||||
|
||||
Figure \ref{fig:eulerg_pic_g} only shows the {\pic}, but does not show the contour ($A$)
|
||||
enclosing $PIC1$. Figure \ref{fig:eulerg_pic_g_a}
|
||||
shows contour A enclosing all elements in $PIC1$
|
||||
|
||||
\pagebreak[1]
|
||||
\subsection{Enclosure and pair-wise \\ intersection in the graph}
|
||||
Because enclosure is a directed relationship and {\em pair-wise intersection} is non-directed
|
||||
we can represent them both on the same graph, see figure \ref{fig:eulerg_pic_g_a}.
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,bb=0 0 330 162,keepaspectratio=true]{./eulerg/eulerg_pic_g_a.jpg}
|
||||
% eulerg_pic_g_a.jpg: 330x162 pixel, 72dpi, 11.64x5.72 cm, bb=0 0 330 162
|
||||
\caption{Graph of Euler diagram in figure \ref{fig:eulerg_pic}.}
|
||||
\label{fig:eulerg_pic_g_a}
|
||||
\end{figure}
|
||||
|
||||
\pagebreak[1]
|
||||
\subsection{Reducing clutter in the graph}
|
||||
Contour A encloses the pure intersection chain $PIC1$;
|
||||
using definition \ref{def:encpic}, we can draw this in a less cluttered way,
|
||||
by only drawing one enclosure relationship to the {\pic}
|
||||
(see figure \ref{fig:eulerg_pic_g_a_unc}).
|
||||
We only need to show contour A enclosing one member of the {\pic} $PIC1$
|
||||
in order to show that contour A encloses all contours in $PIC1$.
|
||||
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,bb=0 0 330 162]{./eulerg/eulerg_pic_g_a_unc.jpg}
|
||||
% eulerg_pic_g_a_unc.jpg: 330x162 pixel, 72dpi, 11.64x5.72 cm, bb=0 0 330 162
|
||||
\caption{Uncluttered graph of Euler diagram in figure \ref{fig:eulerg_pic}.}
|
||||
\label{fig:eulerg_pic_g_a_unc}
|
||||
\end{figure}
|
||||
|
||||
|
||||
%\pagebreak[9]
|
||||
\clearpage
|
||||
\section{Reduction of searches \\ for available zones}
|
||||
|
||||
Another property of any {\pic} $P$, is that
|
||||
the maximum number of Euler zones within it is
|
||||
|
||||
$$ MaxZones = 2^{|P|} $$
|
||||
|
||||
Because no contours external to the {\pic}
|
||||
bisect any in it, no extra zones can be formed.
|
||||
By enclosing a {\pic} with
|
||||
a contour, we change the nature of the zones within
|
||||
the {\pic}, but the number of zones contributed by the {\pic}
|
||||
stays the same.
|
||||
\begin{definition}
|
||||
\label{picreduction}
|
||||
The number of available zones within a {\pic} $P$ does not change
|
||||
when other contours are added or removed from the diagram
|
||||
that are not, or would not become members of the {\pic} $P$.
|
||||
\end{definition}
|
||||
That is to say, the the number of zones within a {\pic} is not affected by changes in the diagram
|
||||
that do not alter the {\pic}.
|
||||
This allows us to analyse {\pic}s separately, thus reducing the $2^N$ overhead of analysing an Euler diagram for available zones.
|
||||
\pagebreak[3]
|
||||
\subsection{Available Zone Searching}
|
||||
|
||||
The available zones in an Euler diagram represent set theoretic combinations
|
||||
that can be used in the diagram.
|
||||
%For FMMD analyis, the test~cases
|
||||
Searching for an available zone involves finding out if the intersection exists, and then determining whether it is covered up
|
||||
by any other contours.
|
||||
A brute force search for available zones using area operations
|
||||
is therefore of the order $N.2^N$ (where N is the number of contours in the diagram).
|
||||
Using $|P|$ to represent the number of contours within a {\pic}
|
||||
and $K$ to represent the number of {\pic}s in a diagram,
|
||||
using the result in definition \ref{picreduction}, we can break the diagram into small segments
|
||||
(the {\pic}s) which have an order $K.2^{|P|}$.
|
||||
The exponential $2^N$ overhead is thus broken down into several smaller $2^{|P|}$ operations.
|
||||
The order of area operations is generally\footnote{In the case where the diagram is not comprised of just one {\pic}, which has no enclosing contours.}
|
||||
reduced by requiring several $K.|P|.2^{|P|}$
|
||||
instead of $N.2^N$ as $K < N$.
|
||||
|
||||
This has effectively reduced the order of the searching algorithm from exponential to polynomial order.
|
||||
|
||||
\vspace{40pt}
|
||||
|
||||
@ -1,119 +0,0 @@
|
||||
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\abstract{
|
||||
This paper discusses representing Euler Diagrams as graphs, or sets of relationships.
|
||||
By representing Euler diagrams in this way,
|
||||
algorithms to invesigate properties of the diagrams, are possible, without
|
||||
having to resort
|
||||
to CPU expensive area operations on the concrete diagrams.
|
||||
}
|
||||
}
|
||||
{ %% Introduction
|
||||
\section{Introduction}
|
||||
This paper discusses representing Euler Diagrams as graphs, or sets of relationships.
|
||||
By representing Euler diagrams in this way,
|
||||
algorithms to invesigate properties of the diagrams, are possible, without
|
||||
having to resort
|
||||
to CPU expensive area operations on the concrete diagrams.
|
||||
}
|
||||
|
||||
|
||||
\section{Introduction : Euler Diagram }
|
||||
|
||||
Classical Euler diagrams consist of closed curves in the plane which are used to represent sets.
|
||||
The spaitial relationship between the curves defines the set theoretic relationships, as defined below.
|
||||
\begin{itemize}
|
||||
\item Intersection - if the curves defining the area within curves overlap
|
||||
\item Sub-set - if a curve is enclosed by another
|
||||
\item disjoint - if the curves are separate
|
||||
\end{itemize}
|
||||
|
||||
|
||||
\section{Defining `pure intersection' and `enclosure'}
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./eulerg1.jpg}
|
||||
% eulerg1.jpg: 513x215 pixel, 72dpi, 18.10x7.58 cm, bb=0 0 513 215
|
||||
\caption{An Euler Diagram showing enclosure and Pure Intersection}
|
||||
\label{fig:eulerg1}
|
||||
\end{figure}
|
||||
|
||||
The set theory term `intersection' can apply to both the curves overlapping and to the sub-set case.
|
||||
For instance in diagram \ref{fig:euler1} the intersection between
|
||||
$A$ and $B$ exists.
|
||||
|
||||
$$ A \cup B \neq \emptyset $$
|
||||
|
||||
as does the intersection $D$ and $E$
|
||||
|
||||
$$ D \cup E \neq \emptyset $$
|
||||
|
||||
Clearly though these intersections are different, because
|
||||
in the $A$, $B$ case
|
||||
$$ A \backslash B = \emptyset \wedge B \backslash A \neq \emptyset $$.
|
||||
This is not the case for $D$, $E$ where:
|
||||
$$ D \backslash E \neq \emptyset \wedge E \backslash D \neq \emptyset $$
|
||||
|
||||
\paragraph{Enclosure}
|
||||
To distinguish between these we can term the $A$, $B$ case to be
|
||||
$A$ `enclosed' by $B$. We can express this as a directed relationship.
|
||||
|
||||
$$ B {\enc} A $$
|
||||
|
||||
|
||||
\paragraph{Pure Intersection}
|
||||
In the $D$, $E$ case we have
|
||||
|
||||
We can say that where the areas defined by the curves intersect but no one curve encloses the
|
||||
other, we can term this `pure intersection'.
|
||||
We can express this as a non directed relationship.
|
||||
|
||||
$$ D \pin E $$
|
||||
|
||||
|
||||
\paragraph{Mutual exclusivity of `pure intersection' and `enclosure'}
|
||||
|
||||
Clearly these two properties are mutually exclusive. No
|
||||
contour can be both purely intersected and enclosed with the same contour.
|
||||
Also enclosure, is transitive. That is to say if B encloses A, and A encloses C
|
||||
then B encloses C, see figure \ref{fig:eulerg_enc}.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./eulerg_enc.jpg}
|
||||
% eulerg_enc.jpg: 315x269 pixel, 72dpi, 11.11x9.49 cm, bb=0 0 315 269
|
||||
\caption{Enclosure, a transitive relationship}
|
||||
\label{fig:eulerg_enc}
|
||||
\end{figure}
|
||||
|
||||
$$ B {\enc} A \wedge A {\enc} C \implies B {\enc} C $$
|
||||
|
||||
\section{Representing Euler Diagrams as sets of relationships}
|
||||
|
||||
The diagram in figure \ref{fig:eulerg1} can be represented by the foillowing relationships.
|
||||
|
||||
$$ B {\enc} A $$
|
||||
$$ D {\pin} E $$
|
||||
|
||||
|
||||
The diagram in figure \ref{fig:eulerg_enc} can be represented by the following relationships.
|
||||
|
||||
$$ B {\enc} A $$
|
||||
$$ A {\enc} C $$
|
||||
|
||||
|
||||
\section{The Pure Intersection chain}
|
||||
|
||||
Contours may be connected via `pure intersection' relationships to form
|
||||
`chains' of contours reachable by pure intersection.
|
||||
|
||||
Figure \ref{fig:eulerg_pic} shows a pure intersection chain consisting of contours $M,N,O,P$ and $Q$.
|
||||
|
||||
|
||||
\textbf{rule:}
|
||||
If any contour in a pure intersection chain is enclosed by any contour, all countours within the
|
||||
pure intersection chain will be enclosed by it.
|
||||
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 2.4 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 2.5 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 24 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 4.6 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 9.0 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 5.7 KiB |
@ -1,36 +0,0 @@
|
||||
|
||||
\documentclass[a4paper,10pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{subfigure}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\usepackage{algorithm}
|
||||
\usepackage{algorithmic}
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
\input{../style}
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
|
||||
%\outerhead{{\small\bf Symptom Extraction Process}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
\title{Euler Diagrams as Graphs}
|
||||
\maketitle
|
||||
\input{eulerg_paper}
|
||||
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{../vmgbibliography,../mybib}
|
||||
|
||||
\today
|
||||
|
||||
|
||||
\end{document}
|
||||
@ -1,19 +0,0 @@
|
||||
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex fmmd_concept_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
cp paper.pdf fmmd_concept_paper.pdf
|
||||
okular fmmd_concept_paper.pdf
|
||||
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
fmmd_concept_paper.tex: fmmd_concept.tex paper.tex
|
||||
cat fmmd_concept.tex | sed 's/fmmd_concept\///' > fmmd_concept_paper.tex
|
||||
|
||||
bib:
|
||||
bibtex paper
|
||||
Binary file not shown.
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 5.7 KiB |
File diff suppressed because it is too large
Load Diff
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 21 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 25 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
@ -1,42 +0,0 @@
|
||||
|
||||
\documentclass[a4paper,10pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usetikzlibrary{shapes,snakes}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\input{../style}
|
||||
\usepackage{ifthen}
|
||||
\usepackage{lastpage}
|
||||
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
%\renewcommand{\chaptermark}[1]{\markboth{ \emph{#1}}{}}
|
||||
\fancyhead[LO]{}
|
||||
\fancyhead[RE]{\leftmark}
|
||||
%\fancyfoot[LE,RO]{\thepage}
|
||||
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
||||
\rfoot{\today}
|
||||
\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
||||
|
||||
%\outerhead{{\small\bf Developing a rigorous bottom-up modular static failure mode modelling methodology}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
||||
\maketitle
|
||||
\input{fmmd_concept_paper}
|
||||
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{../vmgbibliography,../mybib}
|
||||
|
||||
\today
|
||||
\end{document}
|
||||
Binary file not shown.
@ -1,19 +0,0 @@
|
||||
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex fmmd_data_model_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
cp paper.pdf fmmd_data_model_paper.pdf
|
||||
okular fmmd_data_model_paper.pdf
|
||||
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
fmmd_data_model_paper.tex: fmmd_data_model.tex paper.tex
|
||||
cat fmmd_data_model.tex | sed 's/fmmd_data_model\///' > fmmd_data_model_paper.tex
|
||||
|
||||
bib:
|
||||
bibtex paper
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 28 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 9.3 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
File diff suppressed because it is too large
Load Diff
@ -1,42 +0,0 @@
|
||||
|
||||
\documentclass[a4paper,10pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\input{../style}
|
||||
\usepackage{ifthen}
|
||||
\usepackage{lastpage}
|
||||
\usetikzlibrary{shapes,snakes}
|
||||
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
%\renewcommand{\chaptermark}[1]{\markboth{ \emph{#1}}{}}
|
||||
\fancyhead[LO]{}
|
||||
\fancyhead[RE]{\leftmark}
|
||||
%\fancyfoot[LE,RO]{\thepage}
|
||||
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
||||
\rfoot{\today}
|
||||
\lhead{FMMD Data Model}
|
||||
|
||||
%\outerhead{{\small\bf Developing a rigorous bottom-up modular static failure mode modelling methodology}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
\title{FMMD Data Model}
|
||||
\maketitle
|
||||
\input{fmmd_data_model_paper}
|
||||
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{../vmgbibliography,../mybib}
|
||||
|
||||
\today
|
||||
\end{document}
|
||||
@ -1,19 +0,0 @@
|
||||
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex fmmd_design_aide_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
mv paper.pdf fmmd_design_aide_paper.pdf
|
||||
okular fmmd_design_aide_paper.pdf
|
||||
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
fmmd_design_aide_paper.tex: fmmd_design_aide.tex paper.tex
|
||||
cat fmmd_design_aide.tex | sed 's/fmmd_design_aide\///' > fmmd_design_aide_paper.tex
|
||||
|
||||
bib:
|
||||
bibtex paper
|
||||
@ -1,734 +0,0 @@
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\abstract{ This
|
||||
paper
|
||||
describes how the FMMD methodology can be used to refine
|
||||
safety critical designs and identify undetectable and dormant faults.
|
||||
%
|
||||
As a working example, an industry standard mill-volt amplifier, intended for reading thermocouples,
|
||||
circuit is analysed.
|
||||
It has an inbuilt `safety~resistor' which allows it
|
||||
to detect the thermocouple becoming disconnected/going OPEN.
|
||||
%
|
||||
This circuit is analysed from an FMMD perspective and
|
||||
and two undetectable failure modes are identified.
|
||||
%
|
||||
An additional `safety check' circuit is then proposed and analysed.
|
||||
This has no undetectable failure modes, but does have one
|
||||
`dormant' failure mode.
|
||||
%
|
||||
This paper shows that once undetectable faults or dormant faults are discovered
|
||||
the design can be altered (or have a safety feature added), and the FMMD analysis process can then be re-applied.
|
||||
This can be an iterative process applied until the
|
||||
design has an acceptable level safety. % of dormant or undetectable failure modes.
|
||||
%
|
||||
Used in this way, its is a design aide, giving the user
|
||||
the possibility to refine a {\dc} from the perspective
|
||||
of its failure mode behaviour.
|
||||
}
|
||||
}
|
||||
{
|
||||
\section{Introduction}
|
||||
This chapter
|
||||
describes how the FMMD methodology can be used to refine
|
||||
safety critical designs and identify undetectable and dormant faults.
|
||||
%
|
||||
As a working example, an industry standard mill-volt amplifier, intended for reading thermocouples,
|
||||
circuit is analysed.
|
||||
It has an inbuilt `safety~resistor' which allows it
|
||||
to detect the thermocouple becoming disconnected/going OPEN.
|
||||
%
|
||||
This circuit is analysed from an FMMD perspective and
|
||||
and two undetectable failure modes are identified.
|
||||
%
|
||||
An additional `safety check' circuit is then proposed and analysed.
|
||||
This has no undetectable failure modes, but does have one
|
||||
`dormant' failure mode.
|
||||
%
|
||||
This paper shows that once undetectable faults or dormant faults are discovered
|
||||
the design can be altered (or have a safety feature added), and the FMMD analysis process can then be re-applied.
|
||||
This can be an iterative process applied until the
|
||||
design has an acceptable level safety. % of dormant or undetectable failure modes.
|
||||
%
|
||||
Used in this way, its is a design aide, giving the user
|
||||
the possibility to refine a {\dc} from the perspective
|
||||
of its failure mode behaviour.
|
||||
|
||||
}
|
||||
|
||||
|
||||
\section{How FMMD Analysis can reveal design flaws w.r.t. failure behaviour }
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\paragraph{Overview of FMMD Methodology}
|
||||
The principle of FMMD analysis is a five stage process,
|
||||
the collection of components into {\fg}s,
|
||||
which are analysed w.r.t. their failure mode behaviour,
|
||||
the failure mode behaviour is then viewed from the
|
||||
{\fg} perspective (i.e. as a symptoms of the {\fg}) and
|
||||
common symptoms are then collected. The final stage
|
||||
is to create a {\dc} which has the symptoms of the {\fg}
|
||||
it was sourced from, as its failure modes.
|
||||
%
|
||||
%From the failure mode behaviour of the {\fg} common symptoms are collected.
|
||||
These common symptoms are % in effect
|
||||
the failure mode behaviour of
|
||||
the {\fg} viewed as an % single
|
||||
entity, or a `black box' component.
|
||||
%
|
||||
From the analysis of the {\fg} we can create a {\dc}, where the failure modes
|
||||
are the symptoms of the {\fg} we derived it from.
|
||||
}
|
||||
{
|
||||
\paragraph{Overview of FMMD Methodology}
|
||||
To re-cap from chapter \ref{symptomex},
|
||||
the principle of FMMD analysis is a five stage process,
|
||||
the collection of components into {\fg}s,
|
||||
which are analysed w.r.t. their failure mode behaviour,
|
||||
the failure mode behaviour is then viewed from the
|
||||
{\fg} perspective (i.e. as a symptoms of the {\fg}),
|
||||
common symptoms are then collected. The final stage
|
||||
is to create a {\dc} which has the symptoms of the {\fg}
|
||||
it was sourced from, as its failure modes.
|
||||
%
|
||||
%From the failure mode behaviour of the {\fg} common symptoms are collected.
|
||||
These common symptoms are % in effect
|
||||
the failure mode behaviour of
|
||||
the {\fg} viewed as an % single
|
||||
entity, or a `black box' component.
|
||||
%
|
||||
From the analysis of the {\fg} we can create a {\dc}, where the failure modes
|
||||
are the symptoms of the {\fg} we derived it from.
|
||||
}
|
||||
%
|
||||
\paragraph{Undetectable failure modes.}
|
||||
Within a functional group failure symptoms will be detectable
|
||||
or undetectable.
|
||||
The `undetectable' failure modes understandably, are the most worrying for the safety critical designer.
|
||||
EN61058~\cite{en61508}, the statistically based failure mode European Norm, using ratios
|
||||
of detected and undetected system failure modes to
|
||||
classify the systems safety levels and describes sub-clasifications
|
||||
for detected and undetected failure modes.
|
||||
%\gloss{DU}
|
||||
%\gloss{DD}
|
||||
|
||||
%It is these that are, generally the ones that stand out as single
|
||||
%failure modes.
|
||||
For instance, out of range values, are easy to detect by
|
||||
systems using the {\dc} supplying them.
|
||||
Undetectable faults are ones that supply incorrect information or states
|
||||
where we have no way of knowing whether they are correct or not.
|
||||
% we know we can cope with; they
|
||||
%are an obvious error condition that will be detected by any modules
|
||||
%using the {\dc}.
|
||||
%
|
||||
Undetectable failure modes can introduce serious
|
||||
errors into a SYSTEM.
|
||||
|
||||
|
||||
|
||||
\paragraph{Dormant faults.}
|
||||
A dormant fault is one
|
||||
which can manifest its-self in conjunction with
|
||||
another failure mode becoming active, or an environmental
|
||||
condition changing (for instance temperature).
|
||||
Some
|
||||
component failure modes may lead to dormant failure modes.
|
||||
For instance a transistor failing OPEN when it is meant
|
||||
to be in an OFF state would be a dormant fault.
|
||||
Even though the fault is active, the transistor
|
||||
is, for the time being, behaving correctly.
|
||||
%
|
||||
If we examine the circuit from both operational states,
|
||||
i.e. the transistor when is is both meant to be ON and OFF
|
||||
we can determine all the consequences of that particular failure.
|
||||
%
|
||||
More generally, by examining test cases from a functional group against all
|
||||
operational states and germane environmental conditions
|
||||
we can determine all the failure modes of the {\fg}.
|
||||
|
||||
\subsection{Iterative Design Example}
|
||||
|
||||
By applying FMMD analysis to a {\fg} we can determine which failure
|
||||
modes of a {\dc} are undetectable or dormant.
|
||||
We can then either modify the circuit and iteratively
|
||||
apply FMMD to the design again, or we could add another {\fg}
|
||||
that specifically tests for the undetectable/dormant conditions.
|
||||
|
||||
This
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
paper
|
||||
}
|
||||
{
|
||||
chapter
|
||||
}
|
||||
describes a milli-volt amplifier (see figure \ref{fig:mv1}), with an inbuilt safety\footnote{The `safety resistor' also acts
|
||||
as a potential divider to provide a mill-volt offset. An offset is often required to allow for negative readings from the
|
||||
milli-volt source.}
|
||||
resistor (R18). The circuit is analysed and it is found that all but one component failure modes
|
||||
are detectable.
|
||||
We then design a circuit to test for the `undetectable' failure modes
|
||||
and analyse this with FMMD.
|
||||
The test circuit addition can now be represented by a {\dc}.
|
||||
With both {\dcs} we then use them to form a {\fg} which we can call our `self testing milli-volt amplifier'.
|
||||
We then analsye the {\fg} and the resultant {\dc} failure modes/symptoms are discussed.
|
||||
\section{An example: A Millivolt Amplifier}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,bb=0 0 678 690,keepaspectratio=true]{./fmmd_design_aide/mv_opamp_circuit.png}
|
||||
% mv_opamp_circuit.png: 678x690 pixel, 72dpi, 23.92x24.34 cm, bb=0 0 678 690
|
||||
\caption{Milli-Volt Amplifier with Safety/Offset Resistor}
|
||||
\label{fig:mv1}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Brief Circuit Description}
|
||||
|
||||
This circuit amplifies a milli-volt input by a gain of $\approx$ 184 ($\frac{150E3}{820}+1$)
|
||||
\footnote{The resistors used to program the gain of the op-amp would typically be of a $ \le 1\%$ guaranteed
|
||||
tolerance. In practise, the small variations would be corrected with software constants programmed during production
|
||||
test/calibration.}.
|
||||
An offset is applied to the input by R18 and R22 forming a potential divider
|
||||
of $\frac{820}{2.2E6+820}$. With 5V applied as Vcc this gives an input offset of $1.86\,mV$.
|
||||
This amplified offset
|
||||
can be termed a $\Delta V$, an addition to the mV value provided by the sensor.
|
||||
So the amplified offset is $\approx 342 \, mV$.
|
||||
We can determine the output of the amplifier
|
||||
by subtracting this amount from the reading. We can also define an acceptable
|
||||
range for the readings. This would depend on the characteristics of milli-volt source, and also on the
|
||||
thresholds of the voltages considered out of range. For the sake of example let us
|
||||
consider this to be a type K thermocouple amplifier, with a range of temperatures
|
||||
expected to be within {{0}\oc} and {{300}\oc}.
|
||||
|
||||
\paragraph{Voltage range for {{0}\oc} to {{300}\oc}.}
|
||||
Choosing the common Nickel-Chromium v. Nickel Aluminium `K' type thermocouple,
|
||||
{{0}\oc} provides an EMF of 0mV, and {{300}\oc} 12.207.
|
||||
Multiplying these by 184 and adding the 1.86mV offset gives
|
||||
342.24mV and 2563.12mV. This is now in a suitable range to be read by
|
||||
an analogue digital converter, which will have a voltage span
|
||||
typically between 3.3V and 5V~\cite{pic18f2523}.% on modern micro-controllers/ADC (Analogue Digital Converter) chips.
|
||||
Note that this also leaves a margin or error on both sides of the range.
|
||||
If the thermocouple were to become colder than {{0}\oc} it would supply
|
||||
a negative voltage, which would subtract from the offset.
|
||||
At around {{-47}\oc} the amplifier output would be zero;
|
||||
but anything under say 10mV is considered out of range\footnote{We need some negative range
|
||||
to cope with cold junction compensation~\cite{aoe},
|
||||
which is a subject beyond the scope of this paper}.
|
||||
Thus the ADC can comfortably read out of range values
|
||||
but controlling software can determine it as invalid.
|
||||
Similarly anything over 2563.12mV would be considered out of range
|
||||
but would be still within comfortable reading range for an ADC.
|
||||
|
||||
\section{FMMD Analysis}
|
||||
|
||||
|
||||
|
||||
|
||||
\begin{table}[h+]
|
||||
\caption{Milli Volt Amplifier Single Fault FMMD} % title of Table
|
||||
\centering % used for centering table
|
||||
\begin{tabular}{||l|c|l|c||}
|
||||
\hline \hline
|
||||
\textbf{Test} & \textbf{Failure } & \textbf{Symptom } & \textbf{MTTF} \\
|
||||
\textbf{Case} & \textbf{mode} & \textbf{ } & \\ % \textbf{per $10^9$ hours of operation} \\
|
||||
% R & wire & res + & res - & description
|
||||
\hline
|
||||
\hline
|
||||
TC:1 $R18$ SHORT & Amp plus input high & Out of range & 1.38 \\ \hline
|
||||
TC:2 $R18$ OPEN & No Offset Voltage & \textbf{Low reading} & 12.42\\ \hline
|
||||
\hline
|
||||
TC:3 $R22$ SHORT & No offset voltage & \textbf{Low reading} & 1.38 \\ \hline
|
||||
TC:4 $R22$ OPEN & Amp plus high input & Out of Range & 1.38 \\ \hline
|
||||
\hline
|
||||
TC:5 $R26$ SHORT & No gain from amp & Out of Range & 1.38 \\
|
||||
TC:6 $R26$ OPEN & Very high amp gain & Out of Range & 12.42 \\ \hline
|
||||
\hline
|
||||
TC:5 $R30$ SHORT & Very high amp gain & Out of range & 1.38 \\
|
||||
TC:6 $R30$ OPEN & No gain from amp & Out of Range & 12.42 \\ \hline
|
||||
\hline
|
||||
TC:7 $OP\_AMP$ LATCH UP & high amp output & Out of range & 1.38 \\
|
||||
TC:8 $OP\_AMP$ LATCH DOWN & low amp output & Out of Range & 12.42 \\ \hline
|
||||
|
||||
\end{tabular}
|
||||
\label{tab:fmmdaide1}
|
||||
\end{table}
|
||||
|
||||
|
||||
This analysis process, which given the components R18,R22,R26,R30,IC1, has derived
|
||||
the component "milli-volt amplifier" with two failure modes, `Out of Range' and
|
||||
`Low reading'.
|
||||
we can represent this in an FMMD hierarchy diagram, see figure \ref{fig:mvamp_fmmd}.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./fmmd_design_aide/mvamp_fmmd.jpg}
|
||||
% mvamp_fmmd.jpg: 281x344 pixel, 72dpi, 9.91x12.14 cm, bb=0 0 281 344
|
||||
\caption{FMMD analysis Hierarchy for Milli-Volt Amplifier}
|
||||
\label{fig:mvamp_fmmd}
|
||||
\end{figure}
|
||||
|
||||
The table \ref{tab:fmmdaide1} shows two possible causes for an undetectable
|
||||
error, that of a low reading due to the loss of the offset millivolt signal.
|
||||
The loss of the $\Delta V$ would mean an incorrect temperature
|
||||
reading would be made.
|
||||
Typically this type of circuit would be used to read a thermocouple
|
||||
and this error symptom, `low\_reading' would mean our plant could
|
||||
beleive that the temperature reading is lower than it actually is.
|
||||
To take an example from a K type thermocouple, the offset of 1.86mV
|
||||
%from the potential divider represents amplified to
|
||||
would represent $\approx \; 46\,^{\circ}{\rm C}$~\cite{eurothermtables}~\cite{aoe}.
|
||||
|
||||
%\clearpage
|
||||
\subsection{Undetected Failure Mode: Incorrect Reading}
|
||||
|
||||
Although statistically, this failure is unlikely (get stats for R short FIT etc from pt100 doc)
|
||||
if the reading is considered critical, or we are aiming for a high integrity level
|
||||
this may be unacceptable.
|
||||
We will need to add some type of detection mechanism to the circuit to
|
||||
test $R_{off}$ periodically.
|
||||
%For instance were we to check $R_{off}$ every $\tau = 20mS$ work out detection
|
||||
%allowance according to EN61508~\cite{en61508}.
|
||||
|
||||
|
||||
\section{Proposed Checking Method}
|
||||
|
||||
Were we to able to switch a second resistor in series with the
|
||||
820R resistor (R22) and switch it out again, we could test
|
||||
that the safety resistor (R18) still functioning correctly.
|
||||
|
||||
With the new resistor switched in we would expect
|
||||
the voltage added by the potential divider
|
||||
to increase.
|
||||
|
||||
The circuit in figure \ref{fig:mvamp2} shows an bi-polar transistor % yes its menally ill and goes on mad shopping spreees etc
|
||||
controlled by the `test line' connection, which can switch in the resitor R36
|
||||
also with a value of \ohms{820}.
|
||||
|
||||
We could detect the effect on the reading with the potential divider
|
||||
according to the following formula.
|
||||
|
||||
%% check figures
|
||||
The potential divider is now $\frac{820R+820R}{2M2+820R+820R}$ over 5V ci this gives
|
||||
3.724mV, amplified by 184 this is 0.685V \adcten{140}.
|
||||
%
|
||||
The potential divider with the second resistor
|
||||
switched out is $\frac{820R}{2M2+820R}$ over 5V gives 1.86mV,
|
||||
amplified by 184 gives 0.342V \adcten{70}.
|
||||
|
||||
This is a difference of \adcten{70} in the readings.
|
||||
|
||||
So periodically, perhaps even as frequently as once every few seconds
|
||||
we can apply the checking resistor and look for a corresponding
|
||||
change in the reading.
|
||||
|
||||
Lets us analyse this in more detail to prove that we are indeed checking for
|
||||
the failure of the safety resistor, and that we are not introducing
|
||||
any new problems.
|
||||
|
||||
First let us look at the new transistor and resistor and
|
||||
treat these as a functional group.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./fmmd_design_aide/test_circuit.png}
|
||||
% test_circuit.png: 239x144 pixel, 72dpi, 8.43x5.08 cm, bb=0 0 239 144
|
||||
\caption{Test circuit functional group}
|
||||
\label{fig:test_circuit}
|
||||
\end{figure}
|
||||
|
||||
|
||||
In our analysis of the failure modes we have to consider the operational
|
||||
states of this circuit, which are
|
||||
the transistor being switched ON and OFF.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./fmmd_design_aide/mv_opamp_circuit2.png}
|
||||
% mv_opamp_circuit2.png: 577x479 pixel, 72dpi, 20.35x16.90 cm, bb=0 0 577 479
|
||||
\caption{Amplifier with check circuit addition}
|
||||
\label{fig:mvamp2}
|
||||
\end{figure}
|
||||
|
||||
|
||||
|
||||
|
||||
\section{FMMD analysis of Safety Addition}
|
||||
|
||||
|
||||
This test circuit has two operational states, in that it
|
||||
can be switched on to apply the test series resistance, and
|
||||
off to obtain the correct reading.
|
||||
%
|
||||
We must examine each test case from these two perspectives.
|
||||
For $\overline{TEST\_LINE}$ ON the transistor is turned OFF
|
||||
and we are in a test mode and expect the reading to go up by around \adcten{70}.
|
||||
For $\overline{TEST\_LINE}$ OFF the tranistor is on and R36 is by-passed,
|
||||
and the reading is assumed to be valid.
|
||||
|
||||
\begin{table}[h+]
|
||||
\caption{Test Addition Single Fault FMMD} % title of Table
|
||||
\centering % used for centering table
|
||||
\begin{tabular}{||l|l|c|l|c||}
|
||||
\hline \hline
|
||||
\textbf{test line } & \textbf{Test} & \textbf{Failure } & \textbf{Symptom } & \\ %\textbf{MTTF} \\
|
||||
\textbf{status} & \textbf{Case} & \textbf{mode} & \textbf{ } & \\ % \textbf{per $10^9$ hours of operation} \\
|
||||
% R & wire & res + & res - & description
|
||||
\hline
|
||||
\hline
|
||||
%% OK TR1 OFF , and so 36 in series. R36 has shorted so
|
||||
$\overline{TEST\_LINE}$ ON & TC:1 $R36$ SHORT & No added resistance & NO TEST EFFECT & 1.38 \\ \hline
|
||||
%%
|
||||
$\overline{TEST\_LINE}$ OFF & TC:1 $R36$ SHORT & dormant failure & NO SYMPTOM & 1.38 \\ \hline
|
||||
%% here TR1 should be OFF, as R36 is open we now have an open circuit
|
||||
$\overline{TEST\_LINE}$ ON & TC:2 $R36$ OPEN & open circuit & OPEN CIRCUIT & 12.42\\ \hline
|
||||
%% here TR1 should be ON and R36 by-passed, the fact it has gone OPEN means no symptom here, a dormant failure.
|
||||
$\overline{TEST\_LINE}$ OFF & TC:2 $R36$ OPEN & dormant failure & NO SYMPTOM & 12.42\\ \hline
|
||||
\hline
|
||||
%
|
||||
%% TR1 OFF so R36 should be in series. Because TR1 is ON because it is faulty, R36 is not in series
|
||||
$\overline{TEST\_LINE}$ LINE ON & TC:3 $TR1$ ALWAYS ON & No added resistance & NO TEST EFFECT & 3 \\ \hline
|
||||
%%
|
||||
%% TR1 ON R36 should be bypassed by TR1, and it is, but as TR1 is always on we have a dormant failure.
|
||||
$\overline{TEST\_LINE}$ OFF & TC:3 $TR1$ ALWAYS ON & dormant failure & NO SYMPTOM & 3 \\ \hline
|
||||
%%
|
||||
%% TR1 should be off as overline{TEST\_LINE}$ is ON. As TR1 is faulty it is always off and we have a dormant failure.
|
||||
$\overline{TEST\_LINE}$ LINE ON & TC:4 $TR1$ ALWAYS OFF & dormant failure & NO SYMPTOM & 8 \\ \hline
|
||||
%%
|
||||
%% TR1 should be ON, but is off due to TR1 failure. The resistance R36 will always be in series therefore
|
||||
$\overline{TEST\_LINE}$ OFF & TC:4 $TR1$ ALWAYS OFF & resistance always added & NO TEST EFFECT & 8 \\ \hline
|
||||
\hline
|
||||
\end{tabular}
|
||||
\label{tab:testaddition}
|
||||
\end{table}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\subsection{Test Cases Analysis in detail}
|
||||
|
||||
The purpose of this circuit is to switch a resistance in when we want to test the circuit
|
||||
and to switch it out for normal operation.
|
||||
The control is provided by a line called $\overline{TEST\_LINE}$.
|
||||
Thus to apply the test conditions we set $\overline{TEST\_LINE}$ to OFF or false
|
||||
and to order normal operation we set it to ON or true.
|
||||
|
||||
\subsubsection{TC 1}
|
||||
This test case looks at the shorted resistor failure mode of R36.
|
||||
\paragraph{$\overline{TEST\_LINE}$ ON}
|
||||
Here TR1 should be off and R36 should be in series. As R36 is shorted, this means that
|
||||
no resistance will be contributed to the circuit by R36.
|
||||
In the terms of the behaviour
|
||||
of the functional group, this means that it will provide no test effect.
|
||||
\paragraph{$\overline{TEST\_LINE}$ OFF}
|
||||
Here TR1 will be on and by-pass R36, so it does not make any difference if
|
||||
R36 is shorted. This is a dormant failure, we can only detect this failure
|
||||
when $\overline{TEST\_LINE}$ is ON.
|
||||
|
||||
|
||||
|
||||
\subsubsection{TC 2}
|
||||
This test case looks at the open circuit resistor failure mode of R36.
|
||||
\paragraph{$\overline{TEST\_LINE}$ ON}
|
||||
Here TR1 should be off and R36 should be in series. As R36 is open, this means that
|
||||
the test circuit is no open.
|
||||
In the terms of the behaviour
|
||||
of the functional group, this means that it will cause an open circuit failure.
|
||||
\paragraph{$\overline{TEST\_LINE}$ OFF}
|
||||
Here TR1 will be on and by-pass R36, so it does not make any difference if
|
||||
R36 is open. This is a dormant failure, we can only detect this failure
|
||||
when $\overline{TEST\_LINE}$ is ON.
|
||||
|
||||
|
||||
\subsubsection{TC 3}
|
||||
This test case looks at the transistor failure mode where TR1 is always ON.
|
||||
\footnote{The transistor is being used as a switch, and so we can model it as having two failure modes ALWAYS ON or ALWAYS OFF.}
|
||||
\paragraph{$\overline{TEST\_LINE}$ ON}
|
||||
Here TR1 should be off and R36 should be in series. As TR1 is always ON, this means that
|
||||
R36 will always be by-passed. Thus there will be no test effect.
|
||||
\paragraph{$\overline{TEST\_LINE}$ OFF}
|
||||
Here TR1 should be on and by-pass R36.
|
||||
This is a dormant failure, we can only detect this failure
|
||||
when $\overline{TEST\_LINE}$ is ON.
|
||||
|
||||
\subsubsection{TC 4}
|
||||
This test case looks at the transistor failure mode where TR1 is always OFF.
|
||||
\paragraph{$\overline{TEST\_LINE}$ ON}
|
||||
Here TR1 should be OFF and R36 should be in series.
|
||||
This is a dormant failure, we can only detect this failure
|
||||
when the $\overline{TEST\_LINE}$ is OFF.
|
||||
\paragraph{$\overline{TEST\_LINE}$ OFF}
|
||||
Here TR1 should be ON, but is OFF due to failure.
|
||||
The resistance R36 will always be in series.
|
||||
As a symptom for this circuit, it means that there would be no test effect.
|
||||
|
||||
|
||||
\subsection{conclusion of FMMD analysis on safety addition}
|
||||
|
||||
This test circuit has from its four component failure modes,
|
||||
3 failure symptoms $\{ NO TEST EFFECT, NO SYMPTOM, OPEN CIRCUIT \}$
|
||||
For the FMMD analysis in table \ref{tab:testaddition} we have two failure modes for its derived component
|
||||
`no~test~effect' or `open~circuit'. There
|
||||
$NO SYMPTOM$ failure mode is dormant, but will be revealed when the test~line changes state.
|
||||
|
||||
The next stage is to combine the two derived components we have made into
|
||||
a higher level functional group, see figure \ref{fig:testable_mvamp}.
|
||||
|
||||
\section{FMMD Hierarchy, with milli-volt amp and safety addition}
|
||||
|
||||
We have created two derived components, the amplifier, and the test~circuit, we
|
||||
now place them into a new functional group.
|
||||
We can now analyse this functional
|
||||
group w.r.t the failure modes of the two derived components.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=300pt,bb=0 0 698 631,keepaspectratio=true]{./fmmd_design_aide/testable_mvamp.jpg}
|
||||
% testable_mvamp.jpg: 698x631 pixel, 72dpi, 24.62x22.26 cm, bb=0 0 698 631
|
||||
\caption{Testable milli-volt amplifier}
|
||||
\label{fig:testable_mvamp}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Analysis of FMMD Derived component `testable milli-volt amp'}
|
||||
|
||||
The failure mode of most concern is the undetectable failure `low~reading'. This has two potential
|
||||
causes in the unmodified circuit, R22\_SHORT and R18\_OPEN.
|
||||
|
||||
\paragraph{R22\_SHORT with safety addition}
|
||||
With the modified circuit, in the $\overline{TEST\_LINE}$ ON condition
|
||||
TR1 will be off and we will have a reading + test $\Delta V$.
|
||||
However with $\overline{TEST\_LINE}$ OFF we have no potential divider.
|
||||
R18 will pull the +ve terminal on the op-amp up, pushing the result out of range.
|
||||
The failure is thus detectable.
|
||||
|
||||
\paragraph{R18\_OPEN with safety addition}
|
||||
Here there is no potential divider. The $\overline{TEST\_LINE}$ will have no effect
|
||||
which ever way it is switched. The failure mode is thus detectable.
|
||||
|
||||
\paragraph{Symptom Extraction for the Functional Group `testable mill-volt amplifier'}
|
||||
|
||||
We have four failure modes to consider in the functional group `testable mill-volt amplifier'.
|
||||
These are
|
||||
\begin{itemize}
|
||||
\item failure mode: open~potential~divider
|
||||
\item failure mode: no~test~effect
|
||||
\item failure mode: out~of~range
|
||||
\item failure mode: low~reading
|
||||
\end{itemize}
|
||||
|
||||
We can now collect symptoms; `open~potential~divider' from test will cause R18 to pull the +ve input of the opamp high
|
||||
giving an out of range reading from the op-amp output.
|
||||
We can group `low~reading' with `out~of~range'.
|
||||
The `low~reading' will now becomes either `no~test~effect' or `out~of~range' depending on the $\overline{TEST\_LINE}$ state.
|
||||
|
||||
|
||||
%
|
||||
% NB: the calculate MTTF here we have to traverse down the DAG
|
||||
% adding XOR conditions and multiplying AND conditions
|
||||
% 16MAR2011
|
||||
%
|
||||
|
||||
\begin{table}[h+]
|
||||
\caption{Testable Milli Volt Amplifier Single Fault FMMD} % title of Table
|
||||
\centering % used for centering table
|
||||
\begin{tabular}{||l|c|l|c||}
|
||||
\hline \hline
|
||||
\textbf{Test} & \textbf{Failure } & \textbf{Symptom } & \\ % \textbf{MTTF} \\
|
||||
\textbf{Case} & \textbf{mode} & \textbf{ } & \\ % \textbf{per $10^9$ hours of operation} \\
|
||||
% R & wire & res + & res - & description
|
||||
\hline
|
||||
\hline
|
||||
TC:1 $testcircuit$ & open potential divider & Out of range & \\ \hline % XX 1.38 \\ \hline
|
||||
\hline
|
||||
TC:2 $testcircuit$ & no test effect & no test effect & \\ \hline % XX 1.38 \\ \hline
|
||||
\hline
|
||||
TC:3 $mvamp$ & out of range & Out of Range & \\ \hline % XX 1.38 \\
|
||||
\hline
|
||||
TC:4 $mvamp$ & low reading & Out of range \& no test effect & \\ \hline % XX 1.38 \\
|
||||
\hline
|
||||
|
||||
\end{tabular}
|
||||
\label{tab:fmmdaide2}
|
||||
\end{table}
|
||||
|
||||
|
||||
|
||||
We now have two symptoms, `out~of~range' or `no~test~effect'. So for single component failures
|
||||
we now have a circuit where there are no undetectable failure modes.
|
||||
|
||||
We can surmise the symptoms in a list.
|
||||
|
||||
\begin{itemize}
|
||||
\item symptom: \textbf{out~of~range} caused by the failure modes: open~potential~divider, low~reading.
|
||||
\item symptom: \textbf{no~test~effect} caused by the failure modes: no~test~effect, low~reading.
|
||||
\end{itemize}
|
||||
|
||||
\section{MTTF Reliability statistics}
|
||||
|
||||
|
||||
%\clearpage
|
||||
\subsection{OP-AMP FIT Calculations}
|
||||
The DOD electronic reliability of components
|
||||
document MIL-HDBK-217F~\cite{mil1991}[5.1] gives formulae for calculating
|
||||
the
|
||||
%$\frac{failures}{{10}^6}$
|
||||
${failures}/{{10}^6}$ % looks better
|
||||
hours for a wide range of generic components.
|
||||
These figures are based on components from the 1980's and MIL-HDBK-217F
|
||||
gives very conservative reliability figures when applied to
|
||||
modern components. The formula for a generic packaged micro~circuit
|
||||
is reproduced in equation \ref{microcircuitfit}.
|
||||
The meanings of and values assigned to its co-efficients are described in table \ref{tab:opamp}.
|
||||
|
||||
\begin{equation}
|
||||
{\lambda}_p = (C_1{\pi}_T+C_2{\pi}_E){\pi}_Q{\pi}_L
|
||||
\label{microcircuitfit}
|
||||
\end{equation}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
% SIL assessment 8 PIN GENERAL OP-AMP
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
\begin{table}[ht]
|
||||
\caption{OP AMP FIT assessment} % title of Table
|
||||
\centering % used for centering table
|
||||
\begin{tabular}{||c|c|l||}
|
||||
\hline \hline
|
||||
\em{Parameter} & \em{Value} & \em{Comments} \\
|
||||
& & \\ \hline \hline
|
||||
$C_1$ & 0.040 & $300 \ge 1000$ BiCMOS transistors \\ \hline
|
||||
${\pi}_T$ & 1.4 & max temp of $60^o$ C\\ \hline
|
||||
$C_2$ & 0.0026 & number of functional pins(8) \\ \hline
|
||||
${\pi}_E$ & 2.0 & ground fixed environment (not benign)\\ \hline
|
||||
${\pi}_Q$ & 2.0 & Non-Mil spec component\\ \hline
|
||||
${\pi}_L$ & 1.0 & More than 2 years in production\\ \hline
|
||||
|
||||
\hline \hline
|
||||
\end{tabular}
|
||||
\label{tab:opamp}
|
||||
\end{table}
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
|
||||
Taking these parameters and applying equation \ref{microcircuitfit},
|
||||
$$ 0.04 \times 1.4 \times 0.0026 \times 2.0 \times 2.0 \times 1.0 = .0005824 $$
|
||||
we get a value of $0.0005824 \times {10}^6$ failures per hour.
|
||||
This is a worst case FIT\footnote{where FIT (Failure in Time) is defined as
|
||||
failures per Billion (${10}^9$) hours of operation} of 1.
|
||||
|
||||
\subsection{Switching Transistor}
|
||||
|
||||
The switching transistor will be operating at a low frequency
|
||||
and well within 50\% of its maximum voltage. We can also assume a benign
|
||||
temperature environment of $ < 60^{o}C$.
|
||||
MIL-HDBK-217F\cite{mil1992}[6-25] gives an exmaple
|
||||
transistor in these environmental conditions, and assigns an FIT value of 11.
|
||||
%
|
||||
The RAC failure mode distributuions manual~\cite{fmd91}[2-25] entry for
|
||||
bi-polar transistors, gives a 0.73 probability of them failing shorted, and a 0.23 probability of them failing OPEN.
|
||||
%
|
||||
For this exmaple, we can therefore use a FIT value of 8 ($0.73 \times 11$) the transistor failing
|
||||
SHORT and a FIT of 3 ($0.27 \times 11$) failing OPEN.
|
||||
|
||||
|
||||
|
||||
\subsection{Resistors}
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
The formula for given in MIL-HDBK-217F\cite{mil1991}[9.2] for a generic fixed film non-power resistor
|
||||
is reproduced in equation \ref{resistorfit}. The meanings
|
||||
and values assigned to its co-efficients are described in table \ref{tab:resistor}.
|
||||
|
||||
\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}}
|
||||
\fmodegloss
|
||||
|
||||
\begin{equation}
|
||||
% fixed comp resistor{\lambda}_p = {\lambda}_{b}{\pi}_{R}{\pi}_Q{\pi}_E
|
||||
resistor{\lambda}_p = {\lambda}_{b}{\pi}_{R}{\pi}_Q{\pi}_E
|
||||
\label{resistorfit}
|
||||
\end{equation}
|
||||
|
||||
\begin{table}[ht]
|
||||
\caption{Fixed film resistor Failure in time assessment} % title of Table
|
||||
\centering % used for centering table
|
||||
\begin{tabular}{||c|c|l||}
|
||||
\hline \hline
|
||||
\em{Parameter} & \em{Value} & \em{Comments} \\
|
||||
& & \\ \hline \hline
|
||||
${\lambda}_{b}$ & 0.00092 & stress/temp base failure rate $60^o$ C \\ \hline
|
||||
%${\pi}_T$ & 4.2 & max temp of $60^o$ C\\ \hline
|
||||
${\pi}_R$ & 1.0 & Resistance range $< 0.1M\Omega$\\ \hline
|
||||
${\pi}_Q$ & 15.0 & Non-Mil spec component\\ \hline
|
||||
${\pi}_E$ & 1.0 & benign ground environment\\ \hline
|
||||
|
||||
\hline \hline
|
||||
\end{tabular}
|
||||
\label{tab:resistor}
|
||||
\end{table}
|
||||
|
||||
Applying equation \ref{resistorfit} with the parameters from table \ref{tab:resistor}
|
||||
give the following failures in ${10}^6$ hours:
|
||||
|
||||
\begin{equation}
|
||||
0.00092 \times 1.0 \times 15.0 \times 1.0 = 0.0138 \;{failures}/{{10}^{6} Hours}
|
||||
\label{eqn:resistor}
|
||||
\end{equation}
|
||||
|
||||
While MIL-HDBK-217F gives MTTF for a wide range of common components,
|
||||
it does not specify how the components will fail (in this case OPEN or SHORT). {Some standards, notably EN298 only consider resistors failing in OPEN mode}.
|
||||
%FMD-97 gives 27\% OPEN and 3\% SHORTED, for resistors under certain electrical and environmental stresses.
|
||||
% FMD-91 gives parameter change as a third failure mode, luvvverly 08FEB2011
|
||||
This example
|
||||
compromises and uses a 90:10 ratio, for resistor failure.
|
||||
Thus for this example resistors are expected to fail OPEN in 90\% of cases and SHORTED
|
||||
in the other 10\%.
|
||||
A standard fixed film resistor, for use in a benign environment, non military spec at
|
||||
temperatures up to 60\oc is given a probability of 13.8 failures per billion ($10^9$)
|
||||
hours of operation (see equation \ref{eqn:resistor}).
|
||||
This figure is referred to as a FIT\footnote{FIT values are measured as the number of
|
||||
failures per Billion (${10}^9$) hours of operation, (roughly 114,000 years). The smaller the
|
||||
FIT number the more reliable the fault~mode} Failure in time.
|
||||
}
|
||||
{ % CHAPTER
|
||||
Resistors for this example are considered to have a FIT of 13.8, and are expected to fail OPEN in 90\% of cases and SHORTED
|
||||
in the other 10\%.
|
||||
This is described in detail with supporting references in \ref{resistorfit}.
|
||||
}
|
||||
|
||||
|
||||
\section{Conclusions}
|
||||
|
||||
With the safety addition the undetectable failure mode of \textbf{low~reading}
|
||||
disappears.
|
||||
However, the overall reliability though goes down !
|
||||
This is simply because we have more components that {\em can} fail.
|
||||
%% Safety vs. reliability paradox.
|
||||
%The sum of the MTTF's for the original circuit is DAH, and for the new one
|
||||
%DAH.
|
||||
The circuit is arguably safer now
|
||||
but statistically less reliable.
|
||||
|
||||
\paragraph{Practical side effect of checking for thermocouple disconnection}
|
||||
|
||||
Because the potential divider provides an offset as a side effect of detecting a disconnection
|
||||
resistance in the thermocouple extension or compensation cable will have an effect.
|
||||
For a `k' type thermocouple this would be of the order of $0.5 { }^{o}C$ for $10\Omega$ of
|
||||
cable loop impedance. Therefore, accuracy constraints and cable impedance should be considered
|
||||
to determine specified maximum compensation/extension lengths.
|
||||
|
||||
|
||||
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 9.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 13 KiB |
@ -1,40 +0,0 @@
|
||||
|
||||
\documentclass[a4paper,10pt]{article}
|
||||
\usepackage{graphicx}
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\input{../style}
|
||||
\usepackage{lastpage}
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
%\renewcommand{\chaptermark}[1]{\markboth{ \emph{#1}}{}}
|
||||
\fancyhead[LO]{}
|
||||
\fancyhead[RE]{\leftmark}
|
||||
%\fancyfoot[LE,RO]{\thepage}
|
||||
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
||||
\rfoot{\today}
|
||||
\lhead{FMMD as a design aide}
|
||||
|
||||
%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
\title{FMMD as a design aide}
|
||||
\maketitle
|
||||
\input{fmmd_design_aide_paper}
|
||||
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{../vmgbibliography,../mybib}
|
||||
|
||||
\today
|
||||
\end{document}
|
||||
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 9.6 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 8.2 KiB |
Binary file not shown.
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user