conditional compilation to remove abstract from chapters, and replace them with overview sections
This commit is contained in:
parent
69a813989f
commit
0e1410764a
@ -1,10 +1,17 @@
|
||||
%
|
||||
% 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}
|
||||
|
||||
|
@ -4,6 +4,12 @@
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
|
||||
\input{../style}
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
@ -1,14 +1,17 @@
|
||||
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\abstract{ This chapter defines what is meant by the terms
|
||||
components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
|
||||
%The application of Bayes theorem in current methodologies, and
|
||||
%the suitability of the `null hypothesis' or `P' value statistical approach
|
||||
%are discussed.
|
||||
Data types and their relationships are described using UML.
|
||||
Mathematical constraints and definitions are made using set theory.
|
||||
Mathematical constraints and definitions are made using set theory.}
|
||||
}
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
This chapter describes the data types and concepts for the Failure Mode Modular De-composition (FMMD) method.
|
||||
When analysing a safety critical system using
|
||||
|
@ -4,14 +4,18 @@
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\input{style}
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
\input{../style}
|
||||
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
|
||||
\outerhead{{\small\bf 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
|
||||
|
@ -13,6 +13,8 @@
|
||||
%
|
||||
|
||||
|
||||
\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'.
|
||||
@ -24,6 +26,10 @@ 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}
|
||||
|
||||
|
@ -2,8 +2,10 @@
|
||||
|
||||
%
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
This chapter describes a process for analysing safety critical systems, to formally prove how safe the
|
||||
This paper describes a process for analysing safety critical systems, to formally prove how safe the
|
||||
designs and built -in safety measures are. It provides
|
||||
the rigourous method for creating a fault effects model of a system from the bottom up using part level fault modes.
|
||||
From the model fault trees,
|
||||
@ -12,9 +14,9 @@ and accurate, statistical estimation for fault frequency can be derived automati
|
||||
It provides the means to trace the causes of dangerous detected and dangerous undetected faults.
|
||||
It is intended to be used to formally prove systems to meet EN and UL standards, including and not limited to
|
||||
EN298, EN61508, EN12067, EN230, UL1998.
|
||||
|
||||
\end{abstract}
|
||||
|
||||
}
|
||||
{}
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
@ -4,13 +4,18 @@
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath}
|
||||
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
\input{../style}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
|
||||
\outerhead{{\small\bf Propositional Logic Diagram}}
|
||||
\innerfoot{{\small\bf R.P. Clark } }
|
||||
%\outerhead{{\small\bf Propositional Logic Diagram}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
\author{R.P.Clark}
|
||||
|
39
fzd/fzd.tex
39
fzd/fzd.tex
@ -1,9 +1,10 @@
|
||||
\abstract{
|
||||
This
|
||||
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{paper}
|
||||
{chapter}
|
||||
discusses a two stage algorithm designed to greatly
|
||||
{
|
||||
\abstract{
|
||||
This paper discusses a two stage algorithm designed to greatly
|
||||
reduce the number of Area compare operations required to determine which zones are `available' in an Euler
|
||||
diagram.
|
||||
|
||||
@ -24,6 +25,34 @@ The next stage reduces the number of searches required within the isolated
|
||||
groups, (thus reducing the $M.2^{nn}$ terms) by traverssing a graph
|
||||
of the relationships between the contours.
|
||||
}
|
||||
}
|
||||
{ %% Introduction
|
||||
\section{Algorithm Purpose}
|
||||
|
||||
This paper discusses a two stage algorithm designed to greatly
|
||||
reduce the number of Area compare operations required to determine which zones are `available' in an Euler
|
||||
diagram.
|
||||
|
||||
This algorithm will aid in the quick resolution of complex drawn
|
||||
Euler diagrams where the available zones on the diagram must be known.
|
||||
|
||||
An Euler diagram of $N$ contours has a possible $2^N$ zones.
|
||||
A `brute force' search for available zones (determining for availability of all possible $2^N$
|
||||
zones) involves $N.2^N$ Area Compare operations.
|
||||
|
||||
The first stage of the algorithm identifies $M$ number of unique groups of contours that are isolated
|
||||
w.r.t. zone production. Thus each identified group of $nn$ contours
|
||||
has a maximum of $2^{nn}$ zones. This reduces the exponential overhead of the $N.2^N$ order.
|
||||
In fact we reduce the number of stages to search from a $N.2^N$ order
|
||||
to approximately $N^2 + M.2^{nn}$.
|
||||
|
||||
The next stage reduces the number of searches required within the isolated
|
||||
groups, (thus reducing the $M.2^{nn}$ terms) by traverssing a graph
|
||||
of the relationships between the contours.
|
||||
}
|
||||
|
||||
|
||||
|
||||
\section{Introduction : Euler Diagram and Zones Available for use}
|
||||
|
||||
Euler diagrams consist of closed curves in the plane which are used to represent sets.
|
||||
|
@ -1,5 +1,6 @@
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
%This chapter describes using diagrams to represent propositional logic.
|
||||
Propositial Logic Diagrams have been designed to provide an intuitive method for visualising and manipulating
|
||||
@ -27,6 +28,8 @@ automated systems.
|
||||
The Diagrams described here form the mathematical basis for a new visual and formal system
|
||||
for the analysis of safety critical software and hardware systems.
|
||||
\end{abstract}
|
||||
}
|
||||
{}
|
||||
|
||||
%\title{Propositional Logic Diagrams}
|
||||
%\begin{keyword}
|
||||
@ -115,6 +118,7 @@ practical differences between the way they are used to represent software as opp
|
||||
representing electronics and mechanical systems.
|
||||
|
||||
\subsection{Concrete PLD Definition}
|
||||
\paragraph{MUST REFERENCE CONSTRAINT DIAGRAMS HERE}
|
||||
|
||||
A concrete {\em Propositional logic diagram} is a set of labeled {\em contours}
|
||||
(closed curves) in the plane. The minimal regions formed by the closed curves
|
||||
|
@ -4,6 +4,11 @@
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
\input{style}
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
@ -4,6 +4,13 @@
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
|
||||
|
||||
\input{../style}
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
@ -11,7 +18,7 @@
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
|
||||
\outerhead{{\small\bf PT100 FMMD analysis}}
|
||||
%\outerhead{{\small\bf PT100 FMMD analysis}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
|
@ -1,6 +1,7 @@
|
||||
%
|
||||
% Make the revision and doc number macro's then they are defined in one place
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
The PT100, or platinum wire \ohms{100} sensor is
|
||||
a widely used industrial temperature sensor that is
|
||||
@ -21,7 +22,7 @@ Thus after the analysis the PT100 temperature sensing circuit, may be veiwed
|
||||
from an FMEA persepective as a component itself, with a set of known failure modes.
|
||||
|
||||
\end{abstract}
|
||||
|
||||
}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
@ -69,7 +70,8 @@ because of resistance in the cables. Resistance from the supply
|
||||
drop in the supply to the PT100. As no significant current
|
||||
is carried by the two `sense' lines the resistance back to the ADC
|
||||
causes only a negligible voltage drop, and thus the four wire
|
||||
configuration is more accurate.
|
||||
configuration is more accurate\footnote{The increased accuracy is because the voltage measured, is the voltage across
|
||||
the thermistor and not the voltage across the thermistor and current supply wire resistance.}.
|
||||
|
||||
\subsection{Calculating Temperature from \\ the sense line voltages}
|
||||
|
||||
@ -84,7 +86,7 @@ does not impinge on accuracy.
|
||||
The resistance to temperature conversion is achieved
|
||||
through the published PT100 tables\cite{eurothermtables}.
|
||||
The standard voltage divider equations (see figure \ref{fig:vd} and
|
||||
equation \ref{eqn:vd} can be used to calculate
|
||||
equation \ref{eqn:vd}) can be used to calculate
|
||||
expected voltages for failure mode and temperature reading purposes.
|
||||
|
||||
\begin{figure}[h]
|
||||
|
@ -5,13 +5,17 @@
|
||||
\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 Safety Critical Standards Review}}
|
||||
%\outerhead{{\small\textbf Safety Critical Standards Review}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
|
@ -1,16 +1,36 @@
|
||||
%
|
||||
% Make the revision and doc number macro's then they are defined in one place
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
This chapter describes the legal frameworks and standards organisations
|
||||
that exist in Europe and North America.
|
||||
Some specific standards (that the author has experience with directly)
|
||||
are reviewed.
|
||||
\end{abstract}
|
||||
}
|
||||
{}
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
||||
\subsection{Product Life Cycle}
|
||||
i
|
||||
difffernent areas
|
||||
EN61508 REQ to SPEC to DESIGN
|
||||
|
||||
|
||||
EN298
|
||||
DESIGN TO PRODUCT
|
||||
|
||||
FM
|
||||
PRODUCT VERIFICATION MONITORING
|
||||
|
||||
Different agencies - approval is testing of new product
|
||||
and verification to standard - manufacturing overwatch / supervision
|
||||
word on tip of tounge -
|
||||
|
||||
\section{European or `EN' Standards}
|
||||
|
||||
\subsection{Scope}
|
||||
|
@ -4,7 +4,7 @@
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex statistics.tex
|
||||
paper: paper.tex statistics_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
@ -13,5 +13,5 @@ paper: paper.tex statistics.tex
|
||||
|
||||
# Remove the need for referncing graphics in subdirectories
|
||||
#
|
||||
statistics.tex: statistics.tex paper.tex
|
||||
statistics_paper.tex: statistics.tex paper.tex
|
||||
cat statistics.tex | sed 's/statistics\///' > statistics_paper.tex
|
||||
|
@ -4,14 +4,18 @@
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\input{style}
|
||||
%\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}}
|
||||
%\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
|
||||
|
@ -1,8 +1,14 @@
|
||||
|
||||
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\abstract{ This chapter looks at current methodologies
|
||||
for static analysis of safety critical systems
|
||||
and looks at the statistical justifications for their application.
|
||||
and looks at the statistical justifications for their application.}
|
||||
}
|
||||
{}
|
||||
|
||||
|
||||
\section{Introduction}
|
||||
|
@ -4,14 +4,18 @@
|
||||
\usepackage{fancyhdr}
|
||||
\usepackage{tikz}
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\input{../style}
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
%\input{../style}
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
||||
\begin{document}
|
||||
\pagestyle{fancy}
|
||||
|
||||
\outerhead{{\small\bf Survey of Safety Critical Static Analysis Methods}}
|
||||
%\outerhead{{\small\bf Survey of Safety Critical Static Analysis Methods}}
|
||||
%\innerfoot{{\small\bf R.P. Clark } }
|
||||
% numbers at outer edges
|
||||
\pagenumbering{arabic} % Arabic page numbers hereafter
|
||||
|
@ -1,9 +1,13 @@
|
||||
%
|
||||
% Make the revision and doc number macro's then they are defined in one place
|
||||
|
||||
ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
|
||||
A very abstract abstract
|
||||
\end{abstract}
|
||||
}
|
||||
{}
|
||||
|
||||
\section{FMEA}
|
||||
|
||||
|
@ -27,6 +27,9 @@
|
||||
% \address{ Energy Technology Control\\
|
||||
% 25 North Street, Lewes, BN7 2PE, Great Britain}
|
||||
%
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
This chapter describes how software can be represented by first order logic, and how
|
||||
software elements be represented in a propositional logic diagram.
|
||||
@ -34,7 +37,8 @@ When represented in this way they can be combined with other PLD's representing
|
||||
Thus, Fault Mode Effects Analysis (FMEA) can be applied to electro/software/mechanical systems
|
||||
using a common mathematically based formal graphical notation.
|
||||
\end{abstract}
|
||||
|
||||
}
|
||||
{}
|
||||
%
|
||||
%\begin{keyword}
|
||||
% fault~tree fault~mode EN298 EN61508 EN12067 EN230 UL1998 safety~critical logic euler venn propositional
|
||||
|
@ -1,4 +1,6 @@
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
In modular systems design, it is often very useful to
|
||||
know the failure modes of the sub-systems used.
|
||||
@ -33,7 +35,8 @@ automatically, where component failure mode statistics are available\cite{mil199
|
||||
This paper focuses on the process of building the blocks that are used in the hierarchy.
|
||||
|
||||
\end{abstract}
|
||||
|
||||
}
|
||||
{}
|
||||
%\clearpage
|
||||
|
||||
\section{Introduction}
|
||||
|
@ -6,6 +6,10 @@
|
||||
\usepackage{amsfonts,amsmath,amsthm}
|
||||
\usepackage{algorithm}
|
||||
\usepackage{algorithmic}
|
||||
\usepackage{ifthen}
|
||||
\newboolean{paper}
|
||||
\setboolean{paper}{true} % boolvar=true or false
|
||||
|
||||
%\input{../style}
|
||||
|
||||
%\newtheorem{definition}{Definition:}
|
||||
|
@ -1,4 +1,7 @@
|
||||
|
||||
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
\begin{abstract}
|
||||
In failure mode analysis, it is essential to
|
||||
know the failure modes of the sub-systems and components used.
|
||||
@ -35,6 +38,9 @@ automatically, where component failure mode statistics are available\cite{mil199
|
||||
This paper focuses on the process of building the blocks, that are key to creating an FMMD hierarchy.
|
||||
|
||||
\end{abstract}
|
||||
}
|
||||
{}
|
||||
|
||||
|
||||
%\clearpage
|
||||
|
||||
@ -669,8 +675,9 @@ We now have a set $SP$ of the symptoms of failure.
|
||||
|
||||
Algorithm \ref{alg:sympabs55} is the final stage in the process. We now have a
|
||||
derived~component $DC$, which has its own set of failure~modes. This can now be
|
||||
% treated as a component, and
|
||||
used in conjection with other components (or derived~components) to form functional~groups at a higher level of failure~mode~abstraction.
|
||||
used in conjection with other components (or derived~components)
|
||||
to form functional~groups at a higher level of failure~mode~abstraction.
|
||||
Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
|
||||
\end{algorithmic}
|
||||
\end{algorithm}
|
||||
|
||||
@ -683,8 +690,9 @@ The technique provides a methodology for bottom-up analysis of the fault behavio
|
||||
|
||||
Because symptom abstraction collects fault modes, the number of faults to handle decreases
|
||||
as the hierarchy progresses upwards.
|
||||
This is seen in real life Systems. At the highest levels the number of faults
|
||||
reduces. A Sound system might have, for instance only four faults at its highest or System level,
|
||||
This is seen by casual observation of real life Systems. At the highest levels the number of faults
|
||||
is significantly less than the sum of its component failure modes.
|
||||
A Sound system might have, for instance only four faults at its highest or System level,
|
||||
\small
|
||||
$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
|
||||
\normalsize
|
||||
|
Loading…
Reference in New Issue
Block a user