Faultdec

EARLY FAULT DETECTION AND ALERT SYSTEM
Project Report
Rangeen Basu Roy Chowdury Aniket Nathvani
Project Guide: Dr. J. Roychowdhury
Submitted at CMERI Durgapur

Abstract
We propose to make a probabilistic model of a working system during its lifetime
of operation and use this model to design a State Observer that will work in tandem with
a micro-controller based system to pre-detect a possible fault in a system by observing
and analyzing the internal sub-states and issue necessary alarm to the micro-controller
with time to spare. The system that we are monitoring is a cricket ball stitching machine.
The state observer will monitor the health of the stitching needle and alert the user when
it approaches a breaking limit and needs to be replaced. The basic idea is to be able to
identify a needle breakage before it actually happens. The module will also have a user
friendly display panel that will let the user know about the state of the system which it is
monitoring. Though the design has been made with the objective to be used with the ball
stitching machine, it is general enough to be used in any other fault aware system such
as a braking system.
In this report we describe faultdec – the early fault detection system and how it
helps in addressing the problem we have identified. We explain the methodology that
this system has adopted to tackle the issue. We also demonstrate some possible
applications of faultdec. In the end, we conclude with possible enhancements in the
project that might take us to a whole new world of fault tolerant systems.

Acknowledgment
The authors gratefully acknowledge the guidance provided by the project supervisor Dr.
J. Roychowdhury throughout the development of the project.
The authors also wish to thank the faculty members of NIT Durgapur for their
valuable suggestions and directions.
The authors also thank their batch mates for providing constant encouragement,
support and valuable suggestions during the development of the project.

Candidate’s Declaration
We hereby declare that this project report titled ‘Faultdec-Early Fault Detection
System’ submitted at Central Mechanical Engineering Research Institute – Durgapur is
an authentic record of our work carried out under the guidance of Dr. J. Roy
Chowdhury, Scientist, Embedded Systems Lab, CMERI Durgapur.
Date: March 20, 2009
Place: Durgapur
Rangeen Basu Roy Chowdhury Aniket Nathvani
Certificate
This is to certify that the above declaration made by Mr. Rangeen Basu Roy
Chowdhury and Mr. Aniket Nathvani is true to the best of my knowledge and belief.
Date: March 20, 2009
Place: Durgapur
Dr. J Roychowdhury
Scientist
Embedded Systems Laboratory
CMERI Durgapur

Contents
1. Introduction
1.1 The Problem
1.2 Importance Of The Problem
1.3 Possible Solution
2. System Model
2.1 State Diagram
2.2 Characteristics Of Needle
3. Principle Behind faultdec
3.1 Internal State Detection and Timed Automata
3.2 Discretization Of Time
3.3 State Density Mapping
4. Faultdec Architecture
4.1 Block Diagram
4.2 Detection Block
4.3 Decision Block
4.4 Displayer Block
5. How faultdec works
5.1 Degraded State Detection And Signalling
5.2 Deciding Mechanism
5.3 Display
6. Specific Technologies Used
6.1 CPLD As The Implementation
6.2 VHDL Language
6.3 Quartus II

7. Evaluation And Testing
7.1 Experiment 1: Continuous Degraded Pulses
7.2 Experiment 2: Alternate Normal And Degraded Operation
7.3 Experiment 3: Piecewise Linear Simulation Of System
Characteristic
7.4 Experiment 4: Piecewise Linear Simulation Of System
Characteristic With Temporary Degradation
7.5 Experiment 5: Temporary Burst Of Degradation
7.6 Timing Simulation
8. Possible Areas Of Application
8.1 Needle Breakage
8.2 Braking System Failure
8.3 Medical Condition Monitoring
9. Conclusion and Future Scope
A. VHDL Code For Some Important Blocks
A.1 counter_ctrl.vhd
A.2 counter.vhd
A.3 decision.vhd
A.4 count_stat_mux.vhd
References

List Of Figures
Fig 2.1 States and Substates in a system
Fig 2.2 Needle Operation Curve
Fig 2.3 Probability of fault
Fig 2.5 Discrete probability-state density distribution
Fig 3.1.a. Timed Buchi Automata
Fig 3.1.b. Timed Safety Automata
Fig 3.2 Flow Chart for State Density Mapping
Fig 4.1 Top Level Block Diagram of Faultdec
Fig 4.2 Block Diagram of Detection Block
Fig 4.3 Detection Control EFSM
Fig 4.4 State Density Counter EFSM
Fig 4.5 Alarm FSM
Fig 4.6 Block Diagram of displayer
Fig 7.1 Experiment 1 Input Graph
Fig 7.2 Experiment 1 Output Graph

Fig 7.11 Simulation Waveform

List Of Tables
Table 7.1 Experiment-1 Observations

Chapter 1
Introduction
A system is said to be real-time if the total correctness of an operation depends
not only upon its logical correctness, but also upon the time in which it is performed.
In control and automata theory, a state is a unique configuration of information in
a system. Knowing the state of a system is necessary for efficiently controlling the
system; for example, stabilizing a system using state feedback. The current state of a
system determines the future plan of action. So it becomes extremely important to devise
some method by which the state of a system can be monitored. A state which cannot be
observed directly is called an Internal State.
A State Observer is a system that models a real system in order to provide an
estimate of its internal state, given measurements of the input and output of the real
system.
1.1 What The Problem Is
The usefulness of a State Observer can be understood from the fact that 'It can be
a matter of life and death'. If a controller does not know the physical state of a system, it
will not be able to avoid faults and failures. This process of determining the internal
physical state is made difficult by the following factors:

 Traditional state-based systems focus on external state information, such as the
number and type of percepts, etc. when using the current state to influence
decisions. External state-based systems scan the environment and then react or
deliberate using the information gathered.
 In most practical cases, the physical state of the system cannot be determined by
direct observation. Instead, indirect effects of the internal state are observed by
observing the system outputs. A simple example is that of vehicles in a tunnel: the
rates and velocities at which vehicles enter and leave the tunnel can be observed
directly, but the exact state inside the tunnel can only be estimated.
 Typical micro-controller based internal state observers are extremely slow in
determining the state and hence they cannot be used in real time systems where
pre-detecting and avoiding fault becomes insurmountable. Moreover only a very
limited number of inputs can be monitored that also not parallel.
 The case in hand is essentially non-deterministic since the internal state transitions
are non-deterministic in nature and can only be qualified using indirect methods.
So the problem is 'To design an extremely fast state observer which can pre detect
possibility of faults by observing non-deterministic internal states and work in tandem
with a micro-controller based controlling system to make the overall system fault
aware'.
1.2 Importance Of The Problem
Knowing the internal state of a system will allow the controlling mechanism to
adapt according to the physical condition of the system which it is controlling. The state
observer will act as an additional supervisor to the micro-controller based system and
will observe and analyze the non-deterministic sub states and allow the controller to take
decisions based on this analysis . It can then be used in critical applications where it
becomes extremely necessary to predict a fault rather than detect a fault. Doing so will
lower the risk of failure since required measures can be taken well in advance.

Chapter 2
System Model
The system, whose state we are to observe is a degradable system i.e. its operation
deteriorates with time. Any system during its time of operation becomes fatigued and
finally fails as a result of accumulation of this fatigue. In this transition from normal
operation to failed state, the system passes through another state known as the 'Degraded
State'. The system starts oscillating between normal and degraded state. Initially the
oscillation is less and it spends more time in the normal state. But as time passes, the
system remains in the degraded state for a longer amount of time than in the normal
state. This occurs as a result of fatigue accumulation and indicates possibility of a fault
in the near future. Once the breaking limit is reached, the system snaps and enters failed
state.
2.1 State Diagram
The micro-controller based system can observe only two basic states of a system,
namely working state and failed state. It is unable to determine what happens during
the transition between these two states. The working state has sub-states which are
equivalent to each other. The sub-states can be broadly classified into two categories-
normal and degraded.

Fig 2.1 States and Substates in a system
The two sub-states, namely normal state and degraded state are 'Equivalent
States'.So it is extremely difficult to distinguish between them by just looking at the
input and output words. On the other hand, the failed state has totally different output
words from the degraded and normal states. So it can be distinguished easily, though
detecting it would not be of any great use since the system has already failed.
The job of faultdec is to be able to distinguish between the normal sub-state and
the degraded sub-state clearly, to approximately measure the density of the states,
determine the probability of fault and alert in time.
2.2 Characteristics of needle
In any system characteristic, the initial degraded oscillation is due to lack of
calibration. Then the system starts behaving normally. During the normal phase of
operation, the system may jump to degraded state at times due to some disturbance but
comes back to normal state quickly. As fatigue starts accumulating in the later part of
the characteristic, oscillations can be seen and if no corrective measure is adapted then
the system fails and loses controllability which has been depicted in the characteristic as
a sharp rise and a subsequent discontinuity.

Fig 2.2 Needle Operation Curve

Since it becomes very difficult to handle continuous probability distribution in
digital decision logic, the continuous probability distribution needs to be made discrete
and comparison logic has to be used to determine the possibility of a fault.
Fig 2.5 Discrete probability-state density distribution

This figure can be generated from the two figures, namely Fig 2.4 and Fig 2.5. Fig
2.4 can be obtained from the collective data of a large number of experiments or might
be provided by the manufacturer. Fig 2.5 on the other hand can be obtained from
experimental data using the cumulative weighted counting algorithm. The two figures
are then combined to obtain the discrete probability vs sate density number pot. This
plot is the basis for generating the alarm. The boundary state density numbers are used
as critical points.
The entire extent of state density has been broken into four regions as it was found
optimum from experimentation. The first region is normal range, the second is the first
degraded region or “d1”, third is the second degraded region or “d2” and the last region
is the final degraded region or “d3” whereafter the system fails.The probability for each
range is the average for that range from the continuous probability distribution. It can be
seen that the width of the intervals of state density value decreases as we its value
increases. This reflects the fact that the probability of failure increases rapidly with
increase in time and so does the density of state but the rate of increase of probability is
faster than state density. The state density value is a value determined according to an
algorithm that nearly reflects the behaviour of the system. Weighted counting system
has been used to get a discrete value for state density so that it becomes easy for the
digital decision logic to determine the current condition of the system and probability of
fault.

Chapter 3
Principle Behind Faultdec
3.1 Possible Solution Of The Problem
 If a system is observable, it is possible to fully reconstruct the system state from
its output measurements using the state observer. A possible way to monitor the
internal state is by using Timed Automata Theory to design the state observer.
 Instead of using soft techniques for observing, hardware techniques should be
employed. Using devices like FPGA or CPLD will do the job since they are
extremely fast and the designs implemented in them are concurrent unlike soft
designs and thus save a large number of clock cycles.
 By the components of the design are concurrent so the complete module can be
replicated as many times required and the whole design can be burned so that a
large number of inputs can be monitored simultaneously and concurrently.
The result is Faultdec, an early fault detection system.
3.2 Internal State Detection and Timed Automata
Since faultdec is an internal state based engine, so normal automata cannot be the

modeling technique for it. Instead, a slightly changed version of automata - the timed
automata technique has been used. Timed automata is a theory for modeling and
verification of real time systems. A timed automaton is essentially a finite automaton
(that is a graph containing a finite set of nodes or locations and a finite set of labeled
edges) extended with real-valued variables. Such an automaton may be considered as an
abstract model of a timed system. The variables model the logical clocks in the system,
which are initialized with zero when the system is started, and then increase
synchronously with the same rate. Clock constraints i.e. guards on edges are used to
restrict the behavior of the automaton. A transition represented by an edge can be taken
when the clocks values satisfy the guard labeled on the edge. Clocks may be reset to
zero when a transition is taken.
Timed Büchi Automata: A guard on an edge of an automaton is only an enabling
condition of the transition represented by the edge; but it cannot force the transition to
be taken. For instance, the example automaton may stay forever in any location, just
idling. In the initial work by Alur and Dill [AD90], the problem is solved by introducing
Büchi-acceptance conditions; a subset of the locations in the automaton are marked as
accepting, and only those executions passing through an accepting location infinitely
often are considered valid behaviors of the automaton. As an example, consider again
the automaton in Figure 3.1(a) and assume that end is marked as accepting. This implies
that all executions of the automaton must visit end infinitely many times. This imposes
implicit conditions on start and loop. The location start must be left when the value of y
is at most 20, otherwise the automaton will get stuck in start and never be able to enter
end. Likewise, the automaton must leave loop when y is at most 50 to be able to enter
end.
Fig 3.1.a. Timed Buchi Automata Fig 3.1.b. Timed Safety Automata

Timed Safety Automata: A more intuitive notion of progress is introduced in
timed safety automata [HNSY94]. Instead of accepting conditions, in timed safety
automata, locations may be put local timing constraints called location invariants. An
automaton may remain in a location as long as the clocks values satisfy the invariant
condition of the location. For example, consider the timed safety automaton in Figure
3.1(b), which corresponds to the Büchi automaton in Figure 3.1(a) with end marked as
an accepting location. The invariant specifies a local condition that start and end must be
left when y is at most 20 and loop must be left when y is at most 50. This gives a local
view of the timing behavior of the automaton in each location.
The most appropriate modeling technique for faultdec would be Timed Safety
Automata. It can be used to determine whether the time taken by the needle to stitch is
normal or higher than normal and will be the main driving logic behind faultdec.
3.3 Use Of High Frequency Clock
Since the faultdec will be a digital system, it cannot measure continuous quantities
like time directly. This has to be done by discretization i.e. Breaking time into smaller
discrete intervals and then counting the number of intervals. The count value is
proportional to time passed. A clock having time period much smaller than the stitching
duration ie. Of higher frequency, has been used to achieve this task.
There might be cases where it becomes important to eliminate the unavoidable
glitches or discontinuities in the sensor signal that occur due to some noise. To avoid the
false detection of a discontinuity as an edge, the sensor signal might be debounced with
a low frequency clock. Though this will lead to a certain amount of latency but will
increase the reliability of the system to a great extent. This delay is solely determined
by the delay used for debouncing and is not effected by the clock used for discretization
of time and neither does affect the resolution of the system.
3.4 State Density Mapping
The actual state density is mapped to a State Density Value using an algorithm

which uses Weighted counting to generate the density value. The algorithm is quite
simple though effective and takes care of almost all possibilities. It also avoids false
detection to a large extent. Depending upon the calculated state density value and using
the discrete probability distribution, the alert is generated to notify the micro-controller
and the user about the condition of the needle.
3.5 Algorithm for State Density Mapping
Start from a state density value of 4 and normal counter
value of 0
If detected state is normal then
decrement state density value by 1 up to a
minimum of 0
else if detected state is degraded then
if previous state was normal then increment
state density value by 2
else if previous state was degraded then
increment state density value by 3
end if
end if
As can be noted, the counting weightage for a degraded state changes depending
upon whether the previous state was normal or degrade. This process of changing
weightage is a primitive learning mechanism. The decision block actually changes the
way it decides depending upon past conditions and not only based upon the current state.
This phenomenon, called cumulative weighted counting, induces a small degree of
intelligence in it.

Fig 3.2 Flow Chart for State Density Mapping

Chapter 4
Faultdec Architecture
The faultdec consists of three major blocks namely the detection block, the
decision block and the displayer block. The detection block is the place where timed
safety automata has been employed to distinguish between normal state operation and
degraded state operation by measuring the time required to complete the operation. The
decision block generates the alert signals based upon the output of the detection block
which tells whether the state is normal or degraded. The displayer block does the task of
displaying the internal condition of the system as determined by the decision block.
Fig 4.1 Top Level Block Diagram of Faultdec

4.1 Detection Block
This block is responsible for detecting a degraded state of operation and indicate it
in the output. It does this by counting using a high frequency clock during the period
when the input is active and then comparing the count value with a preset value found
by experimentation. It counts only till the value reaches preset value and then stops,
declaring the current state as a degraded one. So it has been modeled using timed safety
automata. Extended fsm approach has been adopted to realize the timed safety automata
in the detection block.
Fig 4.2 Block Diagram of Detection Block
Fig 4.3 Detection Control EFSM

4.2 Decision Block
This block has two very important functions:
 Determining the state density by generating the state density value
 Generating the alert signals based upon the state density value and discrete
probability distribution.
The block does the first job by using the weighted counting algorithm as described
earlier. The second job is done by comparing the generated state density value with the
intervals in the discrete probability distribution and taking decision. The state density
counter has been implemented using an EFSM and the alarm generator has been
implemented using a FSM. This block consists of one EFSM which has the output from
detection block as its input and a FSM which has two bit alarm signal as output.
Fig 4.4 Decision EFSM

Fig 4.5 Alarm FSM
4.3 Displayer Block
Depending upon the alert signal generated by the decision block, this displays the
following things:
 The 4th
led displays the position of the ball while being stitched and is solely for
the convenience of the user
 The 1st
to 3rd
led display the following:
 Number of stitches completed when the operation is in normal state
 “d0'” when the system is in first degraded state
 “d1” when the system is in second degraded state
 “d2” when the system is in final degraded state

Fig 4.6 Block Diagram of displayer
The displayer block is for user interaction and displays useful facts to the user so
that he can take decision based on them and is able to prevent faults. This actually helps
faultdec to assist the user in taking decisions such as whether to change the needle or
whether to load a new ball for stitching.

Chapter 5
How Faultdec Works
In the previous section the internal architecture and the design of faultdec was
discussed. In this section the signalling and the operation of every module of faultdec
and faultdec as a whole has been described.
5.1 Degraded State Detection And Signalling
The signal from the sensor is such that it remains active high during a stitch i.e. it
has a value of logical '1' from the instant when the needle goes into the leather to the
instant when it comes out. So the time taken by the needle for for one stitch can be
determined by measuring the duration for which the signal remains high. This is done
indirectly by counting using a very high frequency clock and using the signal enable for
the counter. The counter is stopped either when the negative edge of the sensor signal
appears or when the count value crosses the preset level. If the counter is stopped due to
expiration, then the state is considered as a degraded state. And a pulse of one clock
duration is issued to signal the detection of a degraded state of operation.
5.2 Deciding Mechanism
The decision i.e. whether to stop the machine or whether to continue or how many
more stitches the needle can make, has to be taken depending upon the output of the

detection block. The detection block, as mentioned earlier, sends a pulse of one clock
duration every time it detects a degraded state. The detection block uses this pulse to
perform weighted counting. Then based on the state density count the actual decision is
taken. The FSM has this state density count as input. It works in the following manner:
 When a new needle is set for use i.e. when the system is reset and as the system
starts i.e. reset is removed, the system goes to state A which is the noraml
working state.
 If the system becomes degraded then the state density count starts increasing and
as this value crosses 12 , the system goes to state B which is the first degraded
state. At this point, the needle can be considered to be able to make 50 more
stitches. It may so happen that the needle is not actually degraded and the
degraded operation was actually due to some temporary problems. This may lead
to a false transition. The design safeguards against such conditions by taking
current state back to state A if the subsequent operation is normal for a certain
duration. So if the count value falls below 8, the system goes back to stae A i.e .
normal operation.
 Similar transitions occur from state B to state C and similar protection against
false detection has been used. The system moves to state C, which is a further
degraded state, when the state density count crosses 19. The current state may fall
back to state B if the value becomes less than 14. At this point, the needle can
make approximately 25 more stitches and needs to be changed shortly.
 As the state density count crosses 26 it enters the state D which is the critical
region and the probabiity of breakage becomes extremely high. The needle has to
be replaced and faultdec interrupts the system operation by halting it. The system
again returns to reset as the needle is replaced with a new needle.
 The decision block represents the four states as by a two bit vector, which it
sends to the micro controller for proper control mechanism. Depending upon this
bit vector, the controller decides whether to continue stitching the ball or whether
to load a new ball or not.
 The status bit vector also allows stitch quality determination and proper valuation
of the finished balls.
5.3 Display
The display module plays an important role in user interaction and proper
operation of the system. This smooth running of the machine depends upon the ability of
the user or operator to interpret the physical condition of the system and take necessary
action to overcome the problem. Faultdec makes this job really easy for the user as it

displays the system state on a 4 digit 7 segment LED display. The function of the
different parts of the displayer are as follows:
 The BCD counter counts the number of stitches completed on a ball. It is reset
every time a new ball is loaded.
 The shifter is responsible for displaying the position of the ball being stitched on
a 7 segment display by rotating one segment.
 The count_status multiplexer is the component where multiplexing occurs
between the stitch count and the degraded status depending upon the value of the
status string.
 The digit multiplexer is the state machine that controls the digit-data
synchronization and time division multiplexing.

Chapter 6
Specific Technologies Used
6.1 CPLD As The Implementation Platform
Since faultdec has to be extremely fast, so a hardware such as CPLD has been
used for implementation. The major advantages of using a CPLD for implementation are
varied.
 A CPLD can work at a clock frequency of 200 MHz and the implemented
designs can be concurrent thus leading to much faster data acquisition and
processing as compared to a micro-controller which generally work at frequencies
around 15 to 25 MHz and also are not concurrent.
 A CPLD also has large number of I/O ports and is easy to interface with other
digital devices.
 The high clock frequency allows faultdec to achieve a very high resolution in
discretization of time and hence provide extremely accurate detection.
 The low propagation delay allows for the decision to be taken within a few nano
seconds thereby making the controll mechanism highly real time.
The CPLD used for implementation is an Altera MAX II CPLD with component number
98239217c100. The development board is SLS ELT-II toolkit which has the used

CPLD and other peripherals on it. It supports JTAG and serial programming.
6.2 VHDL Language
Since the implementation platform is CPLD so a HDL had to be used for making
the design. VHDL was chosen as the HDL for implementation of faultdec. Its major
advantages in designs such as these are as follows:
 VHDL is a fairly general-purpose language, and many compilers, which can
generate netlists from a VHDL code, are available.
 Because of its general-purpose nature, VHDL can be used for testing another
VHDL code or design by writing testbench that automatically verifies the
functionality of the design.
 VHDL allows different types of modelling such as Behavioral Modelling,
Structural Modelling, RTL Modelling etc.
 VHDL can be used to create modular designs and hence increases re usability. It
eases design and testing by breaking te design down into independently verifiable
components.
 A very very important advantage is that VHDL allows the description of a
concurrent system (many parts, each with its own sub-behavior, working together
at the same time). VHDL is a Dataflow Language, unlike procedural computing
languages such as BASIC, C, and assembly code, which all run sequentially, one
instruction at a time.
VHDL standard IEEE 1164 has been used since the design is completely digital.
6.3 Quartus-II
Since the CPLD used was Altera MAX-II 2082c100, so Quartus-II had to be used
for programming the devices. It has been used as the IDE for writing, compiling,
simulating and programming the design using VHDL. The JTAG mode was used for
programming the device. Quartus-II has excellent support for the VHDL libraries and so
has been the preferred development environment for the project.

Chapter 7
Evaluation And Testing
Every design needs to to be tested and evaluated in order to sort out potential
problems and bugs and to ensure the proper operation of the design. So faultdec needs to
be tested as well. This is achieved by using a microcontroller to simulate the system and
inject fault into the system. The microcontroller is programmed to generate four types of
pulses, each with different active period. These four types of signals namely N, D1, D2,
D3 are used to generate different test cases. For complex cases, a piecewise linear
approach was used to simulate the system characteristics. The type of pulse being
generated at a given time can be controlled using three switches. It is basically nothing
but a priority encoder. D1 is generated when only switch SW1 was on, D2 when SW2 is
on, D3 when SW3 is on and N, being the default type, is generated when all three
switches are off.
These are approximate representations of the real system characteristics, the only
difference being the duration of the curves. In actual implementations, the curves will be
stretched for a much longer duration of time. Otherwise, the shape of the curve as a
whole remains the same.
7.1 Experiment 1: Continuous Degraded Operation
In this experiment, degraded pulses are sent continuously simulating a continuous
degraded operation. The intention is to check whether faultdec is able to comprehend a
degraded pulse and take proper decision thereby checking the forward movement os the
state density counter.

Status Cumulative Number Of pulses
Sent
State Density Number
(Manually Calculated)
Normal 5 14
d0 7 20
d1 10 29
d2 - -

From the table and the output graph, it can be seen that faultdec operates as
expected. The state density count increases steadily, first with a weightage of 2 and then
with a weightage of 3. The alarm is raised only when the critical point is reached. Then
the system is halted by an interrupt.
7.2 Experiment 2: Alternate Normal And Degraded
Operation
In this experiment degraded and normal pulses are sent alternately thus
simulating situations where the system may be oscillating between degraded and normal
operation. In this, both the forward and backward motion of the state density counter is
tested. The algorithm has been designed to avoid such kind of oscillatory deadlock
situation by giving higher weight-age to degraded operation than normal operation.

Fig 7.3 Experiment-2 Input Graph
Status Transition Cumulative Number Of Pulses
Sent
State Density Number
(Manually Calculated)
Normal 21 12
d0 37 20
d1 51 27
d2 - -

Fig 7.4 Experiment-2 Output Graph
The first pulse was a degraded pulse. So the state density count jumps to 2 and
alternates thereafter with a change of -1 and 2. The status changes occur at the intended
points. The system is halted when the state density count reaches the critical region.
7.3 Experiment 3: Piecewise Linear Simulation Of
System Characteristic
To simulate a real world operation of the system, a piecewise linear approach has
been adopted. Four pulses of different width has been used to generate the system
characteristic. The four types, labeled as N, D-1, D-2 and D-3, are sent in predetermined
numbers to generate the characteristic. Since only two levels of qualification is possible
according to the design of the decision block, so, faultdec considers N and D-1 pulses as
tolerable and the others as non tolerable. Simply put, N and D-1 pulses represent normal
operation of the system whereas D-2 and D-3 pulses represent degraded operation .

The black line shows the pulse widths vs time plot whereas the red line gives the
approximate piecewise realization of the system characteristic. The oscillation on the
right half of the graph depicts the actual oscillation that occurs between states
Status Number Of Pulses
Sent
Type Of Pulse
Sent
Cumulative
Number Of Pulses
Sent
State Density
Number
(Manually
Calculated)
Normal 2 D-3 2 5
Normal 15 N 17 0
Normal 2 D-1 19 0
Normal 3 N 22 0
Normal 3 D-1 25 0
Normal 2 D-2 27 5
Normal 2 D-1 29 3
Normal 2 D-2 31 8
Normal 2 D-3 33 14
d0 2 D-3 35 20
d1 3 D-3 38 29
d2 - - - -

From the observation and the output graph, it can be seen that the state density
counter moves in a way as predicted by the model. The rise of the count, after the
system reached a condition of degraded operation, is sharp. This depicts the adaptability
of the decision algorithm. The alarm is raised at proper points as is evident from the
table and the system is halted once the state density count reaches the critical region.
7.4 Experiment 4: Piecewise Linear Simulation Of
System Characteristic With Temporary Degradation
This experiment has been designed to test the robustness of the design and
tolerance of the algorithm to temporary glitches and degradation due to some problem
such as inertia etc. This tests whether faultdec issues a false alarm in this kind of
situation. Similar piecewise linear approach has been adopted as the previous
experiment. Here also four types of pulses have been used.

Sent
Type Of Pulse
Sent
Cumulative
Number Of Pulse
Sent
State Density
Number
(Manually
Calculated)
Normal 2 D-3 2 5
Normal 8 N 10 0
Normal 2 D-3 12 5
Normal 5 N 17 0
Normal 1 D-3 18 2
Normal 10 N 28 0
Normal 3 D-3 31 8
Normal 2 D-1 33 6
Normal 2 D-2 35 11
Normal 1 D-3 36 14
d0 2 D-3 38 20
d1 3 D-3 41 29
d2 - - - -

From the output curve it can be seen that that inspite of the spikes or glitches, a
false alarm is not raised by faultdec. This indicates the tolerance of the model to wobbly
conditions. If the decision were based only on the current state then a false alarm would
have been raised. But due to cumulative weighted counting, the status changes occur at
right points and the system is halted only when the state density count reaches the
critical region.
7.5 Experiment 5: Temporary Burst Of Degradation
This experiment aims to simulate a situation in which there might be a continuous
burst of degraded operation due to some reason such that faultdec alarm moves to d1
through normal and d0. It might be the case that after such a burst, the system starts
operating normally again. In this case a false alarm or a false halt must be avoided and
faultdec must move back to normal status. This functionality has been built into the
algorithm. In this experiment we test this functionality by sending a burst of degraded
(D 3) pulses until the status changes to d1 and then send normal (N) pulses to check the
backtrace of faultdec.

Sent
Type Of Pulse
Sent
Cumulative
Number OF Pulse
Sent
State Density
Number
(Manually
Calculated)
Normal 2 D-3 2 5
Normal 8 N 10 0
Normal 5 D-3 15 14
d0 2 D-3 17 20
d1 6 N 23 14
d0 6 N 29 8
Normal - - - -

This experiment was for testing the proper backtrace and status change. From the
output curve it can be seen that the fall in state density count less steep than rise in it. So
it can be inferred that once the status goes to d0 or d1, it will come back to normal only
if the system exhibits a long duration of normal operation.
7.6 Timing Simulation
This is the most important evaluation on which the reliability and feasibility of
faultdec depends. The operation of faultdec is simulated in the Quartus II waveform
simulator to observe the timing of faultdec i.e. how fast or slow faultdec works. The
main timing constraints are
 Detection time of a degraded pulse
 Decision time
 Status change time / Alarm time

clk1
rst
sensor
tolerable
state_density
status
ssd
ssdsel
ssdp
count
Fig 7.11 Simulation Waveform
Since the whole design is sequential, so the various timing constraints are
dependent upon the clock speed. Here we have taken clock speed as 50 MHz. From the
simulation result the main timing constraints are seen to be as follows
 Detection time of a degraded pulse - 1 clock pulse (20 ns in this case)
 Decision time - 1 clock pulse(20 ns in this case)
 Status change time / Alarm time - 3 clock pulse maximum and 1 clock pulse
minimum(60 ns max/20 ns min)

Chapter 8
Possible Areas Of Application
8.1 Needle breakage
In machines where a needle is used for stitching operation, breakage is very
common with the needle. If a needle breaks in the midst of a stitch, it destroys the object
that it is stitching as is the case in a ball stitching machine. As the needle gets blunt, it
takes more time than normal to complete a stitch. So Faultdec finds its application in
preventing the needle from breaking during a stitch by alerting the user to change the
needle and eventually halting the machine if the condition of the needle becomes too
bad.
8.2 Braking System Failure
The braking system in any vehicle is liable to failure due to wear and tear of the
brake shoe and other components and and hence it takes more time than usual to bring
the car to a halt thus causing a threat to human life and damage of property. Faultdec
comes in handy at preventing such accidents due brake failure provided the user repairs
the brakes in time. The model used for faultdec can also be used, with minor
modifications, for this purpose.
8.3 Medical Condition Monitoring System
This is a very critical issue where it is imperative to detect failure before it

actually occurs. For example a heart failure has to be detected from the ECG signals or
by pulse rate monitoring before it occurs. Faultdec can save save a lot of lives in thes
sector by real time processing of signals from various sensors and signal a deteriorating
condition. Additional blocks for signal conditioning might have to be used in addition to
faultdec for accurate emergency detection system.

Chapter 9
Conclusion And Future Scope
In this report we described faultdec as a project that helps us to detects faults and
failures in systems before occurring and thus avoid wastage of time, material, money
and, in some cases, life. A careful implementation of the idea suggested can prove to be
very beneficial in promoting the design of fault aware systems and thus extend
automation in systems. Module based design of faultdec comes to great use when adding
functionality is the issue. The project can be considered as a proof of concepts- the
theoretical concept of timed automata and the concept that faults in systems can be more
easily prevented through proper automation. It is a step in the direction of using
automation for safety, security and sustainability.
What this project lacks is the ability to adapt to system condition and continue an
uninterrupted operation. Preset, tolerance levels and the weightages for state density
counter have to be essentially set by the user and hardcoded. To incorporate the desired
adaptability, conversation between the microcontroller and the state observer is
necessary. The controller should be able to make changes in the reference values based
on the system condition and the environment. A communication module will do the job
effectively.
To take the design one step further, adaptability can be introduced in the faultdec
itself so that it can take decisions and thereby adjust the presets itself. It will effectively
act as a fuzzy inference engine that can perform this task. An adaptability logic
implemented by neural network and fuzzy logic needs to be designed which can change
the various parameters as and when required depending upon the system condition and
the environment. The communication module can then be dropped and slight
restructuring can be done in the design to introduce this functionality.

Appendix A
VHDL Code For Important Blocks
Faultdec has been implemented with VHDL and is modular in nature. It has 13
component blocks in it. Here only the codes for the important functional blocks are
being provided for quick reference.
A.1 counter_ctrl.vhd
LIBRARY ieee;
USE ieee.std_logic_1164.all;
USE ieee.std_logic_unsigned.all;
USE work.components.all;
ENTITY counter_ctrl IS
PORT ( sensor_in, clk, rst,load: IN STD_LOGIC;
count_value,reference:IN STD_LOGIC_VECTOR(31 DOWNTO 0);
control: OUT STD_LOGIC_VECTOR(1 DOWNTO 0);
degraded:OUT STD_LOGIC;
enable:BUFFER STD_LOGIC);
END counter_ctrl;
ARCHITECTURE behaviour OF counter_ctrl IS
TYPE state IS( reset, stndby, count);
SIGNAL pr_state, nx_state: state;
SIGNAL tolerable,enable_tmp,stop:STD_LOGIC;

BEGIN
PROCESS(rst,clk)
BEGIN
IF(rst='1') THEN
pr_state<=reset;
ELSIF(clk'EVENT AND clk='1') THEN
pr_state<=nx_state;
END IF;
END PROCESS;
PROCESS(enable, pr_state)
BEGIN
CASE pr_state IS
WHEN reset=>
control<="01"; --Order is enable/reset
nx_state<=stndby;
WHEN stndby=>
control<="01";
IF(enable='1') THEN
nx_state<=count;
ELSE
nx_state<=stndby;
END IF;
WHEN count=>
control<="10";
IF(enable='1') THEN
nx_state<=count;
ELSE
nx_state<=stndby;
END IF;
END CASE;
END PROCESS;
--Tolerance Block---
-- tolerable<= '1'WHEN (reference>count_value) ELSE
-- '0';
PROCESS( reference, count_value,clk)
BEGIN
IF( count_value>reference) THEN

IF(clk'EVENT AND clk='1') THEN
tolerable<='0';
END IF;
ELSE
tolerable<='1';
END IF;
END PROCESS;
--------------------
--Extended Block----
PROCESS(sensor_in,tolerable,rst,load)
BEGIN
IF(tolerable='1' AND rst='0' AND load='0') THEN
IF(sensor_in'EVENT AND sensor_in='1') THEN
enable_tmp<='1';
END IF;
ELSE
enable_tmp<='0';
END IF;
END PROCESS;
enable<=enable_tmp AND sensor_in;
--------------------
PROCESS(tolerable,clk)
BEGIN
IF(tolerable='0') THEN
degraded<='1';
END IF;
ELSE
degraded<='0';
END IF;
END PROCESS;
-- degraded<='1' WHEN tolerable='0' ELSE
-- '0';
END behaviour;

A.2 counter.vhd
LIBRARY ieee;
USE ieee.std_logic_arith.all;
USE work.components.all;
ENTITY counter IS
PORT( sensor_in,clk, rst,load: IN STD_LOGIC;
count_enable,overflow,degraded:OUT STD_LOGIC;
data:BUFFER STD_LOGIC_VECTOR(31 DOWNTO 0));
END ENTITY;
ARCHITECTURE behaviour OF counter IS
SIGNAL ctrl_count:STD_LOGIC_VECTOR(1 DOWNTO 0);
SIGNAL low_count,high_count:INTEGER RANGE 0 TO 65535;
SIGNAL low_overflow,high_overflow,high_enable,rst_count:STD_LOGIC;
SIGNAL reference:STD_LOGIC_VECTOR(31 DOWNTO 0)
:="00000000000000000011111100000000";
--"00000000000001001011111100000000";
BEGIN
rst_count<=rst OR ctrl_count(0);
high_enable<=ctrl_count(1) AND low_overflow;
overflow<=high_overflow;
control:counter_ctrl PORT MAP(sensor_in=>sensor_in,clk=>clk,rst=>rst,load=>load,
count_value=>data,reference=>reference,
control=>ctrl_count,
degraded=>degraded,enable=>count_enable);
low_word:generic_counter GENERIC MAP(65535) PORT
MAP(clk=>clk,rst=>rst_count,

enable=>ctrl_count(1),overflow=>low_overflow,
count=>low_count);
high_word:generic_counter GENERIC MAP(65535) PORT
MAP(clk=>clk,rst=>rst_count,
enable=>high_enable,overflow=>high_overflow,
count=>high_count);
PROCESS(rst,ctrl_count(2),low_count,high_count)
BEGIN
IF(rst='1') THEN
data<="00000000000000000000000000000000";
ELSE
data(15 DOWNTO 0)<=conv_std_logic_vector(low_count,16);
data(31 DOWNTO 16)<=conv_std_logic_vector(high_count,16);
END IF;
END PROCESS;
END behaviour;
A.3 decision.vhd
LIBRARY ieee;
USE ieee.std_logic_arith.all;
USE ieee.std_logic_signed.all;
ENTITY decision IS
PORT(rst,clk,count_enable,degraded:IN STD_LOGIC;
transition_enable: BUFFER STD_LOGIC;
status:OUT STD_LOGIC_VECTOR(1 DOWNTO 0));
END decision;
ARCHITECTURE behaviour OF decision IS
COMPONENT up_down_counter IS

GENERIC(n: INTEGER :=3);
PORT(clk,rst,up, down: IN STD_LOGIC;
overflow: OUT STD_LOGIC;
op:OUT INTEGER RANGE 0 TO n);
END COMPONENT;
SIGNAL state_count:INTEGER RANGE 0 TO 31;
SIGNAL count_enable_delayed: STD_LOGIC;
TYPE state IS(reset,a,b,c,d);
SIGNAL pr_state,nx_state: state;
TYPE state1 IS(reset1,normal,degrade,n1,nd1,nd2,d1,d2,d3);
SIGNAL pr_state1,nx_state1: state1;
SIGNAL up_down_ctrl: STD_LOGIC_VECTOR(2 DOWNTO 0);
BEGIN
PROCESS(count_enable,clk)
BEGIN
count_enable_delayed<=count_enable;
END IF;
END PROCESS;
transition_enable<= (NOT count_enable) AND count_enable_delayed;
-----State Density Counter----------------
PROCESS(rst,clk)
BEGIN
IF(rst='1') THEN
pr_state1<=reset1;
pr_state1<=nx_state1;
END IF;
END PROCESS;
PROCESS(transition_enable,rst,degraded,clk,pr_state1)
BEGIN
CASE pr_state1 IS

WHEN reset1=>
up_down_ctrl<="001";
nx_state1<=normal;
WHEN normal=>
IF(transition_enable='1') THEN
IF(degraded='1') THEN
nx_state1<=nd1;
ELSE
nx_state1<=n1;
END IF;
ELSE
nx_state1<=normal;
END IF;
WHEN n1 =>
nx_state1<=normal;
WHEN nd1 =>
nx_state1<=nd2;
WHEN nd2 =>
nx_state1<=degrade;
WHEN degrade=>
IF(transition_enable='1') THEN
IF(degraded='1') THEN
nx_state1<=d1;
ELSE
nx_state1<=n1;
END IF;
ELSE
nx_state1<=degrade;
END IF;
WHEN d1 =>
nx_state1<=d2;
WHEN d2 =>
nx_state1<=d3;
WHEN d3 =>

nx_state1<=degrade;
END CASE;
END PROCESS;
state_counter: up_down_counter GENERIC MAP(32) PORT
MAP(clk=>clk,rst=>rst AND up_down_ctrl(0),
up=>up_down_ctrl(2), down=>up_down_ctrl(1), op=>state_count);
----End State Density Counter---
----Alarm Module-------------
PROCESS(rst,clk)
BEGIN
IF(rst='1') THEN
pr_state<=reset;
pr_state<=nx_state;
END IF;
END PROCESS;
PROCESS(state_count, pr_state)
BEGIN
CASE pr_state IS
WHEN reset=>
status<="00";
nx_state<=a;
WHEN a=>
status<="00";
IF(state_count<12) THEN
nx_state<=a;
ELSE
nx_state<=b;
END IF;
WHEN b=>
status<="01";

IF(state_count>19) THEN
nx_state<=c;
ELSIF(state_count>8) THEN
nx_state<=b;
ELSE
nx_state<=a;
END IF;
WHEN c=>
status<="10";
nx_state<=d;
ELSIF(state_count>14) THEN
nx_state<=c;
ELSE
nx_state<=b;
END IF;
WHEN d=>
status<="11";
nx_state<=d;
ELSE
nx_state<=c;
END IF;
END CASE;
END PROCESS;
----End Alarm Module---------------
END behaviour;
A.4 count_stat_mux.vhd
LIBRARY ieee;
ENTITY count_stat_mux IS
PORT(status: IN STD_LOGIC_VECTOR(1 DOWNTO 0);
sel:IN INTEGER RANGE 0 TO 3;
count_in: IN STD_LOGIC_VECTOR(6 DOWNTO 0);
op: OUT STD_LOGIC_VECTOR(6 DOWNTO 0));
END count_stat_mux;

ARCHITECTURE behaviour OF count_stat_mux IS
BEGIN
PROCESS(count_in,sel,status)
BEGIN
CASE sel IS
WHEN 0=>
CASE status IS
WHEN "00"=>
op<=count_in;
WHEN "01"=>
op<="1111001";
WHEN "10"=>
op<="0100100";
WHEN "11"=>
op<="0110000";
END CASE;
WHEN 1=>
IF(status="00") THEN
op<=count_in;
ELSE
op<="0100001";
END IF;
WHEN 2=>
IF(status="00") THEN
op<=count_in;
ELSE
op<="1111111";
END IF;
WHEN 3=>
op<=count_in;
END CASE;
END PROCESS;
END behaviour;

References
[1] Patrcia Bouyer. Timed Automata-From Theory to Implementation LSV- CNRS
& ENS de Cachan France. 2003.
[2] Kwang Ting Cheng & A. S. Krishnakumar. Automatic Function Test Generation
Using The Extended Finite State Machine Model.
[3] Timed Automata: Semantics, Algorithms and Tools. Johan Bengtsson and Wang
Yi. UNU-IIST. 2004.
[4] A.Guerrouat, H. Richter. A Formal Approach for Analysis and Testing of Reliable
Embedded Systems.
[5] Sicco Verwer, Mathijs de Weerdt, and Cees Witteveen. Efﬁciently Learning Simple
Timed Automata

Faultdec

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (17)

Similar to Faultdec

Similar to Faultdec (20)

Recently uploaded

Recently uploaded (20)

Faultdec