diff --git a/papers/fmmd_software_hardware/hd.dia b/papers/fmmd_software_hardware/hd.dia index 5f7b599..9d8a730 100644 Binary files a/papers/fmmd_software_hardware/hd.dia and b/papers/fmmd_software_hardware/hd.dia differ diff --git a/papers/software_fmea/hd.dia b/papers/software_fmea/hd.dia index 5f7b599..9d8a730 100644 Binary files a/papers/software_fmea/hd.dia and b/papers/software_fmea/hd.dia differ diff --git a/submission_thesis/CH5_Examples/Makefile b/submission_thesis/CH5_Examples/Makefile index 012686d..2749f47 100644 --- a/submission_thesis/CH5_Examples/Makefile +++ b/submission_thesis/CH5_Examples/Makefile @@ -4,7 +4,7 @@ PNG_DIA = blockdiagramcircuit2.png bubba_oscillator_block_diagram.png circuit1 dubsim1.png invamp.png mvampcircuit.png pd.png plddouble.png plddoublesymptom.png \ poss1finalbubba.png poss2finalbubba.png pt100.png pt100_doublef.png pt100_singlef.png \ pt100_tc.png pt100_tc_sp.png shared_component.png stat_single.png three_tree.png \ - tree_abstraction_levels.png vrange.png sigma_delta_block.png + tree_abstraction_levels.png vrange.png sigma_delta_block.png ftcontext.png ct1.png hd.png diff --git a/submission_thesis/CH5_Examples/copy.tex b/submission_thesis/CH5_Examples/copy.tex index 804cb36..fc58130 100644 --- a/submission_thesis/CH5_Examples/copy.tex +++ b/submission_thesis/CH5_Examples/copy.tex @@ -2677,7 +2677,626 @@ because here we have found a fault that we cannot detect at this level. This means that should we wish to cope with this fault, we need to devise a way of detecting this condition in higher levels of the system. -\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.}} +\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. Associated with continuous demand systems under EN61508~\cite{en61508}}} + + + + +\section{Applying FMMD to Software} + +FMMD can be applied to software, and thus we can build complete failure models +of typical modern safety critical systems. +With modular FMEA i.e. FMMD %(FMMD) +we have the concepts of failure~modes +of components, {\fgs} and symptoms of failure for a functional group. + +A programmatic function has similarities with a {\fg} as defined by the FMMD process. +% +An FMMD {\fg} is placed into a hierarchy. +A Software function is placed into a hierarchy, that of its call-tree. +A software function typically calls other functions and uses data sources via hardware interaction, which could be viewed as its `components'. +It has outputs, i.e. it can perform actions +on data or hardware +which will be used by functions that may call it. + +We can map a software function to a {\fg} in FMMD. Its failure modes +are the failure modes of the software components (other functions it calls) +and the hardware its reads values from. +Its outputs are the data it changes, or the hardware actions it performs. + +When we have analysed a software function---using failure conditions +of its inputs as failure modes---we can +determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour). + +We can thus apply the $\derivec$ process to software functions, by viewing them in terms of their failure +mode behaviour. To simplify things as well, software already fits into a hierarchy. +For Electronics and Mechanical systems, although we may be guided by the original designers +concepts of modularity and sub-systems in design, applying FMMD means deciding on the members for {\fgs} +and the subsequent hierarchy. With software already written, that hierarchy is fixed. + +% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% +%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% failure modes of a function in order to +%map FMMD to software. + + + +% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% +%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% failure modes of a function in order to +%map FMMD to software. + +\subsection{Software, a natural hierarchy} + +Software written for safety critical systems is usually constrained to +be modular~\cite{en61508}[3] 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. + +What is potentially difficult with a software function, is deciding what +are failure modes, and later what a failure symptoms. +With electronic components, we can use literature to point us to suitable sets of +{\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}.%~\cite{en61508}~\cite{en298}. +With software, only some library functions are well known and rigorously documented +enough to have the equivalent of known failure modes. +Most software is `bespoke'. We need a different strategy to +describe the failure mode behaviour of software functions. +We can use definitions from contract programming to assist here. + +\subsection{Contract programming description} + +Contract programming is a discipline~\cite{dbcbe} for building software functions in a controlled +and traceable way. Each function is subject to pre-conditions (constraints on its inputs), +post-conditions (constraints on its outputs) and function wide invariants (rules). + + +\paragraph{Mapping contract `pre-condition' violations to failure modes} + +A precondition, or requirement for a contract software function +defines the correct ranges of input conditions for the function +to operate successfully. + +For a software function, a violation of a pre-condition is +in effect a failure mode of `one of its components'. + + +\paragraph{Mapping contract `post-condition' violations to symptoms} + +A post condition is a definition of correct behaviour by a function. +A violated post condition is a symptom of failure of a function. +Post conditions could be either actions performed (i.e. the state of hardware changed) or an output value of a function. + +\paragraph{Mapping contract `invariant' violations to symptoms and failure modes} + +Invariants in contract programming may apply to inputs to the function (where they can be considered {\fms} in FMMD terminology), +and to outputs (where they can be considered {failure symptoms} in FMMD terminology). + + +\subsection{Combined Hardware/Software FMMD} + +For the purpose of example, we chose a simple common safety critical industrial circuit +that is nearly always used in conjunction with a programmatic element. +A common method for delivering a quantitative value in analogue electronics is +to supply a current signal to represent the value to be sent~\cite{aoe}[p.934]. +Usually, $4mA$ represents a zero or starting value and $20mA$ represents the full scale, +and this is referred to as {\ft} signalling. +% +{\ft} has a an electrical advantage as well, because the current in a loop is constant~\cite{aoe}[p.20] +resistance in the wires between the source and the receiving end is not an issue +that can alter the accuracy of the signal. +% +This circuit has many advantages for safety. If the signal becomes disconnected +it reads an out of range $0mA$ at the receiving end. This is outside the {\ft} range, +and is therefore easy to detect as an error rather than an incorrect value. +% +Should the driving electronics go wrong at the source end, it will usually +supply far too little or far too much current, making an error condition easy to detect. +% +At the receiving end, we only require one simple component to convert the +current signal into a voltage that we can read with an ADC: the humble resistor! + + +%BLOCK DIAGRAM HERE WITH FT CIRCUIT LOOP + +\begin{figure}[h] + \centering + \includegraphics[width=230pt]{./CH5_Examples/ftcontext.png} + % ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385 + \caption{Context Diagram for {\ft} loop} + \label{fig:ftcontext} +\end{figure} + + +The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft} +signal to a micro-controller system. +The signal is locally driven over a load resistor, and then read into the micro-controller via +an ADC and its multiplexer. +With the voltage detected at the ADC the multiplexer can read the intended quantitative +value from the external equipment. + +\subsection{Simple Software Example} + + +Consider a software function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$) +representing the current detected with an additional error indication flag . +% +Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read a voltage +from an ADC into the software. +Let us define any value outside the 4mA to 20mA range as an error condition. +% +As a voltage, we use ohms law~\cite{aoe} to determine the voltage ranges: $V=IR$, $0.004A * \ohms{220} = 0.88V$ +and $0.020A * \ohms{220} = 4.4V$. +% +Our acceptable voltage range is therefore + +$$(V \ge 0.88) \wedge (V \le 4.4) \; .$$ + +This voltage range forms our input requirement. +% +We can now examine a software function that performs a conversion from the voltage read to +a per~mil representation of the {\ft} input current. +% +For the purpose of example the `C' programming language~\cite{kandr} is used. +We initially assume a function \textbf{read\_ADC} which returns a floating point %double precision +value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}). + + +%%{\vbox{ +\begin{figure}[h+] + +\footnotesize +\begin{verbatim} +/***********************************************/ +/* read_4_20_input() */ +/***********************************************/ +/* Software function to read 4mA to 20mA input */ +/* returns a value from 0-999 proportional */ +/* to the current input. */ +/***********************************************/ +int read_4_20_input ( int * value ) { + double input_volts; + int error_flag; + + /* require: input from ADC to be + between 0.88 and 4.4 volts */ + + + input_volts = read_ADC(INPUT_4_20_mA); + + if ( input_volts < 0.88 || input_volts > 4.4 ) { + error_flag = 1; /* Error flag set to TRUE */ + } + else { + *value = (input_volts - 0.88) * ( 4.4 - 0.88 ) * 999.0; + error_flag = 0; /* indicate current input in range */ + } + + /* ensure: value is proportional (0-999) to the + 4 to 20mA input */ + + return error_flag; +} +\end{verbatim} +%} +%}\clearpage + +\caption{Software Function: \textbf{read\_4\_20\_input}} +\label{fig:code_read_4_20_input} +%\label{fig:420i} +\end{figure} +\clearpage +We now look at the function called by \textbf{read\_4\_20\_input}, \textbf{read\_ADC}, which returns a +voltage for a given ADC channel. +% +This function +deals directly with the hardware in the micro-controller that we are running the software on. +% +Its job is to select the correct channel (ADC multiplexer) and then to initiate a +conversion by setting an ADC 'go' bit (see code sample in figure~\ref{fig:code_read_ADC}). +% +It takes the raw ADC reading and converts it into a +floating point\footnote{the type, `double' or `double precision', is a standard C language floating point type~\cite{DBLP:books/ph/KernighanR88}.} +voltage value. + + + + + +%{\vbox{ +\begin{figure}[h+] + +\footnotesize +\begin{verbatim} +/***********************************************/ +/* read_ADC() */ +/***********************************************/ +/* Software function to read voltage from a */ +/* specified ADC MUX channel */ +/* Assume 10 ADC MUX channels 0..9 */ +/* ADC_CHAN_RANGE = 9 */ +/* Assume ADC is 12 bit and ADCRANGE = 4096 */ +/* returns voltage read as double precision */ +/***********************************************/ +double read_ADC( int channel ) { + int timeout = 0; + /* require: a) input channel from ADC to be + in valid ADC range + b) voltage ref is 0.1% of 5V */ + + /* return out of range result */ + /* if invalid channel selected */ + if ( channnel > ADC_CHAN_RANGE ) + return -2.0; + + /* set the multiplexer to the desired channel */ + ADCMUX = channel; + + ADCGO = 1; /* initiate ADC conversion hardware */ + + /* wait for ADC conversion with timeout */ + while ( ADCGO == 1 || timeout < 100 ) + timeout++; + + if ( timeout < 100 ) + dval = (double) ADCOUT * 5.0 / ADCRANGE; + else + dval = -1.0; /* indicate invalid reading */ + + /* return voltage as a floating point value */ + + /* ensure: value is voltage input to within 0.1% */ + + return dval; +} +\end{verbatim} +\caption{Software Function: \textbf{read\_ADC}} +\label{fig:code_read_ADC} +\end{figure} +%} +%} +\clearpage + +We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}. + +\begin{figure}[h] + \centering + \includegraphics[width=100pt]{./CH5_Examples/ct1.png} + % ct1.png: 151x224 pixel, 72dpi, 5.33x7.90 cm, bb=0 0 151 224 + \caption{Call tree for software example} + \label{fig:ct1} +\end{figure} + +This software is above the hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the +software is reading values from the `lower~level' electronics. +% +FMEA is always a bottom-up process and so we must begin with this hardware. +% +The hardware is simply a load resistor, connected across an ADC input +pin on the micro-controller and ground. +% +We can identify the resistor and the ADC module of the micro-controller as +the base components in this design. +% +We now apply FMMD starting with the hardware. + + +\subsection{FMMD Process} + +\paragraph{Functional Group - Convert mA to Voltage - CMATV} + +This functional group contains the load resistor +and the physical Analogue to Digital Converter (ADC). +Our functional group, $G_1$ is thus the set of base components: $G_1 = \{R, ADC\}$. +We now determine the {\fms} of all the components in $G_1$. +For the resistor we can use a failure mode set from the literature~\cite{en298}. +Where the function $fm$ returns a set of failure modes for a given component we can state: + +$$ fm(R) = \{OPEN,SHORT\}. $$ +\vbox{ +For the ADC we can determine the following failure modes: + +\begin{itemize} + \item STUCKAT --- The ADC outputs a constant value, + \item MUXFAIL --- The ADC cannot select its input channel correctly, + \item LOW --- The ADC output is always LOW, or zero ADC counts, + \item HIGH --- The ADC output is always HIGH, or max ADC counts. +\end{itemize} +} +We can use the function $fm$ to define the {\fms} of an ADC thus: +$$ fm(ADC) = \{ STUCKAT, MUXFAIL,LOW, HIGH \}. $$ + +With these failure modes, we can analyse our first functional group, see table~\ref{tbl:cmatv}. + +{ +\tiny +\begin{table}[h+] +\caption{$G_1$: Failure Mode Effects Analysis} % title of Table +\label{tbl:cmatv} + +\begin{tabular}{|| l | c | l ||} \hline + \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ + \textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline + \hline + 1: $R_{OPEN}$ & resistor open, & $HIGH$ \\ + & voltage on pin high & \\ \hline + + 2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\ + & voltage on pin low & \\ \hline \hline + + + + 3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\ + & fixed value & \\ \hline + + + + 4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\ + & wrong channel & \\ \hline + + 5: $ADC_{LOW}$ & output low & $LOW$ \\ + 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline + + +\hline + + +\hline + +\end{tabular} +\end{table} +} + + +We now collect the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $. +We now create a {\dc} to represent this called $CMATV$. + +We can express this using the `$\derivec$' function thus: +$$ CMATV = \; \derivec (G_1) .$$ + +As its failure modes, are the symptoms of failure from the functional group we can now state: +$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$$ + + +\paragraph{Functional Group - Software - Read\_ADC - RADC} + +The software function $Read\_ADC$ uses the ADC hardware analysed +as the {\dc} CMATV above. + + +The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as +{\em/* require: a) input channel from ADC to be + in valid ADC range + b) voltage ref is 0.1\% of 5V */}. +% +From the above contractual programming requirements, we see that +the function must be sent the correct channel number. +% +A violation of this can be considered a {\fm} of the function, +which we can call $ CHAN\_NO $. +% +The reference voltage for the ADC has a 0.1\% accuracy requirement. +% +If the reference value is outside of this, it is also a {\fm} +of this function, which we can call $V\_REF$. + +Taken as a component for use in FMEA/FMMD our function has +two failure modes. We can therefore treat it as a generic component, $Read\_ADC$, +by stating: + +$$ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $$ + +As we have a failure mode model for our function, we can now use it in conjunction with +with the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMSTV, Read\_ADC \}$. + +We now analyse this hardware/software combined {\fg}. + + + +{ +\tiny +\begin{table}[h+] +\caption{$G_2$: Failure Mode Effects Analysis} % title of Table +\label{tbl:radc} + +\begin{tabular}{|| l | c | l ||} \hline + \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ + \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline + \hline + 1: ${CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\ + & read & \\ \hline + + 2: ${VREF}$ & ADC volt-ref & $VV\_ERR$ \\ + & incorrect & \\ \hline \hline + + + + 3: $CMATV_{V\_ERR}$ & voltage value & $VV\_ERR$ \\ + & incorrect & \\ \hline + + + + 4: $CMATV_{HIGH}$ & ADC may read & $HIGH$ \\ + & wrong channel & \\ \hline + + 5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline + +\hline + + +\hline + +\end{tabular} +\end{table} +} + + + +We now collect the symptoms of failure for the {\fg} analysed (see table~\ref{tbl:radc}) +as $\{ VV\_ERR, HIGH, LOW \}$. We can add as well the violation of the postcondition +for the function. +This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */ }, +corresponds to $VV\_ERR$, and is already in the {\fm} set for this {\fg}. + +We can now create a {\dc} called $RADC$ thus: $$RADC = \; \derivec(G_2)$$ which has the following +{\fms}: + +$$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ + + + + + +\paragraph{Functional Group - Software - voltage to per mil - VTPM } + +This function sits on top of the $RADC$ {\dc} determined above. +We look at the pre-conditions for the function $read\_4\_20\_input$ , % which we can call $RI$ +to determine its {\fms}. +Its pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}. +We can map this violation of the pre-condition, to the {\fm} VRNGE; %As this function has one pre-condition +we can state, + +$$ fm(read\_4\_20\_input) = \{ VRNGE \} .$$ + +We can now form a functional group with the {\dc} $RADC$ and the +software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $. + + + +{ +\tiny +\begin{table}[h+] +\caption{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table +\label{tbl:r420i} + +\begin{tabular}{|| l | c | l ||} \hline + \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ + \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline + \hline + 1: $RI_{VRGE}$ & voltage & $OUT\_OF\_$ \\ + & outside range & $RANGE$ \\ \hline + + 2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\ + & incorrect & \\ \hline \hline + + + + 3: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\ + & incorrect & \\ \hline + + + + 4: $RADC_{LOW}$ & ADC may read & $OUT\_OF\_$ \\ + & wrong channel & $RANGE$ \\ \hline + +\hline + + +\hline + +\end{tabular} +\end{table} +} + +The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$. +The postcondition for the function $read\_4\_20\_input$, {\em /* ensure: value is proportional (0-999) to the + 4 to 20mA input */} corresponds to the $VAL\_ERR$ and is already in the set of failure modes. +% \paragraph{Final Functional Group} +For single failures these are the two ways in which this function +can fail. An $OUT\_OF\_RANGE$ will be flagged by the error flag variable. +The $VAL\_ERR$ will simply mean that the value read is simply wrong. + +We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ thus: + +$$ R420I = \; \derivec(G_3) .$$ + +This new {\dc} has the following {\fms}: +$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$$ + +% +% Using the derived components, CMATV and VTPM we create +% a new functional group. This +% integrates FMEA's from software and eletronics +% into the same failure mode model. + + + +We can now represent the software/hardware FMMD analysis +as a hierarchical diagram, see figure~\ref{fig:hd}. + +\begin{figure}[h] + \centering + \includegraphics[width=200pt]{./CH5_Examples/hd.png} + % hd.png: 363x520 pixel, 72dpi, 12.81x18.34 cm, bb=0 0 363 520 + \caption{FMMD hierarchy with hardware and software elements} + \label{fig:hd} +\end{figure} + + + +We can represent the hierarchy in figure~\ref{fig:hd} algebraically, using the `$\derivec$' function +using the groups as intermediate stages: +\begin{eqnarray*} +G_1 = \{R,ADC\} \\ +CMATV = \;\derivec (G_1) \\ +G_2 = \{CMATV, read\_ADC \} \\ +RADC = \; \derivec (G_2) \\ +G_3 = \{ RADC, read\_4\_20\_input \} \\ +R420I = \; \derivec (G_3) \\ +\end{eqnarray*} +or, a nested definition, +$$ \derivec \Big( \derivec \big( \derivec(R,ADC), read\_4\_20\_input \big), read\_4\_20\_input \Big). $$ + + + + + +This nested structure means that we have multiple traceable +stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage +of reasoning for each component failure mode. + +%\clearpage +\subsection{Conclusion: Software/Hardware FMMD Model} + +The {\dc} representing the {\ft} reader +in software shows that by FMMD, we can integrate +software and electro-mechanical FMMD models. +With this analysis +we have a complete `reasoning~path' linking the failures modes from the +electronics to those in the software. +Each functional group to {\dc} transition represents a +reasoning stage. +% + +With traditional FMEA methods the reasoning~distance is large, because +it stretches from the component failure mode to the top---or---system level failure. +For this reason applying traditional FMEA to software stretches +the reasoning distance even further. + +We now have a {\dc} for a {\ft} input in software. +Typically, more than one such input could be present in a real-world system. +Not only have we integrated electronics and software in an FMEA, we can also +re-use the analysis for each {\ft} input in the system. + +The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed +by another software function to read other known signals +via the MUX (i.e. voltage references). This strategy would +detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. +% +%Detailing this however, is beyond the scope %and page-count +%of this paper. + + + +%Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!! + + diff --git a/submission_thesis/CH8_finish_appendixes/copy.tex b/submission_thesis/CH8_finish_appendixes/copy.tex new file mode 100644 index 0000000..6ee5ba8 --- /dev/null +++ b/submission_thesis/CH8_finish_appendixes/copy.tex @@ -0,0 +1,11 @@ + + +%% +%% CH8 finishing up and appendixes +%% + +\printglossary + + +\addcontentsline{toc}{chapter}{Glossary} + diff --git a/submission_thesis/Makefile b/submission_thesis/Makefile index 901fa9a..362639d 100644 --- a/submission_thesis/Makefile +++ b/submission_thesis/Makefile @@ -1,9 +1,10 @@ -CHAPTERS = CH1_introduction CH2_FMEA CH3_FMEA_criticism CH4_FMMD CH5_Examples CH6_Evaluation CH7_Conculsion +CHAPTERS = CH1_introduction CH2_FMEA CH3_FMEA_criticism CH4_FMMD CH5_Examples CH6_Evaluation CH7_Conculsion CH8_finish_appendixes all: ${CHAPTERS} pdflatex thesis + makeindex thesis.glo -s thesis.ist -t thesis.glg -o thesis.gls acroread thesis.pdf clean: @@ -35,3 +36,6 @@ CH7_Conculsion: cd $@; make copy +CH8_finsh_appendixes: + cd $@; make copy + diff --git a/submission_thesis/mybib.bib b/submission_thesis/mybib.bib index b818d6c..430fa1b 100644 --- a/submission_thesis/mybib.bib +++ b/submission_thesis/mybib.bib @@ -208,6 +208,15 @@ } +@book{DBLP:books/ph/KernighanR88, + author = {Brian W. Kernighan and + Dennis Ritchie}, + title = {The C Programming Language, Second Edition}, + publisher = {Prentice-Hall}, + year = {1988}, + isbn = {0-13-110370-9}, + bibsource = {DBLP, http://dblp.uni-trier.de} +} @BOOK{allfour, diff --git a/submission_thesis/style.tex b/submission_thesis/style.tex index a93d89f..c10b28a 100644 --- a/submission_thesis/style.tex +++ b/submission_thesis/style.tex @@ -15,6 +15,7 @@ \setlength{\textwidth}{160mm} \setlength{\textheight}{220mm} \setlength{\oddsidemargin}{0mm} \setlength{\evensidemargin}{0mm} % +\newcommand{\permil}{\ensuremath{0/{\!}_{00}}} \newcommand{\derivec}{{D}} \newcommand{\abslev}{\ensuremath{\alpha}} \newcommand{\oc}{\ensuremath{^{o}{C}}} diff --git a/submission_thesis/thesis.tex b/submission_thesis/thesis.tex index 23c4ca0..9d5b474 100644 --- a/submission_thesis/thesis.tex +++ b/submission_thesis/thesis.tex @@ -92,7 +92,13 @@ \chapter{Conclusion} \input{CH7_Conculsion/copy} -\appendix +\nocite{alggraph} +\nocite{ince} + +%%% ONLY NEEDED IF WE HAVE APPENDIXES +%\chapter{Conclusion} +%\input{CH8_finish_appendixes/copy} + %\chapter{FMMD tool : Design Issues} %