robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

looking at journal article

Browse Source
This commit is contained in:
Robin Clark 2015-08-19 20:05:08 +01:00
parent 4ae48a5649
commit 12a4e0e337
2 changed files with 46 additions and 24 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex
View File

@ -131,7 +131,10 @@ failure mode of the component or sub-system}}}
%\small
\abstract{ % \em
%\input{abs}
%\input{abs}%
The intention of this paper is to demonstrate an FMEA methodology that can
analyse integrated hardware/software systems and has test efficiency benefits.
%
The certification process of safety critical products for European and
other international standards often demand environmental stress,
endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or 'static testing',
@ -170,8 +173,7 @@ the ability to model integrated hardware and software systems.
To demonstrate FMMD a small, but complete embedded system
(including both software and hardware)
worked example is presented to show FMMD applied to an
integrated electronics/software system.
is analysed for failure mode effects.
%, the industry standard
%{\ft} signalling loop.
%
@ -263,7 +265,9 @@ is implemented at the bottom, which prepares input/output (IO)
signals for/from the micro controller.
The micro controller will have software to read/send signals to the electronics
and on top of that a functional software layer where the control algorithms will
reside. On the top of this hierarchy are the \cf{main} and \cf{monitor} functions.
reside.
%
Typically at the top of this hierarchy are the \cf{main} and \cf{monitor} functions.
This hierarchy is represented in figure~\ref{fig:sw_hw_hierarchy}.
\begin{figure}[h]+
@ -282,7 +286,7 @@ do not specify FMEA for software but instead essentially just specify good pract
i.e. review processes and language feature constraints.
%
That is to say FMEA has no formal framework for following
failure modes from low level hardware elements through into software models.
failure modes from low level hardware elements through into software models~\cite{sfmeainterface}.
%
This is a weakness.
%
@ -482,10 +486,10 @@ within the system would have to be examined against all its other components.
No current FMEA variant gives guidelines for the components that should
be included to analyse a {\fm} in a system.
%
Were a {\fm} examined against all the other components in a system
this gives a maximum reasoning distance.
Were each {\fm} examined against all the other components in a system
this would a maximum reasoning distance --- for that particular {\fm}.
%
This is termed the exhaustive FMEA (XFMEA). % case for a single {\fm}.
This is termed an exhaustive FMEA case (XFMEA). % case for a single {\fm}.
%does not
% The exhaustive~reasoning~distance would be
% the sum of the number of failure modes, against all other components
@ -511,8 +515,8 @@ methodologies).
%
%\fmmdglossSTATEEX
%
A high reasoning distance, because it is a manual process performed by experts, is both
expensive in terms of time and money.
A high reasoning distance, because it is a manual process performed by experts, is
expensive in both terms of time and money.
%
It is apparent also that the shorter the reasoning distance, the more precisely theoretical examination
can determine failure symptoms. A shorter reasoning distance therefore implies a higher quality of safety analysis.
@ -905,7 +909,7 @@ failed component will have to be traced through
several sub-systems, gauging its effects with and on other components.
%
With software at the higher levels of these sub-systems,
there is yet another layer of complication.
this introduces another layer of complication.
%
%In order to integrate software, %in a meaningful way
%we need to re-think the
@ -916,11 +920,11 @@ there is yet another layer of complication.
% calculated incorrectly (due to a mistake by the programmer, or a fault in the micro-processor on which it is running), or
% external influences such as
% ionising radiation causing bits to be erroneously altered.
It is desirable to trace failure modes effects through the hardware and software interfaces.
However It is desirable to trace failure modes effects through the hardware and software interfaces.
This is for two reasons.
%
The first is to ensure that the software can detect all possible
hardware failures, and secondly that the software reacts appropriately.
hardware failures, and secondly that the software actually reacts appropriately.
@ -928,17 +932,17 @@ hardware failures, and secondly that the software reacts appropriately.
\section{FMEA defeciences and `wishlist'}
%\subsection{FMEA - General Criticism}
A summary of deficiencies in current FMEA methodologies is listed below:
A summary of deficiencies in current FMEA methodologies are listed below:
\begin{itemize}
%\item FMEA type methodologies were designed for simple electro-mechanical systems of the 1940's to 1960's,
\item State explosion - %impossible
very difficult/time consuming to perform FMEA exhaustively, %rigorously
\item Difficult to re-use previous analysis work~\cite{rudov2009language},
\item Very difficult to model simultaneous/multiple failures,
\item Software and hardware models are separate (if the software is modelled at all) meaning the software interface may not be correctly modelled,
\item Software and hardware models are treated separately (if the software is modelled at all) meaning the software interface may not be correctly modelled,
%\item reasoning distance -- component failure to system level symptom process is undefined in regard
%to the components to check against each given component {\fm},
\item FMEA methodologies are undefined in regard to which components to check against given failure modes,
\item FMEA methodologies are undefined in regard to scope, i.e. which components to check against given failure modes,
%
\item Distributed real time systems are very difficult to analyse with FMEA because they typically involve many hardware/software interfaces.
\end{itemize}
@ -1099,11 +1103,17 @@ system is included. The top level failure symptoms are the ways in which the sys
An advantage of this, is that all component failure modes must be considered
in terms of their effects as the system goes from the
lower levels through to more abstract system level failures.
This can lead to surprises. Often when a system is evaluated
%
This can lead to surprises.
%
Often when a system is evaluated
by FMMD a list of system level failures can include ones
that are not currently dealt with or even detectable
without some re-design. Having surprises at the design
and not in~the~field is a very good thing
without some re-design.
%
Having surprises at the design
and not during beta~test (or even in~the~field) is a very good thing
when dealing with safety critical systems!
@ -1112,9 +1122,9 @@ it too can be treated as an FMMD {\fg}.
%Software functions are treated as components as well, and
%treat the hardware they interface to (if any) as components.
A software functions `components' are the software functions it calls
and the hardware elements it interfaces to (if any.
but eventually
all software hierarchies reach down to hardware, or they would not do anything in the real world).
and the hardware elements it interfaces to (if any).
Eventually
all software hierarchies must reach down to hardware in order to react with the real world.
An example of a hardware low level analysis is given in~\cite{syssafe2011} and a combined
software hardware sub-system in~\cite{syssafe2012}. Examples of both, including analysis of performance
@ -1351,8 +1361,8 @@ The software then applies a PID~\cite{dcods} algorithm to determine the length/m
\subsection{Closed Loop Control Hardware/Software Hybrid Example}
It is desirable to model a complete standalone system with FMMD,
not only a standalone system, but ideally a hybrid software/hardware system.
%It is desirable to model a complete standalone system with FMMD,
%not only a standalone system, but ideally a hybrid software/hardware system.
%
Temperature control is typically a first order differential problem, and is often
addressed using the Proportional Integral Differential (PID) algorithm~\cite{dcods}[p.66].

12
papers/fermat/fermat.tex
View File

@ -413,6 +413,18 @@ Or a general way of showing $a^n + b^n \; where \; n > 2$ cannot produce a simpl
That is the last thing........ that is the only way flt can have an exception, where $a \perp b$, AND
it produces a $c^n$ where c is an integer.....
BUT IS IT A HOLE
IT JUST MEANS THERE IS ONLY one special case for an flt
Common primes are disproved in this way,
only where $a^n + b^n = \forall p \in c^n | p \perp a \wedge p \perp b$ can actually work and this
means $a \perp b$.
$ a \perp b \perp c $ this is actually how it works for Pythagorean triangles.
Is there anyway to go back from $\forall p \in c^n | p \perp a \wedge p \perp b $
\section{Further work}
Using the rule of adding uncommon factors, an iterative `fishing' method for finding prime numbers can be applied.