...
This commit is contained in:
Robin Clark
parent
3607ac6c65
commit
bf552179a9
BIN
fmmd_concept/System_safety_2011/component.png
Normal file
BIN
fmmd_concept/System_safety_2011/component.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 2.5 KiB |
BIN
fmmd_concept/System_safety_2011/fmmd_env_op_uml.png
Normal file
BIN
fmmd_concept/System_safety_2011/fmmd_env_op_uml.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 13 KiB |
BIN
fmmd_concept/System_safety_2011/master_uml.png
Normal file
BIN
fmmd_concept/System_safety_2011/master_uml.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 24 KiB |
603
fmmd_concept/System_safety_2011/mybib.bib
Normal file
603
fmmd_concept/System_safety_2011/mybib.bib
Normal file
@ -0,0 +1,603 @@
|
||||
|
||||
|
||||
% 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{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{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 = {}
|
||||
};
|
||||
|
||||
501
fmmd_concept/System_safety_2011/submission.tex.backup
Normal file
501
fmmd_concept/System_safety_2011/submission.tex.backup
Normal file
@ -0,0 +1,501 @@
|
||||
\documentclass[twocolumn]{article}
|
||||
%\documentclass[a4paper,10pt]{report}
|
||||
|
||||
\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
|
||||
\newcommand{\oc}{\ensuremath{^{o}{C}}}
|
||||
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
|
||||
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
|
||||
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
|
||||
\newcommand{\fg}{\em functional~group}
|
||||
\newcommand{\fgs}{\em functional~groups}
|
||||
\newcommand{\dc}{\em derived~component}
|
||||
\newcommand{\dcs}{\em derived~components}
|
||||
\newcommand{\bc}{\em base~component}
|
||||
\newcommand{\bcs}{\em base~components}
|
||||
\newcommand{\irl}{in real life}
|
||||
\newcommand{\enc}{\ensuremath{\stackrel{enc}{\longrightarrow}}}
|
||||
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
|
||||
%\newcommand{\pic}{\em pure~intersection~chain}
|
||||
\newcommand{\pic}{\em pair-wise~intersection~chain}
|
||||
\newcommand{\wrt}{\em with~respect~to}
|
||||
\newcommand{\abslevel}{\ensuremath{\Psi}}
|
||||
\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functional groups of components and creating derived components representing them, and in turn using the derived components to create higher level functional groups, and so on, that are used to build a failure mode model of a SYSTEM}}}
|
||||
\newcommand{\fmodegloss}{\glossary{name={failure mode},description={The way in which a failure occurs. A component or sub-system may fail in a number of ways, and each of these is a
|
||||
failure mode of the component or sub-system}}}
|
||||
\newcommand{\fmeagloss}{\glossary{name={FMEA}, description={Failure Mode and Effects analysis (FMEA) is a process where each potential failure mode within a SYSTEM, is analysed to determine SYSTEM level failure modes, and to then classify them {\wrt} perceived severity}}}
|
||||
\newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure within a population (of size N), divided by N over a given time interval}}}
|
||||
\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
|
||||
\newcommand{\bcfm}{base~component~failure~mode}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
\fancyhf{}
|
||||
\fancyhead[LO]{}
|
||||
\fancyhead[RE]{\leftmark}
|
||||
|
||||
\cfoot{Page \thepage\ of \pageref{LastPage}}
|
||||
\rfoot{\today}
|
||||
\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark$^\star$ , Andrew~Fish$^\dagger$ , John~Howse$^\dagger$ , Chris Garret$^\dagger$ \\
|
||||
$^\star${\em Energy Technology Control, 25 North Street, Lewes, BN7 2PE, UK} \and $^\dagger${\em University of Brighton, UK}
|
||||
}
|
||||
|
||||
\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
|
||||
\maketitle
|
||||
|
||||
|
||||
\abstract{
|
||||
The certification process of safety critical products for European and
|
||||
other international standards often involve environmental stress,
|
||||
endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or 'static testing',
|
||||
is often also required. In general this will reveal modifications that must be made to
|
||||
improve the product safety, or identify theoretical weaknesses in the design.
|
||||
This paper proposes a new theoretical methodology for creating failure mode models of safety critical systems.
|
||||
It has a common notation for mechanical, electronic and software domains and is modular and hierarchical.
|
||||
These properties provide advantages in rigour and efficiency when compared to current methodologies.
|
||||
}
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
\subsection{Current methodologies}
|
||||
|
||||
We briefly analyse the four current methodologies.
|
||||
|
||||
\subsubsection{Fault Tree Analysis (FTA)}
|
||||
|
||||
FTA is a top down methodology in which a diagram is drawn for
|
||||
each undesirable top level event, presenting the conditions that must arise to cause
|
||||
the event. It is suitable for large complicated systems with few undesirable top
|
||||
level events and focuses on those events considered most important or most catastrophic.
|
||||
Effects of duplication/redundancy of safety systems can be readily assessed.
|
||||
It uses notations that are readily understood by engineers.
|
||||
However, it cannot guarantee to model all base component failure modes
|
||||
or be used to determine system level errors other than those modelled.
|
||||
Each diagram is a separate model, creating duplication of modelled elements,
|
||||
and there is no facility to cross check between diagrams. It has limited
|
||||
support for environmental and operational states.
|
||||
|
||||
|
||||
\subsection{Fault Mode Effects Analysis FMEA)}
|
||||
FMEA is used principally in manufacturing.
|
||||
Each defect is assessed by its cost to repair and its frequency, using a
|
||||
failure mode ratio. A list of failures and their cost is generated.
|
||||
It is easy to identify single component failure to system failure scenarios
|
||||
and an estimate of product reliability can be calculated. It cannot focus on
|
||||
component interactions that cause system failure modes or determine potential
|
||||
problems from simultaneous failure modes. It does not consider environmental
|
||||
or operational states in sub-systems or components. It cannot model
|
||||
self-checking safety elements or other in-built safety features or
|
||||
analyse how particular components may fail.
|
||||
|
||||
|
||||
\subsection{Failure Mode Criticality Analysis (FMECA)}
|
||||
FMECA is a refinement of FMEA, using
|
||||
two extra variables: the probability of a component failure mode occurring
|
||||
and the probability that this will cause a top level failure, and the perceived
|
||||
criticallity. It gives better estimations of product reliability/safety and the
|
||||
occurrence of particular system failure modes than FMEA but has similar deficiencies.
|
||||
|
||||
|
||||
\subsection{Failure Modes, Effects and Diagnostic Analysis (FMEDA)}
|
||||
|
||||
FMEDA is a refinement of
|
||||
FMEA and FMECA and models self-checking safety elements. It assigns two
|
||||
attributes to component failure modes: detectable/undetectable and safe/dangerous.
|
||||
Statistical measures about the system can be made and used to classify a
|
||||
safety integrity level. It allows designs with in-built safety features to be assessed.
|
||||
Otherwise, it has similar deficiencies to FMEA but has limited support
|
||||
for environmental and operational states in sub-systems or components,
|
||||
via self checking statistical mitigation.
|
||||
|
||||
\subsection{Summary of Defeciencies in Current Methods}
|
||||
|
||||
\subsubsection{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component
|
||||
level failure modes~\cite{faa}[Ch.9]. Also one FTA tree is drawn for each top level
|
||||
event, leading to repeated work, with limited ability for cross checking/model validation.
|
||||
|
||||
\subsubsection{Bottom-up approach: FMEA, FMECA, FMEDA}
|
||||
|
||||
\paragraph{State Explosion problem}
|
||||
The bottom -up techniques all suffer from a problem of state explosion.
|
||||
To perform the analysis rigorously, we need to consider the effect
|
||||
of a component failure against all other components. Adding environmental
|
||||
and operational states further increases this effect.
|
||||
|
||||
Let N be the number of components in our system, and K be the average number of component failure modes
|
||||
(ways in which a component can fail). The total number of base component failure modes
|
||||
is $N \times K$. To examine the effect that one failure mode has on all
|
||||
the other components\footnote{A %base
|
||||
component failure will typically affect the sub-system
|
||||
it is part of, and create a failure effect at the SYSTEM level.}
|
||||
will be $(N-1) \times N \times K$, in effect a very large set cross product.
|
||||
If $E$ is the number of environmental conditions to consider
|
||||
in a system, and $A$ the number of applied states (or modes of the SYSTEM),
|
||||
the job of the bottom-up analyst is presented with two
|
||||
additional %cross product
|
||||
factors,
|
||||
$(N-1) \times N \times K \times E \times A$.
|
||||
If we put some typical very small embedded system numbers\footnote{these figures would
|
||||
be typical of a very simple temperature controller, with a micro-controller sensor
|
||||
and heater circuit.} into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$
|
||||
we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $.
|
||||
To look in detail at a half of a million test cases is obviously impractical.
|
||||
% Requirements for an improved methodology The deficiencies identified in the
|
||||
% current methodologies are used to establish criteria for an improved methodology.
|
||||
|
||||
\paragraph{Reasoning distance - complexity and reach-ability.}
|
||||
Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
|
||||
working heuristically. A base component failure will typically
|
||||
be conceptually removed by several stages from a top level event.
|
||||
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
|
||||
that must interact to reach the top level event.
|
||||
Where $C$ represents the set of components in a failure mode causation chain,
|
||||
$c_i$ represents a component in $C$ and
|
||||
the function $fm$ returns the failure modes for a given component, equation
|
||||
\ref{eqn:complexity}, returns the `reasoning~distance'.
|
||||
\begin{equation}
|
||||
R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
|
||||
\label{eqn:complexity}
|
||||
\end{equation}
|
||||
|
||||
The reasoning distance is a value representing the number of failure modes
|
||||
to consider to rigorously determine the causation chain
|
||||
from the base component failure to the SYSTEM level event.
|
||||
|
||||
The reasoning distance serves to show that when the causes of a top level
|
||||
event are completely determined, a large amount of work not
|
||||
typical of heuristic or intuitive interpretation is required.
|
||||
% could have a chapter on this.
|
||||
% take a circuit or system and follow all the interactions
|
||||
% to the components that cause the system level event.
|
||||
|
||||
\paragraph{Multiple Events from one base component failure mode}
|
||||
A base component failure may potentially cause more than one
|
||||
SYSTEM level failure mode.
|
||||
It could be possible to identify one top level event associated with
|
||||
a {\bcfm} and not investigate other possibilities.
|
||||
|
||||
%\section{Requirements for a new static failure mode Analysis methodology}
|
||||
|
||||
\section{A wish list for a failure mode methodology}
|
||||
From the deficiencies outlined above, we can form a wish list for a better methodology.
|
||||
{ \small
|
||||
\begin{itemize}
|
||||
\item It must address the state explosion problem.
|
||||
\item It must ensure that all component failure modes be considered in the model.
|
||||
\item It should be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].
|
||||
\item It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
|
||||
\item It should have a formal basis, that is to say, be able to produce mathematical traceability
|
||||
for its results, such as error causation trees.%, reliability and safety statistics.
|
||||
\item It should be easy to use, ideally using a
|
||||
graphical syntax (as opposed to a formal symbolic/mathematical text based language).
|
||||
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
|
||||
to smaller and smaller functional groupings \cite{maikowski}.
|
||||
\item It must be possible for multiple (simultaneous) failure modes to be modelled.% from the base component level up.
|
||||
\end{itemize}
|
||||
}
|
||||
|
||||
% A new methodology must ensure that it represents all component failure modes and it therefore should be bottom-up,
|
||||
% starting with individual component failure modes.
|
||||
%
|
||||
% In order to control the state explosion problem, the process must be modular
|
||||
% and deal with small groups of components. The design process follows this
|
||||
% rationale, sub-systems are build to perform often basic functions from base components.
|
||||
% We can term these small groups {\fgs}.
|
||||
%
|
||||
% Components should be collected
|
||||
% into small functional groups to enable the examination of the effect of a
|
||||
% component failure mode on the other components in the group.
|
||||
% Once we have the failure modes, or symptoms of failure of a {\fg}
|
||||
% it can now be considered as `derived component' with a known set
|
||||
% of failure symptoms. We can use this `derived component' to build higher level
|
||||
% functional groups.
|
||||
%
|
||||
% This helps with the reasoning distance problem,
|
||||
% because we can trace failure modes back through complex interactions and have a structure to
|
||||
% base our reasoning on, at each stage.
|
||||
%
|
||||
|
||||
|
||||
%Development of the new methodology
|
||||
|
||||
\section{An ontology of failure modes}
|
||||
|
||||
An ontology is now developed of
|
||||
failure modes and their relationship to environmental factors,
|
||||
applied/operational states and the hierarchical nature inherent in product design,
|
||||
defining the relationships between the system as a whole, components,
|
||||
failure modes, operational and environmental states.
|
||||
|
||||
|
||||
Components have sets of failure modes associated with them.
|
||||
Failure modes for common components may be found in
|
||||
the literature~\cite{fmd91},~\cite{mil1991}.
|
||||
We can associate a component with its failure modes.
|
||||
This is represented in UML in figure \ref{fig:component_concept}.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt,keepaspectratio=true]{./component.png}
|
||||
% component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
|
||||
\caption{Component with failure modes UML diagram}
|
||||
\label{fig:component_concept}
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection{Modular Design}
|
||||
|
||||
When designing a system from the bottom-up, small groups of components are selected to perform
|
||||
simple functions. These can be termed {\fgs}.
|
||||
When the failure mode behaviour, or symptoms of failure
|
||||
of a {\fg} are determined, it can be treated as a component in its own right.
|
||||
|
||||
% Functional groups
|
||||
% are then brought together to form more complex and higher level {\fgs}.
|
||||
Used in this way the {\fg} has become a {\dc}. The symptoms of failure
|
||||
of the {\fg} can be considered the failure modes of its {\dc}.
|
||||
Derived~Components can be used to create higher level {\fgs}.
|
||||
Repeating this process will lead to identify-able higher level
|
||||
groups, often referred to as sub-systems. We can call the entire collection/hierarchy
|
||||
of sub-systems the SYSTEM.
|
||||
|
||||
|
||||
\subsection{Environmental Conditions, Operational States}
|
||||
|
||||
Any real world sub-system will exist in a variable environment
|
||||
and may have several modes of operation.
|
||||
In order to find all possible failures, a sub-system
|
||||
must be analysed for each operational state
|
||||
and environmental condition that could affect it.
|
||||
%
|
||||
A question is raised here: which objects should we
|
||||
associate the environmental and the operational states with ?
|
||||
There are three objects in our model to which these considerations could be applied.
|
||||
We could apply these conditions
|
||||
to {\fgs}, components, or {\dcs}.
|
||||
|
||||
\paragraph {Environmental Conditions.}
|
||||
|
||||
Environmental conditions are external to the
|
||||
{\fg} and are often things over which the system has no direct control.
|
||||
Consider ambient temperature, pressure or even electrical interference levels.
|
||||
%
|
||||
Environmental conditions may affect different components in a {\fg}
|
||||
in different ways.
|
||||
|
||||
For instance, a system may be specified for
|
||||
$0\oc$ to $85\oc$ operation, but some components
|
||||
may show failure behaviour between $60\oc$ and $85\oc$
|
||||
\footnote{Opto-isolators typically show marked performance decrease after
|
||||
$60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
|
||||
Other components may operate comfortably within that whole temperature range specified.
|
||||
Environmental conditions will have an effect on the {\fg} and the {\dc},
|
||||
but they will have specific effects on individual components.
|
||||
|
||||
It seems obvious that
|
||||
environmental conditions should apply to components.
|
||||
%A component will hold a set of environmental states that
|
||||
%affect it.
|
||||
|
||||
\paragraph {Operational States}
|
||||
|
||||
Sub-systems may have specific operational states.
|
||||
These could be a general health level, such as
|
||||
normal operation, graceful degradation or lockout.
|
||||
Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state.
|
||||
|
||||
Operational states are conditions that apply to some functional groups, not individual components.
|
||||
%% Andrew says that that does no make sense But I think it does
|
||||
%
|
||||
%\paragraph{Design Decision.}
|
||||
%Operational state will be applied to {\fg}s.
|
||||
%
|
||||
%\paragraph{UML Model of FMMD Analysis}
|
||||
%
|
||||
The UML diagram in figure \ref{fig:env_op_uml}, shows the data
|
||||
relationships between {\fgs} and operational states, and component
|
||||
failure modes and environmental factors.
|
||||
|
||||
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[width=200pt,bb=0 0 818 249,keepaspectratio=true]{./fmmd_env_op_uml.png}
|
||||
% % fmmd_env_op_uml.jpg: 818x249 pixel, 72dpi, 28.86x8.78 cm, bb=0 0 818 249
|
||||
% \caption{UML model of Environmental and Operational states w.r.t FMMD}
|
||||
% \label{fig:env_op_uml}
|
||||
% \end{figure}
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt]{./fmmd_env_op_uml.png}
|
||||
% fmmd_env_op_uml.png: 816x246 pixel, 72dpi, 28.79x8.68 cm, bb=0 0 816 246
|
||||
\caption{UML model of failure mode ontology}
|
||||
\label{fig:env_op_uml}
|
||||
\end{figure}
|
||||
|
||||
%This is because environmental conditions will apply SYSTEM wide,
|
||||
%but may only affect specific components.
|
||||
|
||||
%DEVELOP UML MODELS
|
||||
|
||||
|
||||
|
||||
\section{The proposed Methodology}
|
||||
|
||||
Th
|
||||
|
||||
|
||||
\subsection{Re-Factoring the UML Model}
|
||||
|
||||
The UML models thus far % in this
|
||||
have been used to develop the ontology. % data relationships required to perform FMMD analysis.
|
||||
We can now re-organise and rationalise the UML model.
|
||||
We want to be able to use {\dcs} in functional groups.
|
||||
It therefore makes sense for {\dc} to inherit {\em component}.
|
||||
|
||||
The re-factored UML diagram is shown in figure \ref{fig:refactored_uml}.
|
||||
|
||||
|
||||
% \begin{figure}[h]
|
||||
% \centering
|
||||
% \includegraphics[width=200pt,bb=0 0 702 464]{./master_uml.png}
|
||||
% % master_uml.jpg: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
|
||||
% \caption{Re-factored UML Diagram}
|
||||
% \label{fig:refactored_uml}
|
||||
% \end{figure}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=200pt]{./master_uml.png}
|
||||
% master_uml.png: 700x462 pixel, 72dpi, 24.69x16.30 cm, bb=0 0 700 462
|
||||
\caption{Re-factored UML Diagram }
|
||||
\label{fig:refactored_uml}
|
||||
\end{figure}
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Derived components can be
|
||||
used to build functional groups at a higher level. In this manner we
|
||||
can build a hierarchical model with each layer consisting of
|
||||
components derived from the functional groups of derived components.
|
||||
From the ontology, a set of rules for simplifying the failure
|
||||
modes (collecting them into common symptoms) as we traverse up the
|
||||
hierarchy is developed. The hierarchical model can have layers added
|
||||
until it converges to a top level single functional group. On collecting
|
||||
symptoms from this, we are left with the top level, or system level, failure modes.
|
||||
The model is presented in a diagrammatic notation that has been
|
||||
designed to be intuitive and understandable. It uses well tested
|
||||
visual techniques to represent the elements of the model and their
|
||||
relationships. Software support for the development of models in this
|
||||
notation has been designed and proof-of-concept tools have been implemented.
|
||||
|
||||
|
||||
\subsection{Justification of wishlist}
|
||||
|
||||
By applying the methodology in section \ref{fmmdproc}, the wishlist can
|
||||
now be evaluated for the proposed FMMD methodology.
|
||||
|
||||
{ \small
|
||||
\begin{itemize}
|
||||
\item{State Explosion must be reduced.}
|
||||
Because small collections of components are dealt with in functional groups
|
||||
the state explosion problem is effectively dealt with.
|
||||
|
||||
\item{All component failure modes must be considered in the model.}
|
||||
The proposed methodology will be bottom-up.
|
||||
This ensures that all component failure modes are handled.
|
||||
|
||||
|
||||
\item{ It should be easy to integrate mechanical, electronic and software models.}
|
||||
Because component failure modes are considered, we have a generic entity to model.
|
||||
We can describe a mechanical, electrical or software component in terms of its failure modes.
|
||||
%
|
||||
Because of this
|
||||
we can model and analyse integrated electromechanical systems, controlled by computers,
|
||||
using a common notation.
|
||||
|
||||
\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
|
||||
The hierarchical nature, taking {\fg}s and deriving components from them, means that
|
||||
commonly used {\dcs} can be re-used in a design (for instance self checking digital inputs)
|
||||
or even in other projects where the same {\dc} is used.
|
||||
|
||||
|
||||
|
||||
\item{ It should have a formal basis, data should be available to produce mathematical proofs
|
||||
for its results}
|
||||
Because the failure mode of a SYSTEM is a hierarchy of {\fg}s and derived components
|
||||
SYSTEM level failure modes are traceable back down the fault tree to
|
||||
component level failure modes. This provides causation trees \cite{sccs} or, minimal cut sets
|
||||
for all SYSTEM failure modes.
|
||||
|
||||
\item{ It should be capable of producing reliability and danger evaluation statistics.}
|
||||
The minimal cuts sets for the SYSTEM level failures can have computed MTTF
|
||||
and danger evaluation statistics sourced from the component failure mode statistics \cite {mil1991}.
|
||||
|
||||
\item{ It should be easy to use, ideally
|
||||
using a graphical syntax (as opposed to a formal mathematical one).}
|
||||
A modified form of constraint diagram (an extension of Euler diagrams) has
|
||||
been developed to support the FMMD methodology.
|
||||
This uses Euler circles to represent failure modes, and spiders to collect symptoms, to
|
||||
advance a {\fg} to a {\dc}.
|
||||
|
||||
|
||||
\item{ From the top down the failure mode model should follow a logical de-composition of the functionality
|
||||
to smaller and smaller functional modules \cite{maikowski}.}
|
||||
The bottom-up approach fulfils the logical de-composition requirement, because the {\fg}s
|
||||
are built from components performing a given task.
|
||||
|
||||
|
||||
\item{ Multiple failure modes may be modelled from the base component level up.}
|
||||
By breaking the problem of failure mode analysis into small stages
|
||||
and building a hierarchy, the problems associated with the cross products of
|
||||
all failure modes within a system are reduced by an exponential order.
|
||||
This is because the multiple failure modes are considered
|
||||
within {\fgs} which have fewer failure modes to consider
|
||||
at each FMMD stage.
|
||||
Where appropriate, multiple simultaneous failures can be modelled by
|
||||
introducing test~cases where the conjunction of failure modes is considered.
|
||||
\end{itemize}
|
||||
}
|
||||
|
||||
%\clearpage
|
||||
\section{Conclusion}
|
||||
|
||||
This new approach is called
|
||||
Failure Mode Modular De-Composition (FMMD) and is designed
|
||||
to be a superset of the current four approaches, that is to say,
|
||||
from an FMMD model, we should be able to
|
||||
derive models that the other four methodologies would have been
|
||||
able to create. As this approach is modular, many of the results of
|
||||
analysed components may be re-used in other projects, so
|
||||
test efficiency is improved.
|
||||
FMMD is based on generic failure modes, so it is not constrained to a
|
||||
particular field. It can be applied to mechanical, electrical or software domains.
|
||||
It can therefore be used to analyse systems comprised of electrical,
|
||||
mechanical and software elements in one integrated model.
|
||||
|
||||
\today
|
||||
%
|
||||
{ \tiny
|
||||
\bibliographystyle{plain}
|
||||
\bibliography{vmgbibliography,mybib}
|
||||
}
|
||||
|
||||
\today
|
||||
\end{document}
|
||||
|
||||
1756
fmmd_concept/System_safety_2011/vmgbibliography.bib
Normal file
1756
fmmd_concept/System_safety_2011/vmgbibliography.bib
Normal file
File diff suppressed because it is too large
Load Diff
Loading…
Reference in New Issue
Block a user