COMPUTERIZED SIMULATION SYSTEM FOR ECM RADAR SYSTEM
MOHAMAD SABRI BIN SALLEH
A project report submitted in partial fulfillment
of the requirements for the award of the degree
of Master of Engineering
Electrical-Electronics and Telecommunication
(Electronic Warfare)
Faculty of Electrical Engineering
Universiti Teknologi Malaysia
MAY 2007
iii
This thesis is dedicated to father, mother and family.
Your prayer helps a lot. Thank you.
iv
ACKNOWLEDGEMENT
The author sincerely would like to express his deepest gratitude to Assoc.
Prof. Dr. Jasmy Yunus for his supervision and constructive ideas in carrying out this
project. Author also would like to thank his entire friend for their support and
contribution in giving invaluable idea, advice and assistance towards the completion
of this project. InsyaAllah.
Mohamad Sabri Salleh
v
ABSTRACT
The purpose of this project is to develop a simulation system for Electronic
Counter Measure (ECM) Radar System. The study of ECM system consist of basic
principle of radar, jammer, ECM and Electronic Counter Counter Measure (ECCM).
The principle of electromagnetic spectrum is the basic background for all calculation
and simulation. It is user friendly for design and training purposes. The simulation
system provides the application for user to design and learn about ECM Radar
System. User will be able to appreciate the principle behind the operation of
Electronic Warfare (EW).
This thesis documents the development of computerized simulation system
by using principle of software engineering which is Object Oriented (OO)
Methodology. The process started with requirement analysis on how the users wish
the system to be. The user needs a system which is able to evaluate equipment and
train personnel about EW theory. Then Unified Modeling Language (UML) was
used as a tool to implement the OO methodology. Use case diagram were used,
based on the requirement analysis. From the use case diagram, use case scenarios are
created to view on how the system works. Next sequence diagrams were used to
view the internal process within the simulation system. Finally before code
generation, the flow chart of the simulation algorithm was used. The system is based
on C++ Builder application; it has the capability of OO programming with the
enhancement of Visual Component Library (VCL). OO methodology with the tools
of UML has aided in the development of the system in a well structured manner.
vi
ABSTRAK
Projek ini adalah bertujuan untuk menghasilkan satu simulasi berkomputer
bagi pengoperasian Electronic Counter Measure (ECM) Radar System. Kajian
mengenai sistem ECM melibatkan teori radar, jammer, radar ECM dan Electronic
Counter Counter Measure (ECCM). Asas pengiraan spektrum elektromagnetik
merupakan asas pengiraan bagi simulasi ini. Simulasi ini dapat membuatkan
pengguna mempelajari dan menghayati teori pengunaan dan rekaan peperangan
elektronik. Ia mempunyai pengantara yang mudah guna bagi tujuan rekaan dan
pengorperasian.
Thesis ini adalah dokumen berkenaan pembinaan sistem simulasi
berkomputer menggunakan prinsip software engineering iaitu Object Oriented (OO)
Methodology khususnya. Proses bermula dengan pengumpulan data untuk
requirement analysis yang mana untuk mendapatkan apa yang dikehendaki oleh
pengguna terhadap sistem tersebut. Pengguna mengkehendaki satu sistem yang
berupaya menguji keupayaan peralatan dan juga melatih anggota mengenai teori
peperangan elektronik. Kemudian Unified Modeling Language (UML) telah
digunakan sebagai alat bantu melaksanakan OO methodologi ini. Use case diagram
digunakan berdasarkan maklumat dari kehendak pengguna. Daripada use case
diagram tersebut use case scenario telah direka untuk mengambarkan bagaiman
sistem itu berfungsi. Sequence diagram kemudiannya digunakan untuk memaparkan
proses demi proses dalam sistem tersebut. Akhir sekali carta aliran telah digunakan
untuk membantu pembinaan kod. Sistem ini adalah berasaskan C++Builder yang
mana mempunyai keupayaan pengaturcaraan OO dan dengan bantuan Visual
Component Library (VCL). OO methodologi dengan bantuan UML telah
memudahkan pembinaan pengaturcaraan dengan lebih sistematik.
vii
TABLE OF CONTENT
CHAPTER
1
2
TITLE
PAGE
DECLARATION
ii
DEDICATION
iii
ACKNOWLEDMENTS
iv
ABSTRACT
v
ABSTRAK
vi
TABLE OF CONTENTS
vii
LIST OF FIGURES
x
LIST OF TABLES
xii
LIST OF ABBREAVIATIONS
xiii
LIST OF APPENDICES
xiv
INTRODUCTION
1
1.1
Motivation for the Project
1
1.2
Project Objective
3
1.2.1
Simulation for Evaluation
3
1.2.2
Simulation for Training
4
1.2.3
Scope of Project
5
OVERVIEW ON SIMULATION DEVELOPMENT
7
AND SOFTWARE ENGINEERING
2.1
Simulation in Literature
7
2.1.1 Simulation for Command, Control,
7
Communication, Computer, Intelligence,
Surveillance and Recognition (C4ISR)
2.1.2
Simulation for Manufacturing Processes
8
2.1.3
Simulation for System Dynamics (SD)
8
viii
3
2.2
Software Engineering
9
2.3
Object Oriented (OO) Concept
12
2.4
Testing, Validation and Verification
13
2.5
Unified Modeling Language
14
2.6
Simulation Development by Using C++ Builder
17
OVERVIEW OF ELECTRONIC COUNTER
20
MEASURE (ECM) RADAR
3.1
Principle of Radar
20
3.2
Principle of Jammer
22
3.3
Burnthrough Range
22
3.3.1
24
3.4
4
Inverse Square Law and Power Reduction
Cross Eye Jamming
SOFTWARE DEVELOPMENT FOR SIMULATION
25
28
SYSTEM
4.1
Requirement Analysis
29
4.1.1 Requirement Analysis on Evaluation ECM
29
Radar Evaluation Module
4.1.2 Requirement Analysis on Burnthrough Range
30
Training Aid Module
4.1.3 Requirement Analysis on Cross Eye
31
Jamming Training Aid Module
4.2
Designing the Simulation by Using Object Oriented
31
Methology
4.2.1 Design for Evaluation ECM Radar Module
32
4.2.2
34
Design for Burnthrough Range Training Aid
Module
4.2.3
Design for Simularion of Cross Eye Jamming
Training Aid Module
35
ix
4.3
Code Generation
35
4.3.1
36
Code generation for Radar ECM Evaluation
Module
4.3.2 Code Generation for Burnthrough Range
38
Training Aid Module
4.3.3
Code Generation for Cross Eye Jamming
39
Training Aid Module
4.4
5
6
Testing
43
RESULT AND DISCUSSION
47
5.1
Result for Evaluation ECM Radar Module
47
5.2
Result for Burnthrough Range Training Aid Module
50
5.3
Result for Cross Eye Jamming Training Aid Module
52
CONCLUSION AND FUTURE WORK
56
6.1
56
Conclusion
6.2 Future Work
57
List of Reference
58
Appendix A
60
Appendix B
61
Appendix C
63
Appendix D
68
Appendix E
70
Appendix F
77
Appendix G
79
x
LIST OF FIGURES
FIGURE NO.
TITLE
PAGE
1.1
Electronic Warfare Overview
2
2.1
Relation of Software Engineering
10
2.2
Implementation of Software Engineering by Waterfall
Model
11
2.3
Example of Inheritance Hierarchical
13
2.4
A model of software testing process
14
2.5
Use Case’s notation in UML
15
2.6
Sequence Diagram
16
2.7
State Chart Diagram
16
2.8
The Start up Screen of C++ Builder
18
3.1
Radar Principle
21
3.2
Concept of Burnthrough Range
23
3.3
Burnthrough Range Graph
24
3.4
Cross Eye Jamming and Shifted Tracking Boresight
25
3.5
Cross Eye Jamming Technique
26
3.6
Jammer Power Ratio Base on GXE
26
4.1
Development of Simulation System for ECM Radar by
Using Waterfall Model
28
4.2
Use Case Diagram for User Select Radar and Jammer
32
4.3
Use Case Diagram for User Request Burnthrough Range
32
4.4
Sequence Diagram for Simulation of Evaluation Radar
and Jammer
33
4.5
Class Diagram for Simulation of ECM Radar Evaluation
33
4.6
Use Case Diagram for User Change Parameter Value
34
4.7
Sequence Diagram for Simulation of Burnthrough Range
Training Aid Module
34
xi
4.8
Use Case Diagram for User Change Parameter of Cross
Eye Jamming
35
4.9
Sequence Diagram for Cross Eye Jamming Training Aid
Module
35
4.10
Flow Chart for Radar ECM Evaluation Module
37
4.11
Flow Chart for Burnthrough Range Training Aid Module
39
4.12
Flow Chart for Simulation of Simulation Cross Eye
Jamming Training
41-42
5.1
Display of Main Module ECM Radar Evaluation Module
48
5.2
Display on Main Module for Selecting Radar and
Jammer.
48
5.3
Display of Main Module Showing Burnthrough Range
Button, Result, Analysis and Recommendation.
49
5.4
Display of Burnthrough Range Training Aid Module
50
5.5
Display of Burnthrough Range Training Aid Module with
An Example Calculation.
51
5.6
Display of Cross Eye Jamming Training Aid Module
52
5.7
Display of Cross Eye Jamming Training Aid Module with
An Example Calculation.
52
5.8
Display of Cross Eye Jamming Training Aid Module with
An Example Wrong Configuration.
53
xii
LIST OF TABLES
TABLE NO.
TITLE
PAGE
4.1
Radar Test Data for Simulation of ECM Radar Evaluation
Module and Burnthrough Range Training Aid Module.
44
4.2
Jammer Test Data for Simulation of ECM Radar
Evaluation Module and Burnthrough Range Training Aid
Module.
45
4.3
Expected Burnthrough Range Result for Simulation of
ECM Radar Evaluation Module and Burnthrough Range
Training Aid Module Using Data in Table 4.1 and Table
4.2.
45
4.4
Expected Result for Cross Eye Jamming Configuration of
2L Error and 15o Uncertainty Phase Angle.
46
4.5
Expected Result for Cross Eye Jamming Configuration of
100,000kW Power Transmit, 10 m2 Radar Cross Section
and 15o Angle of Phase Uncertainty
46
5.1
Result From Module Simulation ECM Radar Evaluation
49
5.2
Result From Module Simulation Burnthrough Range
Training Aids.
51
5.3
Result for Cross Eye Jamming Configuration of 2L Error
and 15o Uncertainty Phase Angle.
53
5.4
Result for Cross Eye Jamming Configuration of
100,000kW Power Transmit, 10 m2 Radar Cross Section
and 15o Angle of Phase Uncertainty
54
xiv
LIST OF APPENDICES
Appendix A: File1.h
Appendix B: Main.h
Appendix C: Main.cpp
Appendix D: Unit2.h
Appendix E: Unit2.cpp
Appendix F: Unit3.h
Appendix G: Unit3.cpp
CHAPTER 1
INTRODUCTION
This chapter provides an overview of the project conducted on Computerized
Simulation for Electronic Counter Measure (ECM) Radar System. The objectives
and the motivation of the project are introduced. The overview of the Electronic
Warfare is also presented.
1.1
Motivation for The Project
Electronic Warfare (EW) is defined in the “DOD Dictionary for Military
Terms” [1] as:
Electronic Warfare is a military actions involving the use of radio
energy to determine, exploit, reduce, prevent or deny the hostile
using electromagnetic spectrum. Electronic warfare consists of
Electronic Support Measure (ESM), Electronic Counter Measure (ECM)
and Electronic Counter Counter Measure (ECCM).
In other words, Electronic warfare is an action to win the war by using the
medium of electromagnetic (EM) spectrum. The strengths and weaknesses about
electromagnetic spectrum has open up ways to strategically win the war. The EW has
evolved very fast and the technology becomes more complex. The exploration on
environment behaviour, material, human factor and all other factor were considered
to design equipment which strategically will help to win the war.
2
Basic principal of winning the war are to be invisible and to attack the
defenceless opponent. In order to implement this, all the opponent sensors has to be
destroyed before proceeding further attack. With the technology of fast attack
equipment, knowledge about EW is vital to defend ourselves.
Electronic
Warfare
ESM
ECM
ECCM
Monitoring the
EM spectrum
to detect
hostile
transmission
Denying the
enemy
effective use of
EM spectrum
Preserving
one’s own use
of the EM
spectrum in the
face of enemy
attempt to deny
Figure 1.1: Electronic Warfare Overview
Source: David Adamy, EW 101 A First Course in Electronic Warfare, Artech House
Inc., Norwood, 2001.
As everyone is thinking to defend their country by improving their equipment
so that, it can work properly and deny any attack to blindfold them. There are ways
to attack and to deny attack from enemy, the same idea should be realized as the
enemy is also improving their equipment for the same purposes. Here the
information warfare is very vital in order to defend ourselves.
Communication technology is very vital, as the operations are all depend on it
to defend our country. The development of EW in Malaysia needs to be expedited in
order to get better confidence level on national security. National security will
contribute to positive development in all aspects.
Malaysian Armed Forces (MAF) has planned for the development of EW
knowledge and skills to all their personnel. The use of computerized simulation
system will help a lot in order to further develop the EW knowledge and skills.
3
Here, this project is to develop a simulation system on one of the field in EW.
ECM Radar is considered as the main part of EW. The learning and evaluation on
ECM Radar will help expedite the development of EW in MAF.
By having an evaluation simulation system, it helps to understand the
operation of the equipment and to choose the right equipment for the country. The
use of the simulation system also helps to expose our personnel to the operation of
EW. Same concept like the development of pilot simulator, a lot of benefit can be
achieved by having a good simulator system.
1.2
Project Objective
The objective of this project is to build a simulation system which consists of
evaluation and training element for Electronic Counter Measure (ECM) Radar. The
evaluation simulation is to measure the capability of ECM Radar against jammer.
Base on this evaluation helps personnel to plan for further action. It can be used for
tactical plan and strategic plan. Personnel also can use the simulation to measure the
capability of other jammer. This project is also to build training module, which will
demonstrate the calculation on EW operation. The personnel can compare the result
manually calculated versus result from the simulation. From there, they can learn and
appreciate the theory behind the EW operation. This simulation system is very
beneficial to proceed on other EW element.
1.2.1
Simulation for Evaluation
To evaluate the equipment, a user needs to explore the specification of the
equipment under evaluation. To evaluate the said specification we need to go through
all the calculation, based on EW theory and principle. The calculation and analysis
can prove the capability of the equipment as stated in the specification sheet. As well
known, most of the EW equipment is very expensive, so the verification and
4
validation on the equipment specification are extremely vital. By having a thorough
exploration on the equipment capability we can help to convince our management on
the return of investment on that equipment.
David L. Adamy [2] has discussed about simulation for equipment
evaluation, he said that:
Simulation for equipment Test and Evaluation (T & E) involves making
a piece of equipment think it is doing the job for which it was designed.
This can be as simple as generating a signal with the characteristics a
sensor is designed to detect. It can be as complex as generating a
realistic signal environment containing all of the signals a full system
will experience as it moves through a lengthy engagement scenario.
Further, that environment may vary in response to a preprogrammed or
operator-selected sequence of control and movement actions by the
system being tested. It is distinguished from training simulation in that
its purpose is to determine how well the equipment works rather than to
impart skills to operators.
This can help in choosing the right equipment, in procuring process. This also
can help in planning for the equipment life cycle cost. Other than that, the evaluation
result can be used as a reference for strategic and tactical planning. The strategic
planning based on the evaluation result also can help in predicting the performance
of the equipment. For the tactical planning the data’s are used for references to know
the performance and capability of the equipment.
1.2.2
Simulation for Training
David L. Adamy [2] also has discussed about simulation for training, he said
that:
It exposes student to experiences (in a safe and controlled way) that
allow personnel to learn or practice various types of skills. In EW
training, this most often involves the experiencing of enemy signals in
5
the way they would be encountered if the trainee were at an operating
position in a military situation. EW simulation is often combined with
other types of simulation to provide a full training experience. For
example, a cockpit simulation for a particular aircraft may include EW
display that reacts as though the aircraft were flying through a hostile
electronic
environment.
Training
how
the
personnel
respond.
Sometimes, the instructor can play back the situation and responses as
part of the debriefing after a training exercise, which considered a
powerful learning experience.
The trainees become more intimate to the EW field as they can experience the
operation base on the simulation. By having these two capabilities of the simulation,
it helps to expedite the development of EW in Malaysia. EW is very vital in any war
strategies, as nowadays communication becomes common and everybody is involved
in those communications.
1.3 Scope of Project
Base on the project objectives, the scope of this project is to build evaluation
module on burnthrough range between ECM radar and jammer, training module on
burnthrough range and training module on cross eye jamming.
Evaluation on burnthrough range between ECM radar and jammer provides
list of ECM radar and jammer, which will be chosen by the user. Then selected
equipment will be evaluated on burnthrough range parameter. The parameter will be
displayed for user to perform manual calculation. The module also will give a brief
analysis on the burnthrough range result. Other than evaluation on that equipment, it
also works as database on the characteristic of ECM radar and jammer.
Training module consist of burnthrough range and cross eye jamming
calculation. Users are able to change any parameter and observed the result
automatically. These give the user chance to appreciate the effect of each parameter
6
and relate to the theory of EW and electromagnetic waves. For the burnthrough range
training module, user able to change the parameter value by key in the value or using
the sliding bar. The simulation also displays bar graph which represents the value of
burnthrough range. This is to give user chance to observe immediately whether the
result are increasing or decreasing. For cross eye jamming training module, it has
parameter to be changed by the user. It displays the result on configuration of the
jammer versus the characteristic of the target radar.
CHAPTER 2
OVERVIEW ON SIMULATION DEVELOPMENT AND SOFTWARE
ENGINEERING
This chapter provides the overview on simulation and software engineering.
Simulation development has been surveyed from other author to see their view. The
simulation development consists of various methods and also depends on application.
Software engineering for simulation system development involves OO method, UML
and C++ Builder application.
2.1
Simulation in Literature
2.1.1
Simulation for Command, Control, Communication, Computer,
Intelligence, Surveillance and Recognition (C4ISR)
Hollenbach, W. and Misch, L. in [3] discussed the importance of simulation
and modeling in the interoperability of Command, Control, Communication,
Computer, Intelligence, Surveillance and Recognitions (C4ISR). The traditional
C4ISR systems, according to [3] were more mission focused, and designed for
operational requirements. This paper indicated that the major importance of
distributed C4ISR system was in the training of personnel and mission planning.
Better training can be achieved by the integration of simulation systems with actual
C4ISR systems to provide dynamic environmental data. Mission planning faces two
challenges; one challenge is the variation of events that might occur during the plan
8
execution, the other challenge is the different actions that can be taken to execute the
plan. Mission planning has not been totally automated yet. The authors suggested that
the simulation would assist the planner and the decision maker in testing the plan and
rapidly re-plan and re-test as the situation changes. This requires faster simulation
systems for training, hence distributed simulation systems would be needed to achieve
the required speed. The importance of the visualization in plan simulation of the paper
was then being discussed visualization in plan simulation. Visualization would
provide a strong tool for plan validation after simulation.
2.1.2
Simulation for Manufacturing Processes
Charles Harrell in [4] discussed about how to model the simulation system
with realization of process simulation and system simulation. Process is a sequence
of activities that converts input into output. Processes implemented by the system.
System is collection of elements that are coordinated to achieve a common goal.
Traditional way to analyze processes is to do static analysis looking at process has
been converting from a system paradigm to a process paradigm. Author discussed
about ICAM DEFINITION (IDEF) language developed by the US Air Force through
its ICAM program, free style mapping and American Society of Mechanical
Engineer (ASME) standard for mapping. ASME standard used symbol for categories
of process. Author suggested that integration of simulation with process mapping has
been proven successful and is encouraging more analytical thinking in the design of
such processes. This suggestion by the author has made a good comparison to the
method used in order to help in a more efficient designing of this project.
2.1.3
Simulation for System Dynamics (SD)
Ddembe Williams and Michael Kennedy in [5] discussed about the utility of
the application of Component-Based Programming (CBP) techniques to the
development of a System Dynamics (SD) simulation model. Many problems being
9
examined by SD techniques are complex and thus time consuming. Current
simulation software used in modeling system that is predominantly continuous in
nature is called SD software packages. The term “simulation software” is used in a
broad sense to describe simulation language and software packages or “simulator”.
Author suggested that the application of CBP and simulator to the development of an
experimental SD simulation model. It is possible to highlight the potential of CBP and
the capability and flexibility of the SD approach. It was possible to create an
interesting simulation environment within a short period of time, but it does not, to the
extent, fully change the way in which SD models are created. Author suggested that
further work to implement a method for modifying existing component for use as
simulation component. Base on observation made by the author [5], his project
involves system dynamics, which are more complex than this project of evaluation
and training module. The use of component base programming is a good example as
the more complex simulation using it as a tool.
2.2
Software Engineering
Software Engineering defined by [6] is an engineering discipline that is
concerned with all aspects of software production from the early stages of system
specification to maintaining the system after it has gone into use.
(i)
Engineering discipline. Engineers make things work. They apply theories,
methods and tools where there are appropriate, but they use them selectively
and always try to discover solutions to problems even when there are no
applicable theories and methods. Engineers also recognize that they must
work to organizational and financial constraints, so they look for solutions
within these constraints.
(ii)
All aspect of software production. Software engineering is not just concerned
with the technical processes of software development but also with activities
such as software project management and with the development of tools,
methods and theories to support software production.
10
The software engineering was formulated after years of handling such
behavior. From the experience, software engineering suggest the better way of
developing the software. It includes all aspect needed to help the software
development smooth, traceable and success.
The software engineering has included the process from the beginning of the
software development until the system is in operation and maintained. For this
project, it uses software engineering value such as; waterfall model, Unified Modeling
Language (UML) concept and object oriented programming. These values seems very
beneficial to the simulation system software development.
Figure 2.1: Relation of Software Engineering
Source: Ian Sommerville, Software Engineering, Addison Wesley, Edinburgh, 2004.
Software engineering has been derived from the experience and refers to the
system engineering. The term ‘system’ has means purposeful collection of interrelated component working together towards some common objective. This is
applicable to the software engineering, which also having the same item as a
11
component and work together to achieve one objective. These interrelation are
dependable and usable, the object oriented are suggested for the software
development. It helps to minimize custom made function by using usable functions
which adaptable to other events.
In general, software engineers adopt a systematic and organized approach to
their work, as this is often the most effective way to produce high quality software.
However, engineering is all about selecting the most appropriate method for a set of
circumstances and more creative, less formal approach to development may be
effective in some circumstances. Less formal development is particularly appropriate
for the development of web-based systems, which requires a blend of software and
graphical design skills.
Requirement analysis
Design
Implementation
Testing
Figure 2.2: Implementation of Software Engineering by Waterfall Model
As defined in [6] Requirement Analysis is based on description of the service
provided by the system and its operational constraints. These requirements reflect the
needs of the customers for system that helps solve some problem such as controlling
a device, placing an order or finding information. Requirements are consist of user
requirements and system requirement.
(i)
User requirements are statements, in a natural language plus diagrams, of
what service the system is expected to provide and the constraints under
which it must operate.
12
(ii)
System requirements set out the system’s functions, services and operational
constraints in detail. The system requirements document should be precise. It
should define exactly what is to be implemented. It may be part of the
contract between the system buyer and the software developers.
2.3
Object Oriented (OO) Concept
As for this project the design phase of software engineering are using object
oriented methodology, here the overview about OO. Object Oriented means that
organize software as a collection of discrete object that incorporate both data
structure and behavior. Object oriented generally include four aspects as follows:
(i)
Identity
(ii)
Classification
(iii)
Polymorphism
(iv)
Inheritance
Identity means that data is quantized into discrete, distinguishable entities
called objects. Example of real-world objects are like cat, desk etc. The entire object
shares two characteristics, state and behavior.
Classification means that object with the same data structure (attribute) and
behavior (operation) are grouped into a class. One example of class is desk. My desk
and my friend’s desk is an object with respect to desk class.
Polymorphism means that the same operation may behave differently on
different classes. An operation is an action or transformation that an object performs
or is subject to. For example two or more class could each have a method called
output. Each output would do the right thin for the class that it was in. One output
might display a number whereas a different one might display a name.
13
Inheritance is a way of organizing classes as sharing of attributes and
operation among classes based on a hierarchical relationship. A class can be defined
broadly and then refined into successively finer subclasses.
Vehicle
Automobile
Sedan
Hatchback
Motorcycle
Bus
School bus
Luxury bus
Figure 2.3: Example of Inheritance Hierarchical
2.4
Testing, Validation and Verification
Validation and Verification (V & V) as define in [6] is to establish confidence
that the software is ‘fit for purpose’. This means that the system must be good
enough for its intended use. The level of required confidence depends on the
system’s purpose, the expectations of the system user and the current marketing
environment for the system.
Validation can be phrase as: Are we building the right product? On the other
side Verification can be phrase as: Are we building the product right. For
verification, the software should confirm to its specification and for validation, the
software should do what the user really requires.
V & V is a whole life cycle process and it is for discovery of defects in a
system and for assessment of whether or not the system is usable in an operational
situation.
Software inspection is concerned with analysis of static system representation
to discover problem or also known as static verification. It may be supplement by
tool-based document and code analysis. Software testing is concerned with
14
exercising and observing product behavior, it also known as dynamic verification.
The system is executed with test data and its operational behavior is observed.
Testing shows the presence of error and it cannot demonstrate that there are
no remaining faults. Software testing consists of aspect as follows:
(i)
System testing
(ii)
Component testing
(iii)
Test case design
(iv)
Test automation
Test plan should be drawn up to guide the testing process. When testing a
system, the objective is to ‘break’ the system by using experience and guideline to
choose types of test cases that have been effective in discovering defects in other
systems.
Test
cases
Design test
cases
Test
data
Prepare test
data
Test
results
Run program
with test data
Test
reports
Compare results
to test cases
Figure 2.4: A model of software testing process
2.5
Unified Modeling Language (UML)
To implement the code generation, the UML diagram are very useful tools for
the purpose. UML helps to design the software and to model the system in order to
develop the software. The most important part in OO problem solving is the
construction of a model. Model consists of objects interacting by sending message.
The UML is defined by [7] is ‘a general purpose visual modeling language
that is used to specify, visualize, construct and document the architecture of a
15
software system’. UML helps in specifying the system by helping the developer
build models of the system that are clear, easy to understand, and fully represent
what the designer wants. During the problem specification, the problem needs to be
modeled in a way that it will be easy to communicate to other members of the team.
80 % of problem can be modeled by 20 % of UML.
When the models of a system are built successfully, they can be mapped to a
source code of object oriented programming language such as C++. Mapping the
models into a code is known as “forward engineering”.
UML consist of a few type of diagram, there are a few diagram which
frequently used for software design. Use case diagram, use case scenario and class
diagram is the main diagram represented in the Software Engineering.
Use case diagram is to describe the functional behavior of the system as seen
by the user. A sequence of use cases introduces what that actor expects from the
system. The collaboration in turn is the link between the behavior of a use case and
the structure of the class objects. The use cases work together to model the overall
system task. Figure below show UML notation for use case.
communication
Make
decision
actor
use case
Figure 2.5: Use Case’s notation in UML
Sequence Diagram describes the dynamic behavior between actors and the
system and between objects of the system. Sequence diagram emphasize the
behavioral aspects of collaboration. They model the flow of control, emphasize the
time ordering of messages and show the lifetime of transient objects. Figure 2.6
shows an example of a sequence diagram.
16
Figure 2.6: Sequence Diagram
Use Case Scenario, it also known as the use case description, it is the textual
description of the use cases. The important detail of the system’s functionality are
considered and documented.
State Chart Diagram is equivalent to the well-known state machines. They are
made up of states, the activities performed at each state, and the transition from one
state to another. State chart diagrams capture the dynamic aspect of classes or
collaborations.
Figure 2.7: State Chart Diagram
To develop a program of a system, it is not typically necessary to use the
entire UML diagram. It has to be chosen based on preference and particular situation.
A single use case may not capture all scenario, design of software with the tools of
UML require us to design what is optimize according to the scope and requirement.
UML also available in application tools, it is such Rational Rose which the popular
software for UML creation.
Mohammad S. Al –Aqrabawi in [6], described how to use Unified Modeling
Language (UML) to model a software-intensive simulation for the combat systems
of a fully automated naval "digital ship". The UML, an Object Management Group's
17
(OMG) standard, is a graphical modeling language used for specifying, visualizing,
constructing, and documenting software intensive artifacts. UML, which has been
accepted as an industry standard in November 1997, has aided the design and
maintenance of object-oriented legacy applications. While the software developers
were building UML models for their existing applications as part of a reverseengineering process, development of next generation software applications started
from the models (forward-engineering process). In the forward engineering process,
the system's code is specified and constructed from the UML models, which evolve
as the system evolves in order to maintain consistent documentation and
visualization of the system. Moreover, UML has the power of hiding unnecessary
details of the system by the ability to model its different views. This enables
visualizing the system at different levels of hierarchy. Using UML has aided in
building a well-structured object-oriented application, validating the use cases of the
application with the domain experts, visualizing and validating the structure of the
source code before writing it, communicating between different members of the
development team, and providing an easily understandable documentation of the
system.
2.6
Simulation Development by Using C++ Builder
Author in [5] also describe the overview of C++ Builder in implementing the
CBP concept. Borland International describes the C++ Builder as a visual
programming environment where 32-bit Windows applications can be designed,
developed and debugged. The style of programming supported by C++ Builder is
widely known as CBP. Telles (1997) describes it as a true Rapid Application
Development (RAD) tool for the C++ Windows programming world. The OO
concept of reusing is central to CBP. C++ Builder offers programmers a dual
approach to programming using the C++ language. It offers the opportunity to
program within an Integrated Development Environment that allows program to be
written, edited, compiled and linked, all within a single application and it offers CBP
in which component are used in application to ease the programming task and cut
18
down on development time. Standards established for the creation of the required
component are universal and transferable from system to system regardless of
language. In order to allow for the creation of component which may be used on
other platforms, and facilitate the use and manipulation of components from other
platforms in C++ Builder applications, additions were made to the C++ syntax.
Figure 2.7 shows an editor, a form, the object inspector, the component palette and
the tool bar in the start up screen of C++ Builder.
Figure 2.8: The Start up Screen of C++ Builder
The C++ Builder describes a component as an object in code. Visual
Component Library (VCL) contains different types of objects, some of which are not
components. Components in C++ Builder are identified as any class, which is
directly descended from the TComponent class. Objects, which are not components,
are derived directly from TObject, the ancestor class at the top of the VCL hierarchy.
VCL is a good example of the use of inheritance, in object-oriented terms.
TComponent, the ancestor of all components in the VCL provides the minimal
properties and events necessary for a component to work in the C++ Builder
environment. Other base classes, which descend from it, have specialized
capabilities, which are present in all class, derived from them. For example, all edit-
19
box and memo controls are derived from the TCustomEdit base class that
encapsulates the fundamental behavior common to all components, which edit text.
One significant characteristic of all components is that they are visual and can
be manipulated at design time. However, whilst some components remain visible at
runtime, some do not play any visible role in an application at runtime because they
are program elements which act either as a placeholder, or an interface for the
manipulation of underlying data. For example, DataSource is a non-visual (at
runtime) component that provides a conduit between a dataset and data-aware control
that enable the display, navigation and editing of underlying data in the dataset. Nonvisual component such as these are derived directly from TComponent whilst visual
component such as Edit Boxes (also known as controls) are derived from TControl, a
specialized base class derived from TComponent. Another characteristic of CBP is
the universalilty advocated for component use and distribution. Some of the
components are written in Pascal whilst some are outright in ActiveX controls. C++
Builder also supports the development, installation and use of new components in its
environment.
CHAPTER 3
OVERVIEW OF ELECTRONIC COUNTER MEASURE (ECM) RADAR
This chapter provides an overview of ECM Radar. Basic radar, jammer, and
ECM radar are presented. Burnthrough range and cross eye jamming were also
presented.
3.1
Principle of Radar
The term ‘radar’ is the abbreviation of Radio Detection and Ranging. Radar is
an electromagnetic system used for the detection and location of objects. It operates
by transmitting a particular type of electromagnetic waveform; a pulse modulated
sine wave for example, and detects the nature of the returned signal, called the echo
signal.
Radar is used to extend the capability of one’s senses for observing the
environment, especially the sense of vision. Radar has the advantage of being able to
measure the distance or range to an object (target). This is probably the most
important attribute. The basic form of radar consists of a transmitting antenna
emitting electromagnetic radiation generated by an oscillator of some sort, a
receiving antenna, and an energy detecting device, or receiver.
A portion of the transmitted signal is intercepted by a reflecting object
(target) and is reradiated in all directions. It is the energy reradiated by the target that
21
is of prime interest to the radar. The receiving antenna collects the returned energy
and feeds it to the receiver, where it is processed to detect the presence of the target
and to calculate its location and relative velocity.
The distance to the target is determined by measuring the time taken for the
radar signal to travel to the target and back. The direction or angular position, of the
target may be determined from the direction of arrival of the reflected wave front. If
relative motion exists between target and radar, the shift in the carrier frequency of
the reflected wave (Doppler Effect) is a measure of the target’s relative (radial)
velocity and may be used to distinguish between moving targets and stationary
objects. In radars, which continuously track the movement of a target, a continuous
indication of the rate of change of target position is also available.
Figure 3.1: Radar Principle
Radar receivers are designed to deal with extremely small signals and need to
be extremely sensitive. They are therefore very vulnerable to noise jamming. If the
noise jamming is larger in amplitude than the radar return signal, it will mask the
return signal and prevent it from being detected and displayed. This happens when the
Signal to Noise ratio (SNR) is less than one, (SNR < 1).
22
3.2
Principle of Jammer
EM jamming and EM deception are the most common forms of ECM. EM
jamming is also known as noise jamming, and was the first type of active radar ECM
to develop during World War II. Noise jamming also represents the simplest form of
jamming, which has predictable results. However, noise jamming is still an effective
radar ECM technique that is still in use today.
The aim of noise jamming is to deny or degrade information to threat radars,
by inserting a stronger signal into the victim radar’s receiver.
This effectively
decreases the signal-to-noise ratio (SNR). Noise jamming can deny or degrade radar
range information and, with a very powerful jamming signal, may also deny or
degrade angle information.
To noise jam radar successfully, a noise jammer needs to:
(i)
Know the victim radar’s frequency.
(ii)
Know the victim radar’s bandwidth, (for maximum effectiveness).
(iii)
Have sufficient jamming power available.
(iv)
Be able to jam in the correct direction.
The noise jamming signal can be random white noise, (often referred to as
plain noise). Or the noise jamming can be modulated in some way, (modulated
noise). Amplitude Modulated noise (AM noise) or Frequency Modulated noise (FM
noise) can be used.
AM and FM noise can operate at fixed amplitudes and
frequencies, or be swept over a range of values.
3.3
Burnthrough Range
Burnthrough range is known as the distance to the target at which the radar
has adequate signal quality to track the target. At ranges less than the burnthrough
23
range, the radar echo will be stronger than the jamming signal and the target will
then be detectable. At ranges greater than the burnthrough range the jamming should
mask the radar echo. Noise jamming is basically a power battle between the radar
and the jammer. If the jamming signal is more powerful than the radar return, the
radar will be jammed. This occurs when the SNR is less than one (SNR < 1). If the
radar return is more powerful than the jamming signal, the jamming will not be
successful and the target will still be seen.
The basic concept of Burnthrough range can be depicted as a following
diagram. Meanwhile the Algorithm for Radar, Algorithm for Jammer, Algorithm for
Burnthrough Range, Burnthrough Range Graph, Burnthrough Range Simulation and
Burnthrough Range Preliminary Result was derived subsequently.
Figure 3.2: Concept of Burnthrough Range
Burnthrough Range Equation
RBT
=
PRGRσAR
PJGJ4 π La
PR = Power of the radar
PJ = Power of the jammer
GR = Gain of the radar
GJ = Gain of the jammer
σ = Aircraft radar cross section
La = Atmosphere loss
½
(3.1)
24
Figure 3.3: Burnthrough Range Graph
3.3.1
Inverse Square Law and Power Reduction
The inverse square law governs all EM propagation. The power of radar
signal will be reduced by an amount inversely proportional to the square of the
distance it travels to the target:
P ∝ 1/R2
(3.2)
The radar return echo will also be reduced in power by an amount inversely
proportional to the distance it travels back to the radar receiver. This gives a 2-way
power loss of:
P ∝ 1/R4
(3.3)
Burnthrough range can be calculated from a standard set of figures and
conditions. However, in reality burnthrough range is never constant, but changes
according to the following factors:
(i)
Jammer power.
(ii)
Victim radar power.
(iii)
Victim radar processing techniques.
(iv)
Variations in the target Radar Cross Section (RCS).
25
3.4
Cross Eye Jamming
Cross Eye Jamming is between target (jammer) and tracking radar (victim).
The target which has been track by the radar will launch Cross Eye Jamming to get
away from the tracking radar.
This technique involves the jammer emitting two signals in anti phase from
two points on its platform. This might be the two wings of an aircraft, or two
different points on a ship or tank.
Figure 3.4: Cross Eye Jamming and Shifted Tracking Boresight
The radiation from the two sources will interfere as it travels towards the
monopulse antenna. The result is an interference pattern with distorted wavefront. At
the antenna the tracking boresight will point at right angles to the wavefront.
Whenever the two radiation are opposite in phase, the antenna tends to point to much
higher than the target position.
26
Figure 3.5: Cross Eye Jamming Technique
The technique implemented by using two coherent sources, separated by
distance L and it’s generate phase distortion of wave front. These two sources are
180o out of phase.
Gain Cross Eye Jamming; GXE =
δ
L/2
(3.4)
To implement the cross eye jamming the GXE must greater than 1 to make
sure the tracking radar miss the target.
Figure 3.6: Jammer Power Ratio Base on GXE
27
Example of Cross Eye Jamming;
1. Error, δ = 2L;. (L= length between two transmitter)
2. Angle phase uncertainty = 15o.
3. Power Transmit by tracking radar = 108 W.
4. Radar Cross Section = 10 m2.
5. Range = 30 km.
GXE =
δ
L/2
=4
Upper angle = 180O + 15O = 195O.
Lower angle = 180° - 15° = 165°.
By using GXE and angle of uncertainty, refer to graph Jammer Power Ratio to get the
K2 = 0.7
E field ratio =
0.7 = K = 0.837
∴ E field cancellation = 1- 0.837
= 0.163
Received power from Jammer = (0.163) 2 * P1
= 0.0267 P1
∴ 0.0267 P1 > Pskin
>
(Radar Transmit Power)(RCS )
(4Π )(30 K ) 2
> 88.4 mW
P1 > 3.31 W
∴ P1 = 3.31 W represent as the stronger jammer.
P2 = K2 * P1
= 0.7 * 3.31
= 2.32 W
P1 = 3.31 W and P2 = 2.32 W
CHAPTER 4
SOFTWARE DEVELOPMENT FOR SIMULATION SYSTEM
The purpose of this project is to develop a simulation system for ECM Radar.
Its involve element of Software Engineering and Electronic Warfare theory. The
development of the simulation system was implemented by using Software
Engineering discipline.
Requirement analysis
•To evaluate equipment
•To train personnel in EW
Design (Object Oriented
methodology)
•Burnthrough range
Calculation scenario and
Cross Eye Jamming.
Implementation
• Software development
Testing
• Design test set
Figure 4.1: Development of Simulation System for ECM Radar by Using Waterfall
Model
29
4.1
Requirement Analysis
Review of similar theses also helps in implementing this project. With all
information gathered, the mechanism needed for the simulation system has to be
listed down. All parameter involve were listed down which will be used in
developing the system.
The user requirement is collected from all the sources gathered. From
example of other simulation system, the weaknesses that arose are taken into
consideration. It also from the discussion between colleagues, the feedback is based
on their experience using such system.
Requirement analysis is focusing on the user requirement when the
simulation system to be ready. The user view on how they to operate and make use
on the simulation for their purpose are taken into consideration. The user also gives
the scenario on how the system will be used. The interface must be able to help them
to evaluate and train the personnel.
4.1.1
Requirement Analysis on ECM Radar Evaluation Module
Base on user requirement survey, below are the outcomes of what required by
the user for the evaluation module:-
(i)
System that could provide the ability for user to view list of radar and
jammer. Those list are comes from data base of radar and jammer.
(ii)
The user able to choose the equipment item by computer using mouse to
select from scrollbar for respective list.
(iii)
The system able to display the specification of each equipment which
selected by the user.
(iv)
The user able to request burnthrough range calculation by pushing button.
(v)
The system is required to display the result of burnthrough range in km
and 2 decimal points.
30
(vi)
The system also required to give brief analysis from the burnthrough
range result. The presentation of analysis is on memo text box, which
easy to be read.
(vii)
As the first module, the module has the option button to go to next
module.
(viii)
The system is in computer base or a console with monitor, keyboard and
mouse.
4.1.2 Requirement Analysis on Burnthrough Range Training Aid Module
The user requirements for burnthrough range training module are as follows:
(i)
(ii)
The display has all parameter listed; those parameter are:a.
Radar Transmit Power.
b.
Radar Antenna Gain.
c.
Radar Cross Section.
d.
Jammer Transmit Power.
e.
Jammer antenna gain.
f.
Atmosphere Loss.
The display have edit text box and sliding bar, these are for user to change
parameter value.
(iii)
User able to key in any parameter data value, then the sliding bar
response respectively and user also can change the value by using sliding
bar, so the edit box value change accordingly
(iv)
The system displays the value of burnthrough range in edit text box.
(v)
The system able to give graphical representation on how the effects of
burnthrough range from parameter change.
(vi)
The module can go back to previous display, which is module evaluation
equipment by pushing ’Back’ button.
31
4.1.3 Requirement Analysis on Cross Eye Jamming Training Aid Module
For cross eye jamming training module, the user requirements are as follows:-
(i)
The display module is after main module, which is the evaluation module.
(ii)
Cross eye jamming training module provide parameter to be changed,
parameters are as follows:a. Error
b. Cross eye jamming angle phase uncertainty
c. Tracking radar characteristic; transmit power, radar cross section and
range.
(iii)
The result displays the angle, Cross eye gain, value of K2, Power 1 and
Power 2.
(iv)
Changes of parameter are by using mouse and keyboard.
(v)
The result display immediately after parameter change.
The cross eye jamming training module should have feature of variable
change to observe the formula of calculation for cross eye jamming. The resultant
Power 1 and Power 2 will be compared with manual calculation. It helps personnel to
understand the theory behind the cross eye jamming.
4.2
Designing the Simulation by Using Object Oriented Methodology
Block diagram is used in designing and modeling the system for better view.
The model is designed module by module. The objects oriented are represented in
Unified Modeling Language (UML). The UML diagram provides an efficient means
of understanding system modules without having to read the actual code.
UML are chosen to help in designing the simulation program. As proposed by
UML, this project will go through process of Use Case Diagram, Use Case Scenario,
Sequence Diagram and Class Diagram.
32
4.2.1
Design for ECM Radar Evaluation Module
Select radar
and jammer
user
Figure 4.2: Use Case Diagram for User Select Radar and Jammer.
Use Case Scenario 1
The user observes the list of radar and jammer. User then selects radar and
jammer to be evaluated by clicking on of the radar and jammer. The system displays
the specification value of the selected radar and jammer.
Request
burnthrough
range
user
Figure 4.3: Use Case Diagram for User Request Burnthrough Range.
Use Case Scenario 2
As the system displayed the specification of selected radar and jammer, the
user push button burnthrough range to get the result of bunrnthrough range. The
system will display the result of burnthrough range and brief analysis with respect
the burnthrough range value resulted.
33
Sequence Diagram
User
System
Database
Select radar and jammer
Identify specification value
Display specification
Push button burnthrough range
Display Burnthrough range
Display analysis and
recomendation
Figure 4.4: Sequence Diagram for Simulation of Evaluation Radar and Jammer
Radar
Jammer
void key in()
void key out()
void key in()
void key out()
1
1
Antenna
nama, power,
gain, RCS
Figure 4.5: Class Diagram for Simulation of ECM Radar Evaluation
34
4.2.2
Design for Burnthrough Range Training Aid Module
Change
parameter
value
user
Figure 4.6: Use Case Diagram for User Change Parameter Value.
Use Case Scenario
User observed the available parameter to be changed. Then the user can key in new
value or change the value by sliding bar. System will display value of burnthrough
range and change the width of the bar graph.
Sequence Diagram
User
System
Change parameter value
Display Burnthrough range
Change of value of
burnthrough range and bar
graph
Figure 4.7: Sequence Diagram for Burnthrough Range Training Aid Module
35
4.2.3
Design for Cross Eye Jamming Training Aid Module
Use Case Diagram
Select radar
and jammer
user
Figure 4.8: Use Case Diagram for User Change Parameter of Cross Eye Jamming.
Use Case Scenario
The system gives option on parameter required. User change input parameter value
to be calculated. Calculation involves data from reference of cross eye jamming gain
characteristics. System performs calculation and display result.
Sequence Diagram
User
System
Change input parameter
Display result
Figure 4.9: Sequence Diagram for Cross Eye Jamming Training Aid Module
4.3
Code Generation
Based on the UML tools, Use Case Diagram, Use Case Scenario, Sequence
Diagram and List of Class helps in viewing how the simulation will work.
C++ Builder gives the opportunity to the developer to design the program by
objects represented in Visual Component Library (VCL). From the list of class, the
36
developer can design the interface of the simulation system. By using the VCL the
developer has to pick and place the component on the form according their function.
From the form, with all component needed already placed, the developer has
to write the initialization variable and value, then function will be used and the
handler for the program to operate.
4.3.1
Code generation for ECM Radar Evaluation Module
This module consists of few program functions as follows:
(i)
Load data from file
(ii)
Display data
(iii)
Calculate data
(iv)
Display analysis
The load data from file is a function which retrieves data from file or can be
called database. This data were key in to the vector radar or known as array of data.
Vector is one of the container classes inside C++ Builder. A container is an object
that can hold any number of other objects of a single specified type. The specified
type can be a built-in type like an integer or a float, or it can be a user-defined type,
like a record containing fields of different types, or an object instantiated from a C++
class which have been defined. Container classes support standard operations on data
structures through a coding interface that is easy to use and strongly standardized.
Vector is a type of sequence that supports random access iterators. This vector is
used to retrieve data for any selected radar or jammer.
Display data is a function to display data into the edit text box. To display the
data, it waits the input index number from ComboBox which represent the list of
radar or jammer name. The index number will be used to retrieve particular data
from vector. Then the data are display on to the edit text box and also will be use for
further operation such burnthrough range calculation.
37
Calculate data or calculate Burnthrough Range (Rt) is a function consists of
formula of the burnthrough range. The formula needs data value from radar and
jammer. The data are ready when the radar and jammer are selected. As the index
number from ComboBox point to particular data, the data will be plugged in to the
formula and new value of Rt updated. The value of Rt will be represented in the Rt
edit text box and it also become an input for analysis.
Display analysis is a function which receives input from value of Rt then it
will be tested under condition design to display respective analysis. Source code for
this module as in the Appendix A, B and C. The flow chart is as figure below.
Start
Training module
Main module
Choose Radar and
Jammer
Display specification
of selected Radar and
Jammer
Rt training
Module
Cross eye jamming
training module
Push
button Rt
Calculate Rt with the
selected specification
Display Rt and
Analysis
End
Figure 4.10: Flow Chart for ECM Radar Evaluation Module.
38
4.3.2
Code Generation for Burnthrough Range Training Aid Module
This module consists of function such as follows:
(i)
Edit Text Change
(ii)
Scroll Bar Change
(iii)
Calculate
(iv)
Shape Width change
The Edit Text Change is a function which the user will key in value of
variable then the value of respective variable will change. The change will trigger the
Calculate function and will response according to the Calculate formula. It also will
change the position of Scroll Bar accordingly.
Scroll Bar Change is a function which the user will drag the scroll bar to
change the value of respective variable. The change will trigger the Calculate
function and will response according to the Calculate formula. It will also change the
value inside Edit Text accordingly.
The Calculate is function to calculate the burnthrough range value. It will
return the value of Rt. Calculate function are depend either Edit Text Change or
Scroll Bar Change, the changes either one of these will change the value of Rt.
When the value of Rt change, it will be represented by the shape in terms of
width. It is to show how the result of Rt with respect to the formula of the
burnthrough range. Source codes for this module are as in Appendix D and E. The
flow chart is in Figure 4.11.
39
Start
Change
parameter value
by edit box
Change parameter
value by sliding
bar
Value for
Rt
calculation
Display result and
change of bar
graph width
End
Figure 4.11: Flow Chart for Burnthrough Range Training Aid Module
4.3.3
Code Generation for Cross Eye Jamming Training Aid Module
For Cross Eye Jamming Training Aid module, it consists of few classes as
follows:
a.
GainXE (Gain Cross Eye)
b.
Angle
c.
K2
d.
Power 1 (P1)
e.
Power 2 (P2)
40
GainXE is a function which takes error as input. Radio button were use to
represent three option of error value. The GainXE will be calculated and displayed
when any of the error value selected.
Angle is a function to find the value of the Lower Angle and Upper Angle.
These angles depend on the value of Angle phase uncertainty. The Upper and Lower
angle will be displayed and be used to find K2.
Function K2 is depending on input of Lower angle, Upper angle and Gain XE.
The K2 will be use for calculation of P1 and P2.
P1 are to calculate value of P1 from the value of K2 and radar characteristic.
The radar characteristic such Power Transmit, Radar Cross Section (RCS) and range
will be calculated to find the value of Power Skin. The Power Skin will depend on K2
to find the Power 1.
P2 can be calculated from the value of P1 and K2. Detailed calculation on P1
and P2 can be referred to example in Chapter 3. Source code for this module is in the
Appendix F and G. The flow chart is in Figure 4.12.
41
Start
Change and key in
parameter
Error, Angle, Power
Tx, RCS and Range
GainXE = 2 * Error;
Lower Angle =
180 -Angle
Upper Angle =
180 +Angle
break
.
.
.
.
.
.
.
.
.
break
break
if(GainXE && Angle)
= Condition 1
.
.
.
.
.
.
.
.
if(GainXE && Angle)
= Condition 9
break
if(Range != 0)
= Formula Skin
break
if(KSquare != 0)
= Formula Power1
42
break
break
if(Power1 != 0)
= Formula Power2
if(KSquare == 0)
KSquare= Not Relevan
else
KSquare = KSquare;
Display
Result
End
Figure 4.12: Flow Chart for Simulation of Simulation Cross Eye Jamming Training
As the entire component already placed on the form and the relationship between
them has been laid out in the flow chart. It helps in generation code for function and
handler for this program.
The interesting about object oriented programming is that, the module can be
developed independently and experimentally before being fully combined. Here, all
of the modules were developed independently. Even the sub-module has also been
developed independently. It also can be experiment by using normal C++ compiler to
see the function works, this helps to make sure it works before being combined with
others.
43
4.4
Testing
Most of the component has been tested at component level, this shows that it
practice the white box testing through all the component of the system. Component
test involves all possibilities the component could contribute to defect. For example
the Edit Text is for AnsiString but it also use for numerical value. The cases like
variable type such integer, double and others require to be valid before operation, the
test for this is done from time to time while developing the program.
The flow chart also used to test the system. It helps to test component test,
path test and integration test. As this project involves such flow chart (Fig 4.10, 4.11
and 4.11), the testing is done for all paths.
The expected result has been calculated and lay out to be compared with the
simulation result.
The test plans for this project are as follows:
(i)
Test component possible error.
(ii)
Test function.
(iii)
Test system of a module.
(iv)
Test module with calculated data for comparison.
(v)
Test system integration with all modules.
Test Component Possible Error, for example Edit Text which be used to
receive integer or float. The Edit Text must be validated whether able to function as
required by the requirement analysis. Other than that the possible type of input to the
Edit Text also must be taken care of before proceed to the next level of
programming. Each component was observed their possible error and also when
integrates with other component.
Test Function, the function design was tested with the data to see whether it
works as required. The function was also tested with other function it interfaces with.
Some of the functions are tested by using normal C++ compiler independently, just
44
to see the response on that function. For example if the function involves iteration,
the iteration part can be simulated independently on C++ compiler to see the
response.
Test System of a Module, when the modules are ready, it was tested whether
it is working well or not. Module also tested with test data to see the result and
compare with expected result.
Test Module with Calculated Data, wrong possible data is also calculated
manually to be tested by the module. This is to find whether it could detect the error
or not. For example the Edit Text in module Burnthrough Range Training Aid is
keyed in with negative number and the response are used to update the function to
handle such situation.
Test system integration with all modules, the entire modules are combined
and run. The result helps in updating the function inside the module. For example the
value calculated in Burnthrough Range Training Aid found that it should reset all
variable value when exit the module. From the test, the result which does not reset
will make the module showing the wrong answer when being run again after quitting
at the first time. Below are test data to test the program.
Radar
Power
Transmit
(kW)
Antenna
Gain
(dB)
Radar
Cross
Section
(m2)
1
2
3
4
5
6
7
1000
850
700
800
900
1508
1000
40
32
45
34
34
39.5
41
5
4
6
5
5
1
7
Table 4.1: Radar Test Data for Simulation of ECM Radar Evaluation Module and
Burnthrough Range Training Aid Module.
45
Jammer
Power
Transmit
(W)
Antenna
Gain
(dB)
1
2
3
4
5
6
7
200
180
150
250
300
163
170
6
5
7
4
5
6
4
Table 4.2: Jammer Test Data for Simulation of ECM Radar Evaluation Module and
Burnthrough Range Training Aid Module.
Jammer
Radar
1
2
3
4
5
6
7
1
2.24
2.64
2.30
2.52
2.05
2.48
3.05
2
0.73
0.87
0.76
0.83
0.67
0.81
1.00
3
3.64
4.39
3.75
4.10
3.34
4.04
4.98
4
1.00
1.19
1.03
1.13
0.92
1.11
1.37
5
1.06
1.26
1.09
1.20
0.97
1.18
1.45
6
1.16
1.37
1.19
1.31
1.06
1.28
1.58
7
2.57
3.51
3.05
3.34
2.72
3.29
4.05
(Burnthrough Range Result in kilometer)
Table 4.3: Expected Burnthrough Range Result for Simulation of ECM Radar
Evaluation Module and Burnthrough Range Training Aid Module Using Data in
Table 4.1 and Table 4.2.
46
Error = 2L, Angle
Case 1
Case 2
Case 3
Power
50,000
100,000
150,000
Cross
5
10
15
Range (km)
15
30
45
GainXE (dB)
4
4
4
Lower Angle (o)
165
165
165
Upper Angle (o)
195
195
195
K2
0.7
0.7
0.7
Power 1
3.3141
0.3314
0.3314
Power 2
2.3199
0.2320
0.2320
uncertainty = 15o
Transmit
(kw)
Radar
Section (m2)
Table 4.4: Expected Result for Cross Eye Jamming Configuration of 2L Error and
15o Uncertainty Phase Angle.
-Power Transmit =
100,000 kW,
-Radar Cross
Section = 10 m2
-Range = 30 km
Error (L)
Case 1
Case 2
Case 3
2
3
4
5
15
20
4
6
8
Lower Angle (o)
175
170
160
Upper Angle (o)
185
190
200
K2
0.5
0.8
Not Relevan
Power 1
1.0307
7.9331
7.9331
Power 2
0.5153
6.3465
0.0000
Angle of phase
o
uncertainty ( )
GainXE (dB)
Table 4.5: Expected Result for Cross Eye Jamming Configuration of 100,000kW
Power Transmit, 10 m2 Radar Cross Section and 15o Angle of Phase Uncertainty.
CHAPTER 5
RESULT AND DISCUSSION
The objective of the project is to have a simulation system for ECM Radar
which will be used for evaluation and training. The results are presented here to show
whether it meets the objectives of the project.
5.1
Result for ECM Radar Evaluation Module
Figure 5.1 has shown the interface of first module, which is ECM Radar
Evaluation Module. Here, we can see the combo box has given the user opportunity
to choose easily the radar or jammer they wish to evaluate. Then the edit text boxes
are function to display the value of specification of radar or jammer chosen
respectively. The memo text pad will give the user the ability to read the analysis and
the recommendation resulted from burnthrough range value. User can choose to go to
next module by two buttons below or remain in main module for evaluation
48
Button for
next
module
Figure 5.1: Display of Main Module ECM Radar Evaluation
ComboBox
to select
jammer
Parameter
display
after radar
selected
Figure 5.2: Display on Main Module for Selecting Radar and Jammer.
Figure 5.2 shows how the radar can be selected by the combo box. Then the
system will display the specification of the radar and jammer that has been selected.
Figure 5.3 shows burnthrough range button, result, analysis and recommendation.
49
Rt button
for Rt
calculation
function
Result of
Rt
Analysis and
recommenda
-tion
Figure 5.3: Display of Main Module Showing Burnthrough Range Button, Result,
Analysis and Recommendation.
Jammer
Radar
1
2
3
4
5
6
7
1
2.24
2.64
2.30
2.52
2.05
2.48
3.05
2
0.73
0.87
0.76
0.83
0.67
0.81
1.00
3
3.64
4.39
3.75
4.10
3.34
4.04
4.98
4
1.00
1.19
1.03
1.13
0.92
1.11
1.37
5
1.06
1.26
1.09
1.20
0.97
1.18
1.45
6
1.16
1.37
1.19
1.31
1.06
1.28
1.58
7
2.57
3.51
3.05
3.34
2.72
3.29
4.05
Table 5.1: Result From ECM Radar Evaluation Module
50
5.2
Result for Burnthrough Range Training Aid Module
Table 5.1 shows result of burnthrough range for seven radar and jammer
inside the system database. The result is the same as the test data calculated manually
in the previous chapter.
Figure 5.4: Display of Burnthrough Range Training Aid Module
Figure 5.4 shows six edit text boxes and six scroll bars. It is all for the user to
change the value of parameter as they wish to see the result. This is giving chance to
the user to see the result of the burnthrough range and the response on the bar graph
below. This will give an impact in terms of how the formula behind burnthrough
range works.
51
Figure 5.5: Display of Burnthrough Range Training Aid Module with An Example
Calculation.
Figure 5.5 shows result calculation of burnthrough range 2.24 km which is
true compare to test data. Table 5.2 shows result of burnthrough range, which are
correct compare to test data on simulation for ECM Radar Evaluation Module. User
can change parameter value by edit box or sliding bar. The module will be reset to
default values when the user returns to main module.
Jammer
Radar
1
2
3
4
5
6
7
1
2.24
2.64
2.30
2.52
2.05
2.48
3.05
2
0.73
0.87
0.76
0.83
0.67
0.81
1.00
3
3.64
4.39
3.75
4.10
3.34
4.04
4.98
4
1.00
1.19
1.03
1.13
0.92
1.11
1.37
5
1.06
1.26
1.09
1.20
0.97
1.18
1.45
6
1.16
1.37
1.19
1.31
1.06
1.28
1.58
7
2.57
3.51
3.05
3.34
2.72
3.29
4.05
Table 5.2: Result From Burnthrough Range Training Aid Module.
52
5.3
Result for Cross Eye Jamming Training Aid Module
Edit text
box
Radio button
Figure 5.6: Display of Cross Eye Jamming Training Aid Module
Figure 5.6, it shows the interface of all parameters for cross eye jamming.
These parameters are represented in radio button and edit text box. The user can
choose the value to calculate and to key in the specification of the radar. The result
will show the GainXE, lower angle, upper angle, Power 1 and Power 2. These are
useful to prove the calculation on cross eye jamming.
Figure 5.7: Display of Cross Eye Jamming Training Aid Module with An Example
Calculation.
53
Figure 5.7 shows result of cross eye jamming configuration, which is same as
test data.
Result of
wrong
configuration
Figure 5.8: Display of Cross Eye Jamming Training Aid Module with An Example
Wrong Configuration.
Figure 5.8 shows how wrong configuration will be displayed. The cross eye
jamming cannot be implemented with such configuration above.
Error = 2L, Angle
Case 1
Case 2
Case 3
Power
50,000
100,000
150,000
Cross
5
10
15
Range (km)
15
30
45
GainXE (dB)
4
4
4
Lower Angle (o)
165
165
165
Upper Angle (o)
195
195
195
KSquare
0.7
0.7
0.7
Power 1
3.3141
0.3314
0.3314
Power 2
2.3199
0.2320
0.2320
uncertainty = 15o
Transmit
(kw)
Radar
Section (m2)
Table 5.3: Result for Cross Eye Jamming Training Aid Module with Configuration
of 2L Error and 15o Uncertainty Phase Angle.
54
-Power Transmit =
100,000 kW,
-Radar Cross
Section = 10 m2
-Range = 30 km
Error (L)
Case 1
Case 2
Case 3
2
3
4
5
15
20
4
6
8
175
170
160
Upper Angle ( )
185
190
200
KSquare
0.5
0.8
Not Relevan
Power 1
1.0307
7.9331
7.9331
Power 2
0.5153
6.3465
0.0000
Angle of phase
uncertainty (o)
GainXE (dB)
Lower Angle (o)
o
Table 5.4: Result for Cross Eye Jamming Training Aid Module Configuration of
100,000kW Power Transmit, 10 m2 Radar Cross Section and 15o Angle of Phase
Uncertainty.
Table 5.3 and 5.4 shows the result of cross eye jamming training aid. The
result show that all three module archive the right result compare to manual
calculation. It means that the formula that has been program is functionally correctly.
Military personnel can utilize the simulation for equipment evaluation by
using this simulation. The theory for burnthrough range and cross eye jamming now
is easy to learn with the help of this simulation.
This project was developed, using the object oriented methodology which
involves UML. The source code for this project was developed by using object
oriented methodology with the tools of UML. The simulation succeeds to work as it
required and it is done by the help of the methodology used.
Systematic approach, incremental development/testing and clear notation of
documentation really help in the development of this project. The methodologies
used are able to give the developer chance to design a software better compare to
traditional way of developing software. Borland C++ Builder (BCB) also helps in
55
developing the simulation by using object oriented methodology, it is because BCB
present component as an object.
58
LIST OF REFERENCES
1. Joint Staff, “DoD dictionary of military terms,” Joint Electronic Library,
<http://www.dtic.mil/doctrine/jel/doddict/> Feb 15, 2001.
2. DAVID ADAMY, Introduction to Electronic Warfare Modeling and
Simulation, Artech House Inc., Norwood, 2003.
3. HOLLENBACH J and MISCH G, “Linking C4I and modeling and simulation
systems,” IEEE Military Communications Conference, pp. 1126-1128, USA,
1995.
4. CHARLES HARRELL, “Process Simulation vs. System Simulation”,
Promodel Corporation Utah 1998.
5. DDEMBE WILLIAMS and MICHAEL KENNEDY, “Component-Based
Modeling and Simulation: A Case for Simulation Software Architecture”
South Bank University, UK, 1998.
6. IAN SOMMERVILLE, Software Engineering, Addison Wesley, Edinburgh,
2004.
7. MARK PRIESTLEY, Practical Object-Oriented Design With UML, McGraw
Hill Education, Bershire, 2003.
8. MOHAMMAD S. AL –AQRABAWI, Modeling Large-Scale Software and
Hardware Application Using UML, Master Thesis of Virginia Polytechnic
Institute and State University, Blacksburg, Virginia May 2001.
59
9. DAVID ADAMY, EW 101 A First Course in Electronic Warfare, Artech
House Inc., Norwood, 2001.
10. ELI BROOKNER, Radar Technology, Artech House Inc., Massachusetts,
1977.
11. MERRILL I. SKOLNIK, Introduction to Radar Systems, McGraw Hill Book
Company, Singapore, 2001.
12. RICHARD J. WIEGAND, Radar Electronic Countermeasures System
Design, Artech House Inc., Norwood, 1991.
13. FILIPPO NERI, Introduction to Electronic Defence Systems, Artech House
Inc., Norwood, 2001.
14. HANS VAN VLIET, Software Engineering, John Wiley and Sons Ltd.,
Chichester, 2000.
15. Example of thesis,
http://www.ittc.ku.edu/research/thesis/index.php?sort=lname.
16. JIM MISCHEL, JEFF DUNTEMANN, Borland C++ Builder Programming
Explorer, Corolis Group Inc., Scottsdale, 1997.
17. D. CURTIS SCHLEHER, Introduction to Electronic Warfare, Artech House
Inc., Dedham, 1986.
60
Appendix A: File 1.h
#ifndef FILE1_H
#define FILE1_H
//-----------------------------variable------------------------------------struct Ant
{
char* nama;
double pow, gain, rcs;
}A, A_new;
//instantaneous
//----------------------------radar class----------------------------------class Radar
{
Ant A;
public:
void key_in(var A_new){A = A_new;}
Ant key_out(){return A;}
}Rdata;
//instantaneous
//---------------------------jammer class-----------------------------------class Jammer
{
Ant A;
public:
void key_in(var A_new){A = A_new;}
Ant key_out(){return A;}
}Jdata;
//instantaneous
#endif
61
Appendix B: Main.h
//$$---- Form HDR ---//--------------------------------------------------------------------------#ifndef MainH
#define MainH
//--------------------------------------------------------------------------#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>
#include <ComCtrls.hpp>
#include <ExtCtrls.hpp>
#include <vector.h>
#include "File1.h"
#include <Dialogs.hpp>
#include <Graphics.hpp>
//--------------------------------------------------------------------------class TForm1 : public TForm
{
__published: // IDE-managed Components
TPanel *Panel1;
TLabel *Label1;
TLabel *Label2;
TComboBox *ComboBox1;
TEdit *Edit1;
TEdit *Edit2;
TEdit *Edit3;
TLabel *Label3;
TLabel *Label4;
TLabel *Label5;
TLabel *Label6;
TComboBox *ComboBox2;
TEdit *Edit4;
TEdit *Edit5;
TLabel *Label7;
TLabel *Label8;
TButton *Button1;
TEdit *Edit6;
TLabel *Label9;
TRichEdit *RichEdit1;
TPanel *Panel2;
TRadioButton *RadioButton1;
TRadioButton *RadioButton2;
TButton *Button2;
TLabel *Label10;
TLabel *Label11;
TRichEdit *RichEdit3;
TOpenDialog *OpenDialog1;
62
TOpenDialog *OpenDialog2;
TLabel *Label12;
TPanel *Panel3;
TShape *Shape1;
TShape *Shape2;
TShape *Shape3;
TPanel *Panel4;
TPanel *Panel5;
TRichEdit *RichEdit2;
TImage *Image2;
TImage *Image1;
TButton *Button3;
void __fastcall ComboBox1Change(TObject *Sender);
void __fastcall FormCreate(TObject *Sender);
void __fastcall ComboBox2Change(TObject *Sender);
void __fastcall Button1Click(TObject *Sender);
void __fastcall Button2Click(TObject *Sender);
void __fastcall Edit6Change(TObject *Sender);
void __fastcall Button3Click(TObject *Sender);
private:
// User declarations
public:
// User declarations
__fastcall TForm1(TComponent* Owner);
};
//--------------------------------------------------------------------------extern PACKAGE TForm1 *Form1;
//--------------------------------------------------------------------------#endif
63
Appendix C: Main.cpp
//$$---- Form CPP ---//--------------------------------------------------------------------------#include <vcl.h>
#include <fstream.h>
#include <math.h>
#pragma hdrstop
#include "Main.h"
#include "Unit2.h"
#include "Unit3.h"
//--------------------------------------------------------------------------#pragma package(smart_init)
#pragma resource "*.dfm"
TForm1 *Form1;
//--------------------------------------------------------------------------__fastcall TForm1::TForm1(TComponent* Owner)
: TForm(Owner)
{
}
//--------------------------------------------------------------------------//--------------------------Initialization----------------------------------vector<Radar> RDis;
vector<Jammer> JDis;
//array of radar
//array of jammer
AnsiString cy,cz,cv,cf,cg,ch;
//Analysis & comment line
//---------directory of radar and jammer database file----------------------char const *pathr = "C:\\Radar ECM Simulation\\Radar.TXT";
char const *pathj = "C:\\Radar ECM Simulation\\Jammer.TXT";
//--------------------------------------------------------------------------//--------------------variable----------------------------------------------int v,w,size_radar;
int atm = 1;
double Rp, Rg, Rcs, Jp, Jg, Rt;
//---------------------------------------Function---------------------------//---------------------------------------load radar-------------------------void load_radar(void)
{
RDis.clear();
//clear vector display
64
A_new.nama = new char[20];
// memory allocation for A_new.nama
Form1->ComboBox1->Items->Clear(); // clear combobox1
Form1->RichEdit2->Lines->LoadFromFile(pathr); //load from radar file
v = Form1->RichEdit2->Lines->Count;
//get how many line in the
//file
Form1->OpenDialog1->FileName = pathr;
//open file to put in vector
ifstream infile(Form1->OpenDialog1->FileName.c_str());//retrieve from file
for(int i = 0; i < v; i++){
infile >> A_new.nama;
//retrieve variable nama
infile >> A_new.pow;
//retrieve variable power
infile >> A_new.gain;
//retrieve variable gain
infile >> A_new.rcs;
//retrieve variable RCS
Rdata.key_in(A_new);
//load in array of radar
RDis.insert(RDis.begin(),Rdata); //for display and calculation
Form1->ComboBox1->Items->Add(A_new.nama); //Load name in
combobox
}
infile.close();
//close ifstream
}
//--------------------------------------display data radar-------------void data_radar()
{
Rdata = RDis.at(v - 1 - Form1->ComboBox1->ItemIndex); //get data position
A = Rdata.key_out();
//retrieve from Radar A
Form1->Edit1->Text = A.pow;
//display power
Form1->Edit2->Text = A.gain;
//display gain
Form1->Edit3->Text = A.rcs;
//display RCS
}
//---------------------------------------load jammer-------------------void load_jammer(void)
{
JDis.clear();
//clear vector display
A_new.nama = new char[20];
// memory allocation for A_new.nama
Form1->ComboBox2->Items->Clear(); // clear combobox1
Form1->RichEdit3->Lines->LoadFromFile(pathj); //load from radar file
w = Form1->RichEdit3->Lines->Count; //get how many line in the file
Form1->OpenDialog2->FileName = pathj;
//open file to put in vector
ifstream infile(Form1->OpenDialog2->FileName.c_str());//retrieve from file
for(int i = 0; i < w; i++){
infile >> A_new.nama;
//display variable nama
infile >> A_new.pow;
//display variable power
65
infile >> A_new.gain;
//display variable gain
Jdata.key_in(A_new);
//load in array jammer
JDis.insert(JDis.begin(),Jdata); //for display and calculation
Form1->ComboBox2->Items->Add(A_new.nama); //Load name in
combobox
}
infile.close();
//close ifstream
}
//-------------------------------------display data jammer--------------void data_jammer()
{
Jdata = JDis.at(w - 1 - Form1->ComboBox2->ItemIndex); //get data position
A = Jdata.key_out();
//retrive from Jammer A
Form1->Edit4->Text = A.pow;
//display power
Form1->Edit5->Text = A.gain;
//display gain
}
//------------------------------------------RT variable----------------------double calculate()
{
Rp = Form1->Edit1->Text.ToDouble() * 1000;
//value for Rp
Rg = pow(10, ((Form1->Edit2->Text.ToDouble() )/10)); //value for Rg
Rcs = Form1->Edit3->Text.ToDouble();
//value for RCS
Jp = Form1->Edit4->Text.ToDouble();
//value for Jp
Jg = pow(10, ((Form1->Edit5->Text.ToDouble())/10)); //value for Jg
Rt = (sqrt((Rp * Rg * Rcs)/(Jp * Jg * atm * 4 * M_PI)))/1000;//Rt formula
return Rt;
}
//------------------------------------Analysis and recommendation-----void comment()
{
double x = Form1->Edit6->Text.ToDouble(); //get value from Rt
cy = "Burnthrough range is more than 3 km then the radar having";
cz = "quite enough time to response if enemy launch an attack, but";
cv = "still need to prepare with Electronic Protection Measure";
cf = "Burnthrough range is less than 3 km then the radar having";
cg = "not enough time to response if enemy launch an attack, this";
ch = "definitely need to prepare with Electronic Protection Measure";
66
if(x > 3){
//if Rt more than 3 km
Form1->RichEdit1->Lines->Clear(); //clear text
Form1->RichEdit1->Lines->Add(cy);
//display lines
Form1->RichEdit1->Lines->Add(cz);
//display lines
Form1->RichEdit1->Lines->Add(cv);
//display lines
}
else if(x < 3){
//if Rt less than 3 km
Form1->RichEdit1->Lines->Clear(); //clear text
Form1->RichEdit1->Lines->Add(cf);
//display lines
Form1->RichEdit1->Lines->Add(cg);
//display lines
Form1->RichEdit1->Lines->Add(ch);
//display lines
}
}
//-------------------------------------------Handler-------------------------void __fastcall TForm1::ComboBox1Change(TObject *Sender)
{
data_radar();
}
//--------------------------------------------------------------------------void __fastcall TForm1::FormCreate(TObject *Sender)
{
load_radar();
load_jammer();
}
//--------------------------------------------------------------------------void __fastcall TForm1::ComboBox2Change(TObject *Sender)
{
data_jammer();
}
//--------------------------------------------------------------------------void __fastcall TForm1::Button1Click(TObject *Sender)
{
calculate();
Edit6->Text = Edit6->Text.sprintf("%.2f",Rt);
}
//--------------------------------------------------------------------------void __fastcall TForm1::Button2Click(TObject *Sender)
{
Form2->Show();
}
//--------------------------------------------------------------------------void __fastcall TForm1::Edit6Change(TObject *Sender)
{
comment();
}
//--------------------------------------------------------------------------void __fastcall TForm1::Button3Click(TObject *Sender)
67
{
Close();
}
//--------------------------------------------------------------------------void __fastcall TForm1::Button4Click(TObject *Sender)
{
Form3->Show();
}
//---------------------------------------------------------------------------
68
Appendix D: Unit2.h
//$$---- Form HDR ---//--------------------------------------------------------------------------#ifndef Unit2H
#define Unit2H
//--------------------------------------------------------------------------#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>
#include <ExtCtrls.hpp>
#include <Graphics.hpp>
//--------------------------------------------------------------------------class TForm2 : public TForm
{
__published: // IDE-managed Components
TGroupBox *GroupBox1;
TLabel *Label1;
TLabel *Label2;
TLabel *Label3;
TLabel *Label4;
TLabel *Label5;
TEdit *edtRpt;
TEdit *edtRag;
TEdit *edtRcs;
TEdit *edtJpt;
TEdit *edtJag;
TLabel *Label6;
TEdit *edtAtm;
TScrollBar *scrRpt;
TScrollBar *scrRag;
TScrollBar *scrRcs;
TScrollBar *scrJpt;
TScrollBar *scrJag;
TScrollBar *scrAtm;
TGroupBox *GroupBox2;
TEdit *edtRt;
TLabel *Label7;
TShape *Shape1;
TLabel *Label8;
TLabel *Label9;
TLabel *Label10;
TLabel *Label11;
TLabel *Label12;
TLabel *Label13;
TButton *Button1;
TShape *Shape3;
TPanel *Panel5;
69
TShape *Shape2;
TPanel *Panel4;
TImage *Image2;
TImage *Image1;
void __fastcall edtRptChange(TObject *Sender);
void __fastcall edtRagChange(TObject *Sender);
void __fastcall edtRcsChange(TObject *Sender);
void __fastcall edtJptChange(TObject *Sender);
void __fastcall edtJagChange(TObject *Sender);
void __fastcall edtAtmChange(TObject *Sender);
void __fastcall scrRptChange(TObject *Sender);
void __fastcall scrRagChange(TObject *Sender);
void __fastcall scrRcsChange(TObject *Sender);
void __fastcall scrJptChange(TObject *Sender);
void __fastcall scrJagChange(TObject *Sender);
void __fastcall scrAtmChange(TObject *Sender);
void __fastcall edtRtChange(TObject *Sender);
void __fastcall edtRptKeyPress(TObject *Sender, char &Key);
void __fastcall edtRagKeyPress(TObject *Sender, char &Key);
void __fastcall edtRcsKeyPress(TObject *Sender, char &Key);
void __fastcall edtJptKeyPress(TObject *Sender, char &Key);
void __fastcall edtJagKeyPress(TObject *Sender, char &Key);
void __fastcall edtAtmKeyPress(TObject *Sender, char &Key);
void __fastcall FormActivate(TObject *Sender);
void __fastcall Button1Click(TObject *Sender);
private: // User declarations
public:
// User declarations
__fastcall TForm2(TComponent* Owner);
};
//--------------------------------------------------------------------------extern PACKAGE TForm2 *Form2;
//--------------------------------------------------------------------------#endif
70
Appendix E: Unit2.cpp
//$$---- Form CPP ---//--------------------------------------------------------------------------#include <vcl.h>
#include<math.h>
#pragma hdrstop
//for math calculation
#include "Unit2.h"
//--------------------------------------------------------------------------#pragma package(smart_init)
#pragma resource "*.dfm"
TForm2 *Form2;
//--------------------------------------------------------------------------__fastcall TForm2::TForm2(TComponent* Owner)
: TForm(Owner)
{
}
//-------------------------------Initialiazation----------------------------double Rt, Rp, Rg, Rcs, Jp, Jg, atm;
//variable for Rt
//-------------------------------Function-----------------------------------void activate(void)
//initialization value when activate
{
Jp = 1;
Jg = 1;
atm = 1;
Rt = (sqrt((1000*Rp * Rg * Rcs) / (Jp * Jg * atm * 4 * M_PI)))/1000;
Form2->edtRt->Text = Rt;
}
//------------------------------Rp Change-------------------------------void RpChange()
//calculate Rt when Rp change
{
if( Form2->edtRpt->Text.IsEmpty() )
Form2->edtRpt->Text = IntToStr(0);
else if( Form2->edtRpt->Text.ToInt() > 1000 )
Form2->edtRpt->Text = 1000;
Form2->scrRpt->Position = Form2->edtRpt->Text.ToDouble();
Rp = Form2->edtRpt->Text.ToDouble();
Rt = (sqrt((1000*Rp * Rg * Rcs) / (Jp * Jg * atm * 4 * M_PI)))/1000;
Form2->edtRt->Text = Rt;
}
71
//------------------------------Rag Change-------------------------------void RagChange()
//calculate Rt when Rag change
{
if( Form2->edtRag->Text.IsEmpty() )
Form2->edtRag->Text = IntToStr(0);
else if( Form2->edtRag->Text.ToInt() > 1000 )
Form2->edtRag->Text = 1000;
Form2->scrRag->Position = Form2->edtRag->Text.ToDouble();
Rg = pow(10, ((Form2->edtRag->Text.ToDouble() )/10));
Rt = (sqrt((1000*Rp * Rg * Rcs) / (Jp * Jg * atm * 4 * M_PI)))/1000;
Form2->edtRt->Text = Rt;
}
//------------------------RCS change------------------------------------void RcsChange()
//calculate Rt when Rcs change
{
if( Form2->edtRcs->Text.IsEmpty() )
Form2->edtRcs->Text = IntToStr(0);
else if( Form2->edtRcs->Text.ToInt() > 1000 )
Form2->edtRcs->Text = 1000;
Form2->scrRcs->Position = Form2->edtRcs->Text.ToDouble();
Rcs = Form2->edtRcs->Text.ToDouble();
Rt = (sqrt((1000*Rp * Rg * Rcs) / (Jp * Jg * atm * 4 * M_PI)))/1000;
Form2->edtRt->Text = Rt;
}
//-------------------------Jpt change-------------------------------------void JpChange()
//calculate Rt when Jp change
{
if( Form2->edtJpt->Text.IsEmpty() )
Form2->edtJpt->Text = IntToStr(1);
else if( Form2->edtJpt->Text.ToInt() > 1000 )
Form2->edtJpt->Text = 1000;
Form2->scrJpt->Position = Form2->edtJpt->Text.ToDouble();
Jp = Form2->edtJpt->Text.ToDouble();
Rt = (sqrt((1000*Rp * Rg * Rcs) / (Jp * Jg * atm * 4 * M_PI)))/1000;
Form2->edtRt->Text = Rt;
}
//-----------------------------Jag change-----------------------------------
72
void JagChange()
//calculate Rt when Jag change
{
if( Form2->edtJag->Text.IsEmpty() )
Form2->edtJag->Text = IntToStr(0);
else if( Form2->edtJag->Text.ToInt() > 1000 )
Form2->edtJag->Text = 1000;
Form2->scrJag->Position = Form2->edtJag->Text.ToDouble();
Jg = pow(10, ((Form2->edtJag->Text.ToDouble())/10));
Rt = (sqrt((1000*Rp * Rg * Rcs) / (Jp * Jg * atm * 4 * M_PI)))/1000;
Form2->edtRt->Text = Rt;
}
//------------------------------Atm change---------------------------------void AtmChange()
//calculate Rt when Atm change
{
if( Form2->edtAtm->Text.IsEmpty() )
Form2->edtAtm->Text = IntToStr(0);
else if( Form2->edtAtm->Text.ToInt() > 1000 )
Form2->edtAtm->Text = 1000;
Form2->scrAtm->Position = Form2->edtAtm->Text.ToDouble();
atm = pow(10, ((Form2->edtAtm->Text.ToDouble())/10));
Rt = (sqrt((1000*Rp * Rg * Rcs) / (Jp * Jg * atm * 4 * M_PI)))/1000;
Form2->edtRt->Text = Rt;
}
//---------------------------Exit function----------------------------------void Exit()
{
//exit and reset value
Form2->scrRpt->Position = 0;
Form2->scrRag->Position = 0;
Form2->scrRcs->Position = 0;
Jp = 1;
Jg = 1;
atm = 1;
Form2->scrJpt->Position = 1;
Form2->scrJag->Position = 0;
Form2->scrAtm->Position = 0;
Form2->Close();
}
//---------------------------Handler----------------------------------------void __fastcall TForm2::edtRptChange(TObject *Sender)
73
{
RpChange();
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtRagChange(TObject *Sender)
{
RagChange();
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtRcsChange(TObject *Sender)
{
RcsChange();
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtJptChange(TObject *Sender)
{
JpChange();
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtJagChange(TObject *Sender)
{
JagChange();
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtAtmChange(TObject *Sender)
{
AtmChange();
}
//--------------------------------------------------------------------------void __fastcall TForm2::scrRptChange(TObject *Sender)
{
edtRpt->Text = scrRpt->Position;
}
//--------------------------------------------------------------------------void __fastcall TForm2::scrRagChange(TObject *Sender)
{
edtRag->Text = scrRag->Position;
}
//--------------------------------------------------------------------------void __fastcall TForm2::scrRcsChange(TObject *Sender)
{
edtRcs->Text = scrRcs->Position;
}
//--------------------------------------------------------------------------void __fastcall TForm2::scrJptChange(TObject *Sender)
{
edtJpt->Text = scrJpt->Position;
}
//--------------------------------------------------------------------------void __fastcall TForm2::scrJagChange(TObject *Sender)
74
{
edtJag->Text = scrJag->Position;
}
//--------------------------------------------------------------------------void __fastcall TForm2::scrAtmChange(TObject *Sender)
{
edtAtm->Text = scrAtm->Position;
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtRtChange(TObject *Sender)
{
edtRt->Text = edtRt->Text.sprintf("%.2f",Rt);
Shape1->Width = Rt * 2.36;
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtRptKeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure key in only number
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtRagKeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure key in only number
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//---------------------------------------------------------------------------
75
void __fastcall TForm2::edtRcsKeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure key in only number
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtJptKeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure key in only number
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//--------------------------------------------------------------------------void __fastcall TForm2::edtJagKeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure key in only number
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
76
//--------------------------------------------------------------------------void __fastcall TForm2::edtAtmKeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure key in only number
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//--------------------------------------------------------------------------void __fastcall TForm2::FormActivate(TObject *Sender)
{
activate();
}
//--------------------------------------------------------------------------void __fastcall TForm2::Button1Click(TObject *Sender)
{
Exit();
}
//---------------------------------------------------------------------------
77
Appendix F: Unit3.h
//$$---- Form HDR ---//--------------------------------------------------------------------------#ifndef Unit3H
#define Unit3H
//--------------------------------------------------------------------------#include <Classes.hpp>
#include <Controls.hpp>
#include <StdCtrls.hpp>
#include <Forms.hpp>
#include <ExtCtrls.hpp>
#include <Graphics.hpp>
//--------------------------------------------------------------------------class TForm3 : public TForm
{
__published: // IDE-managed Components
TGroupBox *GroupBox1;
TRadioButton *RadioButton1;
TRadioButton *RadioButton2;
TRadioButton *RadioButton3;
TGroupBox *GroupBox2;
TRadioButton *RadioButton4;
TRadioButton *RadioButton5;
TRadioButton *RadioButton6;
TRadioButton *RadioButton7;
TGroupBox *GroupBox3;
TLabel *Label1;
TEdit *Edit1;
TLabel *Label2;
TEdit *Edit2;
TLabel *Label3;
TEdit *Edit3;
TLabel *Label8;
TLabel *Label9;
TLabel *Label10;
TGroupBox *GroupBox4;
TLabel *Label16;
TLabel *Label17;
TLabel *Label18;
TLabel *Label4;
TLabel *Label5;
TLabel *Label6;
TLabel *Label7;
TLabel *Label12;
TLabel *Label13;
TLabel *Label14;
TLabel *Label15;
TLabel *Label19;
78
TLabel *Label20;
TLabel *Label21;
TLabel *Label22;
TPanel *Panel4;
TShape *Shape2;
TShape *Shape3;
TPanel *Panel5;
TButton *Button1;
TImage *Image1;
TImage *Image2;
TButton *Backbutton;
void __fastcall RadioButton1Click(TObject *Sender);
void __fastcall RadioButton2Click(TObject *Sender);
void __fastcall RadioButton3Click(TObject *Sender);
void __fastcall RadioButton4Click(TObject *Sender);
void __fastcall RadioButton5Click(TObject *Sender);
void __fastcall RadioButton6Click(TObject *Sender);
void __fastcall RadioButton7Click(TObject *Sender);
void __fastcall Edit1Change(TObject *Sender);
void __fastcall Edit2Change(TObject *Sender);
void __fastcall Edit3Change(TObject *Sender);
void __fastcall Edit1KeyPress(TObject *Sender, char &Key);
void __fastcall Edit2KeyPress(TObject *Sender, char &Key);
void __fastcall Edit3KeyPress(TObject *Sender, char &Key);
void __fastcall BackbuttonClick(TObject *Sender);
private: double GainCE, Error, Angle, LowAngle, UpperAngle, RPtx, Rcs, Range;
double KSquare, Power1, PSkin, Power2;
void __fastcall Calculate(); // User declarations
public:
// User declarations
__fastcall TForm3(TComponent* Owner);
};
//--------------------------------------------------------------------------extern PACKAGE TForm3 *Form3;
//--------------------------------------------------------------------------#endif
79
Appendix G: Unit3.cpp
//$$---- Form CPP ---//--------------------------------------------------------------------------#include <vcl.h>
#include <math.h>
#pragma hdrstop
#include "Unit3.h"
//--------------------------------------------------------------------------#pragma package(smart_init)
#pragma resource "*.dfm"
TForm3 *Form3;
//--------------------------------------------------------------------------__fastcall TForm3::TForm3(TComponent* Owner)
: TForm(Owner)
{
}
//----------------------------------Function Calculate-----------------------void __fastcall TForm3::Calculate()
{
GainCE = Error * 2;
LowAngle = 180 - Angle;
UpperAngle = 180 + Angle;
//formula for Gain Cross Eye
//low angle
//upper angle
//-----------------------------------conditional value-----------------------if(GainCE == 4 && Angle == 5)KSquare = 0.5;
if(GainCE == 6 && Angle == 5)KSquare = 0.9;
if(GainCE == 8 && Angle == 5)KSquare = 0.7;
//----------------------------------------------------------------------------if(GainCE == 4 && Angle == 10)KSquare = 0.9;
if(GainCE == 6 && Angle == 10)KSquare = 0.8;
if(GainCE == 8 && Angle == 10)KSquare = 0;
//----------------------------------------------------------------------------if(GainCE == 4 && Angle == 15)KSquare = 0.7;
if(GainCE == 6 && Angle == 15)KSquare = 0;
if(GainCE == 8 && Angle == 15)KSquare = 0;
//-----------------------------------------------------------------------------
80
if(GainCE == 4 && Angle == 20)KSquare = 0;
if(GainCE == 6 && Angle == 20)KSquare = 0;
if(GainCE == 8 && Angle == 20)KSquare = 0;
//----------------------------------------------------------------------------if(Range != 0)
PSkin = (RPtx * Rcs)/(4 * M_PI* pow(Range,2)); //formula Pskin
if(KSquare != 0)
Power1 = PSkin/pow((1-sqrt(KSquare)),2);
//value for Power1
if(Power1 != 0)
Power2 = Power1*KSquare;
//value for Power2
//----------------------------------------------------------------------------if(KSquare == 0)
Label15->Caption = "Not relevan";
else
Label15->Caption = KSquare;
Label13->Caption = GainCE;
Label5->Caption = LowAngle;
Label7->Caption = UpperAngle;
Label19->Caption = Label6->Caption.sprintf("%.4f",Power1);
Label20->Caption = Label7->Caption.sprintf("%.4f",Power2);
}
//------------------------------Handler---------------------------------------void __fastcall TForm3::RadioButton1Click(TObject *Sender)
{
Error = 2;
Calculate();
}
//--------------------------------------------------------------------------void __fastcall TForm3::RadioButton2Click(TObject *Sender)
{
Error = 3;
Calculate();
}
//--------------------------------------------------------------------------void __fastcall TForm3::RadioButton3Click(TObject *Sender)
{
Error = 4;
Calculate();
}
81
//--------------------------------------------------------------------------void __fastcall TForm3::RadioButton4Click(TObject *Sender)
{
Angle = 5;
Calculate();
}
//--------------------------------------------------------------------------void __fastcall TForm3::RadioButton5Click(TObject *Sender)
{
Angle = 10;
Calculate();
}
//--------------------------------------------------------------------------void __fastcall TForm3::RadioButton6Click(TObject *Sender)
{
Angle = 15;
Calculate();
}
//--------------------------------------------------------------------------void __fastcall TForm3::RadioButton7Click(TObject *Sender)
{
Angle = 20;
Calculate();
}
//--------------------------------------------------------------------------void __fastcall TForm3::Edit1Change(TObject *Sender)
{
if( Edit1->Text.IsEmpty() )
Edit1->Text = IntToStr(0);
RPtx = Edit1->Text.ToDouble()*1000; //RPtx variable
Calculate();
}
//--------------------------------------------------------------------------void __fastcall TForm3::Edit2Change(TObject *Sender)
{
if( Edit2->Text.IsEmpty() )
Edit2->Text = IntToStr(0);
Rcs = Edit2->Text.ToDouble();
Calculate();
//Rcs variable
}
//---------------------------------------------------------------------------
82
void __fastcall TForm3::Edit3Change(TObject *Sender)
{
if( Edit3->Text.IsEmpty() )
Edit3->Text = IntToStr(0);
Range = Edit3->Text.ToDouble()*1000;
Calculate();
//Range variable
}
//--------------------------------------------------------------------------void __fastcall TForm3::Edit1KeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure only number key in
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//--------------------------------------------------------------------------void __fastcall TForm3::Edit2KeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure only number key in
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//--------------------------------------------------------------------------void __fastcall TForm3::Edit3KeyPress(TObject *Sender, char &Key)
{
if( (Key != '0') &&
//to make sure only number key in
83
(Key != '1') &&
(Key != '2') &&
(Key != '3') &&
(Key != '4') &&
(Key != '5') &&
(Key != '6') &&
(Key != '7') &&
(Key != '8') &&
(Key != '9') &&
(Key != VK_DELETE) &&
(Key != VK_BACK) )
Key = '\0';
}
//--------------------------------------------------------------------------void __fastcall TForm3::BackbuttonClick(TObject *Sender)
{
Close();
}
//---------------------------------------------------------------------------