.

papers/software_fmea/mybib.bib

@@ -110,6 +110,13 @@ methodology",
   YEAR =         "2002"
 }
 
+@BOOK{misra,
+  AUTHOR =       "Gavin McCall",
+  TITLE =        "MISRA:C:2004 Guidelines for the use of the C language in critical systems ISBN 978-0-9524156-4-0   ",
+  PUBLISHER =      "Hobbs",
+  YEAR =         "2004"
+}
+
 @BOOK{alggraph,
   AUTHOR =       "Alan Gibbons",
   TITLE =        "Algorithmic Graph Theory ISBN:978-0521288811   ",
@@ -250,7 +257,7 @@ methodology",
 
 @BOOK{kandr,
   AUTHOR =       "Kernighan,Ritchie",
-  TITLE =        "The C programming Language 2nd edition",
+  TITLE =        "The C programming Language 2nd edition ISBN 0-13-110362-8",
   PUBLISHER =    "Prentise Hall",
   YEAR =         "1988"
 }

papers/software_fmea/software_fmea.tex

@@ -169,7 +169,7 @@ and then definitions from contract programming are used
 to define failure modes and failure symptoms in 
 software functions.
 With these definitions we can apply FMEA
-to existing software\footnote{Existing software excluding recursive code, and unstructured non-functional languages}.
+to existing software\footnote{Existing software excluding recursive~\cite{misra}[16.2] code, and unstructured non-functional languages}.
 }
  
 \section{FMEA Background}
@@ -321,7 +321,7 @@ to software functions.
 \subsection{Software, a natural hierarchy}
 
 Software written for safety critical systems is usually constrained to
-be modular~\cite{en61508}[3]~\cite{misra}[cc] and non recursive~\cite{misra}[aa]~\cite{iec61511}.
+be modular~\cite{en61508}[3]~\cite{misra}[cc] and non recursive~\cite{misra}[15.2]{iec61511}.
 Because of this we can assume a direct call tree.  Functions call functions
 from the top down and eventually call the lowest level library or IO
 functions that interact with hardware/electronics.