A Project Report on
Simulation Testbed for Evaluation of
Critical Software in Launch Sequence
Submitted in Partial fulfillment of the requirements for the award of
the degree of
Master of Technology
In
Software Engineering
Submitted by
Sreebal I S
Under the Esteemed Guidance of
Mr. Santhosh Kumar G
Lecturer
Dept. of Computer Science, CUSAT
DEPARTMENT OF COMPUTER SCIENCE,
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY,
KOCHI-682022, KERALA
JUNE 2008Page 2
Page 3

DEPARTMENT OF COMPUTER SCIENCE,
COCHIN UNIVERSITY OF SCIENCE AND TECHNOLOGY,
KOCHI-682022, KERALA
Certificate
It is hereby certified that the project work entitled " Simulation Testbed for
Evaluation of Critical Software in Launch Sequence" is a bonafide record
carried out by Vikram Sarabhai Space Centre, Thiruvananthapuram, in partial
fulfillment of the award of the degree of Master of Technology in Software
Engineering from Cochin University of Science and Technology during the
academic year 2007-2008.
Dr. K. Paulose Jacob
Mr. Santhosh Kumar G
Professor & Head of the Dept
Project Guide
Dept. of Computer Science
Lecturer
CUSAT
Dept of Computer Science
CUSATPage 4
Page 5

ACKNOWLEDGEMENT
This project has been done so far with the help and guidance of many. The
invisible hand of Almighty God has always led me during the entire phase of the project.
In VSSC, I would like to thank Dr. R. Vikraman Nair, GD, QRSG for giving me
permission to do the project. Next, I am grateful to Mr. E.S. Padmakumar, Sci/Eng SG,
Division Head, QDSS for giving me valuable suggestions and support throughout the
work even in report preparation.
I like to thank Mr. S. Sateesh Kumar, Sci/Eng SE, QDSS for guiding the project
with much patience and understanding. I express my sincere gratitude to him for
understanding me and guiding me always for my betterment.
I am pleased to Ms. Bindu Thomas, Sci/Eng SF, Section Head, QDSS for her
overwhelming support and guidance.
I am expressing my thanks to Ms. Karthika. S, Sci/Eng SC, QDSS for her
continuous support and assistance during the work. I remember the help given by the
entire QRSG team at this point.
In the department I am grateful to Mr. K. Paulose Jacob, Professor and Head of
Department of Computer Science, Cochin University of Science and Technology for his
support and encouragement. I am also thankful to Dr. Sumam Mary Idicula, Reader,
Department of Computer Science for her valuable advice and suggestions.
Last but not the least I am most thankful to my internal guide Mr. G. Santhosh
Kumar, Lecturer, Department of Computer Science, Cochin University of Science and
Technology for the guidance, help, support and encouragement given to me.
I am also thankful to all the staff in Department for their cooperation. I thank my
mother for her moral support and dedicated prayers. Finally I thank all my friends for
their support and help.Page 6
Page 7

ABSTRACT
The Critical Software carries out critical final activities preparing and testing the
launch vehicle culminating in the launch. This includes commands to set up the vehicle
sub systems for launch and real-time decisions based on status checking of specific
vehicle parameters. The logic is implemented across several computers providing specific
functionality as well as redundancy. This distributed real-time nature and Failure
Detection and Isolation capabilities add to the complexity of the software, making the
evaluation of software a challenging task.
The current method of evaluation is review and verification followed by a system
level testing. The verification process does not fully capture the temporal aspects of the
co-operating software and its constituent threads. The system level tests are limited in its
capability to simulate exact error conditions. Hence, a platform for software specific
evaluation is required to ensure dependability.
Being a mission critical software, a test methodology using simulation is
proposed to be set up for evaluating critical software along with the associated software
elements. This provides a framework to execute the checkout software as in Launch
configuration without the hardware interfaces. Then, the network and other internal
interfaces as in operational environment are to be established. All other interfaces should
be simulated in detail such that the software behaves as if the hardware was present.
These Simulators are to be designed with extensive failure Simulation
capabilities. Simulators are to be developed to cater to onboard processors, count down
timer, vehicle systems etc. Test Cases are to be generated to cover the entire spectrum of
functionalities.
The specific focus of this methodology is to identify the interaction between the
software specific elements and critical software being a real time system, both the
functional and temporal correctness have to be ascertained.Page 8
Page 9

CONTENTS
Certificate............................................................................................................................3
ACKNOWLEDGEMENT..................................................................................................5
LIST OF FIGURES ..........................................................................................................13
LIST OF ABBREVIATIONS...........................................................................................15
1. INTRODUCTION ..........................................................................................................1
1.1 SYSTEM UNDER TEST ............................................................................. 2
2. LITERATURE SURVEY...............................................................................................5
2.1 MISSION CRITICAL SOFTWARE............................................................ 5
2.1.1 CHARACTERISTICS OF MISSION CRITICAL SOFTWARE.......... 5
2.2 SOFTWARE TESTING ............................................................................... 6
2.2.1 TAXONOMY ........................................................................................ 7
2.2.2 STATIC TESTING................................................................................ 8
2.2.3 DYNAMIC TESTING........................................................................... 9
2.2.4 NEED FOR SIMULATION SOFTWARE TESTING.......................... 9
2.3 MIL STD 1553B......................................................................................... 11
2.3.1 BUS COMPONENTS.......................................................................... 12
2.4 SUMMARY OF SURVEY......................................................................... 12
3. CHECKOUT SYSTEM................................................................................................15
3.1 OVERVIEW ............................................................................................... 15
3.2 ACQUISITION CONSOLE ....................................................................... 17
3.2.1 INTERFACE 1 Chassis Configuration................................................ 20
3.2.2 COMMAND EXECUTION ................................................................ 20
3.2.3 ACQUISITION.................................................................................... 21
3.3 INTERFACE UNIT.................................................................................... 22
3.4 GOVERNING CONSOLE (GC)................................................................ 23
3.5 COORDINATORâ„¢S CONSOLE (CC) ....................................................... 24
4. SOFTWARE ENVIRONMENT...................................................................................27
4.1 INTIME....................................................................................................... 27
4.1. 1 INTIME SOFTWARE ARCHITECTURE......................................... 27
5. SERIAL DATA HANDLING UNIT SIMULATOR....................................................33
5.1 PRODUCT FUNCTIONS .......................................................................... 33
5.2 FUNCTIONAL MODULE DECOMPOSITION ....................................... 39
5.3 DESIGN DESCRIPTIONS......................................................................... 39Page 10

5.4 CLASS DIAGRAMS.................................................................................. 41
5.5 USE- CASE DIAGRAM ............................................................................ 44
5.6 SEQUENCE DIAGRAM............................................................................ 46
6. SIMULATION OF INTERFACE CARDS ..................................................................51
6.1. SIMULATION OF ADC CARD............................................................... 51
6.2. SIMULATION OF TTL AND OPTO CARD........................................... 56
6.3 SIMULATION OF RELAY CARD........................................................... 59
7.
RATIONAL REQUISITE PRO...............................................................................63
8. RATIONAL TEST REAL TIME ..................................................................... 65
9. ADVANTAGES ............................................................................................... 69
10. TEST CASES.................................................................................................. 71
11. TEST RESULTS............................................................................................. 73
12. CONCLUSION AND FUTURE WORK ....................................................... 75
13. REFERENCES ............................................................................................... 77Page 11
Page 12
Page 13

LIST OF FIGURES
Fig 1 : Block Diagram of Checkout System
26
Fig 2: Total environment of the system
28
Fig 3 : Role of AC
29
Fig 4: Basic Relay Communication
30
Fig 5: Governing Console
34
Fig 6: Coordinator's Console
35
Fig 7: Transport mechanism for NTX communication
38
Fig 8: Transferring control between Windows NT and INtime
39
Fig 9: INtime components
40
Fig 10: Position of SDU
44
Fig 11: Overall System Configuration
45
Fig 12: Functional Decomposition of SDU Simulator
49
Fig 13: Class Diagram of SDU
53
Fig 14: Use Case Diagram
56
Fig 15: Sequence Diagram For Command Reception
58
Fig 16: Sequence Diagram For Data Frame Transmission
59
Fig 17: High Speed Acquisition
63Page 14
Page 15

LIST OF ABBREVIATIONS
Abbreviation
Meaning
LCS
Launch Control Sequence
AC
Acquisition Console
ADC
Analog to Digital Converter
CC
Coordinator's Console
GC
Governing Console
SDU
Serial Data Unit
RTRT
Rational Test Real Time
DB
Data Buffer
BC
BroadcastPage 16
Page 17

1. INTRODUCTION
Software systems used for critical missions requires very high reliability. These
software intensive systems have many common features like real time, least human
intervention possible, tight hardware interactions, numerically intensive calculations etc,
The software in these systems is responsible for a variety of critical functions. It has to
interact with the hardware, other software modules, sensors, itself and possibly with
humans. Nearly 25 to 50 percentages of the development cost and time are spending on
software development of these systems. The mission performance requirements and
hardware characteristics has a high influence on the software. Extensive and exhaustive
testing of the software is hence essential. Various strategies like static testing techniques,
validation tools etc are used to test the software. However in practice, these techniques
are found to be insufficient.
There are numerous reasons for the bugs to pass undetected into the operational
phase of a project. The difficulty in understanding the real-world environment in which
the system works and interacts is one reason. Yet another is the difficult in anticipating
all of the possible modes and states that the system encounters. There is difficulty in
thoroughly validating and verifying the requirements. The difficulty in verifying that the
design has correctly been implemented, adds to the problem. To compound the problem,
there is lack of communication between software design and testing teams. So the testing
of these software modules, bug detection and rectification are the main tasks facing
software quality assurance.Page 18

2
Chapter 1
When integrating and debugging embedded system, software simulators can be
used to stand-in for hardware that does not currently exist or that is not readily available.
The author of the simulator code has a very important task to perform which is by no
means easy. The software must be written to mimic exactly the hardware specification. In
real-time systems, hardware interfaces are the most crucial part of software development.
So the software simulators should contain all of the interfaces the software need
such as register sets, controls and data buffers. The simulator should be able to run the
Test and Evaluation (T&E) cases as close as the real system. This project aims at the
developing the proof of concept of comprehensive testing environment. An attempt has
been made to replicate some or all of the hardware associated with the software under test
by appropriate stubs and modules. There are questions of fidelity and accuracy of this
approach of testing. This near real world systems-based testing allows a fairly complete
evaluation of the software even in a restricted domain.
1.1 SYSTEM UNDER TEST
Checkout System is a key system associated with launch vehicles. The primary
requirement of the Checkout System is to conduct functional checks on launch vehicle
components. The Checkout System consists of software modules and hardware interfaces
through which it is connected to the onboard systems in the launch vehicle. All the
operations of the system are to be monitored and controlled from a safe distance. The
failure in any of the elements of Checkout System should be detected from the Control
Centre. It also takes care of resetting the vehicle system and ground installation to a safe
state. Hence the reliability requirement for the system is very high as the failure is
catastrophic.Page 19

Introduction
3
The software modules form an integral part of the Checkout System. The aim of
this project is to successfully validate the Checkout Software for space applications. Code
inspection and module testing have their own inherent limitations. As the software
closely works with hardware interfaces, many errors arise during this integration phase,
due to which mission has to be aborted or postponed. To avoid this, the interfaces and
supporting modules can be simulated and the software consoles can be tested. This will
lead to detection of faults at an early phase.Page 20
Page 21

2. LITERATURE SURVEY
The use of computer-based systems has been escalating in industry and research.
Complex systems with high processing capability and short processing time have been
developed with the aid of efficient hardware units. This has been, not only due to
advanced technologies in hardware components but also due to the development of
complex software modules. The interaction of software modules with hardware plays a
strategic role in the working of systems. So the quality of the software is of utmost
importance for the working of these systems.
2.1 MISSION CRITICAL SOFTWARE
Safety critical Systems are embedded systems that could cause injury or loss of
human life if they fail or encounter errors. Flight control systems, automotive drive-by-
wire, nuclear reactor management or operating room heart/lung bypass machines all
belong to the same category. In these systems, the impact of an error can be cumulative.
The failure in the system can lead to heavy economic and time loss. So the reliability
requirements of such systems are very high.
2.1.1 CHARACTERISTICS OF MISSION CRITICAL SOFTWARE
The key characteristics of critical software are different from that of software for
any other applications. These are discussed below:
Real Time nature: the working of mission critical software are always
controlled and constrained by time. So even when testing, the timing constraints has to be
evaluated.Page 22

6
Chapter 2
High Complexity: The complexity of software is rapidly increasing. The
size of a test suite may become very large, and sometimes even exceeds the size of the
software to be tested.
Variety of embedded systems: The systems differ in their processors,
hardware interfaces, real-time operating systems etc.
Software Interfaces: The software interfaces of a target are the interfaces
that can only be accessed by software that executes on the target itself. An example of a
software interface is the Application Programmers Interface of the software to be tested.
Hardware Interfaces: the hardware interfaces are the interfaces on the
physical boundaries of the target, which are controlled or observed by the embedded
software. Architecture for testing embedded software should enable the test suite to
control the hardware interfaces. The architecture should not be limited to a certain set of
known hardware interfaces, but it should be extensible, because the number and variety
of these interfaces are continuously growing.
Software reusability and portability: Since the complexity of embedded
software is increasing rapidly, components are no longer developed for a single system,
but are applied in classes of systems. Therefore reusability and portability is of growing
importance.
2.2 SOFTWARE TESTING
Testing of software is found to play an important role in identifying the bugs and
correcting them. Early detection helps to minimize software and hardware reworks. This
will bring a large saving of time and money. Hence to ensure software quality assurance,
there is great need to focus on a comprehensive testing plan, ensuring that all
requirements are tested.Page 23

Literature Survey
7
Software testing is any activity aimed at evaluating an attribute or capability of a
program or system and determining that it meets its required results. Software testing is
crucial to software quality and widely deployed by programmers and testers. The
difficulty in software testing stems from the complexity of the software. Testing is more
than just debugging. The purpose of testing is manifold. It can be quality assurance,
verification and validation, or reliability estimation.
Tests with the purpose of validating the product works are named clean tests, or
positive tests. The drawbacks are that it can only validate that the software works for the
specified test cases. A finite number of tests cannot validate that the software works for
all situations. On the contrary, only one failed test is sufficient enough to show that the
software does not work. Dirty tests or negative tests refer to the tests aiming at breaking
the software, or showing that it does not work. A piece of software must have sufficient
exception handling capabilities to survive a significant level of dirty tests.
A testable design is a design that can be easily validated, falsified and
maintained. Because testing is a rigorous effort and requires significant time and cost,
design for testability is also an important design rule for software development.
2.2.1 TAXONOMY
There is a surplus of testing methods and testing techniques, serving multiple
purposes in different life cycle phases. Classified by purpose, software testing can be
divided into: Correctness testing, performance testing, reliability testing and security
testing. Classified by life-cycle phase, software testing can be classified into the
following categories: requirements phase testing, design phase testing, program phase
testing, evaluating testing results, installation phase testing, acceptance testing andPage 24

8
Chapter 2
maintenance testing. By scope, testing can be classified as follows: Unit testing,
component testing, integration testing and system testing. The black box approach is a
testing method in which test data are derived from the specified functional requirements
without regard to the final program structure. On the other hand, the structure and flow of
the software is visible for the test faculty in white box testing. Testing plans are made
according to the details of software implementation, such as programming language,
logic and styles. Test cases are derived from the program structure. Further, white box
testing is classified as Static testing and dynamic testing.
2.2.2 STATIC TESTING
In this method, there is no need for the execution of the software program for
testing. It aims at correct descriptions, specifications and representations of software
systems and is therefore a precondition to any further testing exercise. Static analysis
covers the lexical analysis of the program and investigates and checks the structure and
usage of the individual statements. It can be done in either manual method or by
automated tools. The most important manual technique, which allows testing the program
without running it, is software inspection. A software inspection is a group of review
process that is used to detect and correct defects in a software work product. It is a
formal, technical activity that is performed by the work product author and a small peer
group on a limited amount of material. It produces a formal, quantified report on the
resources expended and the results achieved. During inspection either the code or the
design of a work product is compared to a set of pre-established inspection rules.
The main advantage of static testing is that these techniques do not take the
interaction of the programâ„¢s input parameters into consideration. This is important
especially in real time mission critical software. They determine the run-time behavior ofPage 25

Literature Survey
9
a real time system and need to be revalidated. The static techniques finds difficulty to
assess the complexity of most systems, prohibits the estimation of internal parameter
values, loop bounds or the complete dynamic behavior. The user interfaces and graphical
user interfaces are also not tested with the above technique. Similarly client-server
communication cannot be validated with static techniques. The numbers of threads in the
real-time software are so high that code inspection cannot detect failure or conflicts in
their working especially during context switching. The numbers of passes needed are
more that module testing cannot be done. So there has to be higher order testing that has
to be done in order to make these critical software more reliable. Hence dynamic testing
techniques are necessary for testing real time mission critical systems.
2.2.3 DYNAMIC TESTING
While static analysis techniques do not necessitate the execution of the software,
dynamic analysis involves the running system. The analysis of the behavior of a software
system before, during and after its execution in an artificial or real application
environment is performed in dynamic analysis. It involves path and branch coverage. In
these techniques, every path and branch is traversed at least once. Other dynamic testing
procedures include test coverage analyzers, tuning and simulators. Simulation based
testing has been studied and implemented in this project.
2.2.4 NEED FOR SIMULATION SOFTWARE TESTING
In the actual set up there are a set of machines delineated with their
functionalities. They are connected through peer-to-peer networking with a number of
interfaces for achieving the overall functionality. The need for simulation is to simulatePage 26

10
Chapter 2
the actual interface cards in the checkout system. The work aims to set up a group of
computers in a LAN with individual nodeâ„¢s actual functionality and do the testing at the
lab itself before the actual launch. Hardware testing can be done at the sight by plugging
the device etc. Even there all the transient errors cannot be detected. There comes the
need for software testing. Software testing can avoid such transient errors. Some of the
interface cards (with affordable prices) can be bought and the remaining interfaces are
simulated. The simulation code is then tested with the actual code and all the bugs can be
identified at the lab itself.
Application software like Internet Browsers and Office Productivity tools are
developed in high level languages and are targeted to run on PCs and workstations and on
popular operating systems. The software developers of these packages have access to
powerful Integrated Design Environments (IDEs) for generating, managing and testing
code. These programmers have the luxury of running their application in a stable
environment and in real time under debug mode. But these are not the case with
embedded software. They do not have acres to the target hardware, until there is at least a
physical prototype. The development machine architecture and operating environment are
often different from the target machine. The hardware interfaces and cards may be costly,
usually developed concurrent with the software, and therefore not available until late in
the project. There may be real time constraints, resource constraints, concurrent
processing and safety issues. The integration between hardware and software takes place
only at the last phase of testing. This integration usually end upturning into seemingly
endless debug sessions. This is because there is equal probability of error from both
hardware and software and the testers spend time to identify the source of the fault. These
make the overall process more sequential and lengthier than desirable.Page 27

Literature Survey
11
But the most important issue is that only nominal test cases are done in the
current testing scenario. There is no provision to test the error handling paths in the
software. The faults that occur in the network, redundancy checks, fault tolerant checks
etc are never proved to function in any case of malfunctioning. These cannot be tested in
the hardware because such severe test conditions are not achievable using the actual
hardware. The number of tests that can be done using actual hardware is limited. The
mechanical moving parts like relays have limitation on the number of times they can be
activated. The time taken for setting up of the consoles for testing consumes much time.
All these factors limit the number of tests that can be done in the presence of the actual
hardware. The idea of testing based on simulation is found to provide a solution to all
these problems.
Testing, irrespective of the classification and techniques, is used to locate and
correct software defects, which turn out to be an endless process. Bugs cannot be
completely ruled out. But it is not necessary that testing and fixing errors will improve
the quality and reliability of the software, especially as complexity increases. Sometimes
fixing a problem may introduce much more severe problems into the system. But then the
purpose of software testing is ineffective. This indicates that engineering the design
process to make the product have fewer defects may be more effective than engineering
the testing process.
2.3 MIL STD 1553B
The 1553 multiplex data bus provides integrated, centralized system control and
a standard interface for all equipments connected to the bus. The bus concept provides aPage 28

12
Chapter 2
means by which all bus traffic is available to be accessed with a single connection for
testing and interfacing with the system. The standard defines the operation of a serial data
bus that interconnects multiple devices via a twisted, shielded pair of wires. The system
implements a command-response format.
2.3.1 BUS COMPONENTS
There are three functional modes of terminals allowed on the data bus: the bus
controller, the bus monitor, and the remote terminal. Devices may be capable of more
than one function.
¢
Bus controller- The Bus controller (BC) is the terminal that initiates
information transfers on the data bus. It sends commands to the remote terminals, which
reply with a response. The bus will support multiple controllers, but only one may be
active at a time. According to 1553, BC is the key part of the data bus system and the sole
control of information transmission on the bus shall reside with the bus controller.
¢
Bus Monitor : 1553 defines the bus monitor as the terminal assigned the
task of receiving bus traffic and extracting selected information to be used at a later time.
Bus Monitors are frequently used for instrumentation.
¢
Remote Terminal : Any terminal not operating in either the bus
controller or bus monitor mode is operating in the Remote Terminal (RT) mode. Remote
Terminals are the largest group of bus components.
2.4 SUMMARY OF SURVEY
It is clear that various techniques exist for Embedded Software Testing. These
can be summarized as followsage 29

Literature Survey
13
There are various errors that can occur during testing especially during the
integration phase. There is a need to avoid critical errors to save time and money. The
various approaches that currently exist are
Software Prototyping: this is one method to understand how software
should be designed before too much effort has been expended in coding, testing and
documentation. A practical approach is to build an embedded software model, testing and
tuning it in an operational environment, rather then attempting a computer simulation.
Hardware “ in- the “ Loop (HIL) : This technique uses the subset of the
entire system “ embedded processor and its associated I/O devices. Simulation of
complex system requires many sophisticated numerical algorithms, which resulted in the
use of tools like SIMULINK of MATLAB. It could run on real time platforms and could
avoid damage of the hardware.
Hardware simulation using logic simulation: This technique forces the
programmer to debug in an unfamiliar environment like waveform viewers. Initially it
uses VHDL or Verilog. Later cycle based simulation, acceleration or hardware simulation
is used to provide hardware execution environment.
Co-simulation : the real software execution is used as event driver in a
test bench model of the embedded system.
Object Oriented Simulation : there are a number of established general
purpose/ simulation specific object oriented languages for which supporting simulation
class libraries has been developed. A host of simulation environments and connectionist
tools for databases and physical equipment are also available. These are application
independent but environments are application specific.
High “ fidelity Flight Simulation (HFS) : This is a high fidelity non real
time closed loop simulation. It is an engineering level simulation.Page 30

14
Chapter 2
These techniques do not perform all inclusive testing of the software. There are
certain aspects of the critical systems that cannot be fully duplicated in a test
environment. The replication of the actual hardware or an emulator for the hardware can
be very expensive. They also do not test the hardware and network interactions of
software product. The working of the software under failure conditions like permanent
failures, transient failures and failure scenarios are not feasible with the actual system.
The real time behavior of the system cannot be validated by them to the maximum extend
possible. The neglect of these can result in failure during integrated testing.
There are cases where the concept of software simulators was used for various
application purposes. One such is a software simulator used in the development of
software for pulp cooking purposes.
In this project, a comprehensive test environment is developed. Typically these
test environments are done using the supporting computers, workstations and programs
that replicate the functions that a completely hardware-based test system cannot perform.
This near real world systems-based testing allows a fairly complete evaluation of the
software even in a restricted domain. In addition, unusual situations and system
/hardware error conditions can be put into the software under test without actually
impacting hardware.Page 31

3. CHECKOUT SYSTEM
3.1 OVERVIEW
Checkout System is a key system associated with Launch Vehicles. The main
purpose is to conduct checks on the subassemblies of a launch vehicle as well a son the
integrated system. In physical terms, the checkout system consists of software modules
and hardware interfaces through which it is connected to the onboard systems in the
launch vehicle. It controls the sequence of various tests and the sequence of the launch.
The reliability requirement for the system is very high as failure leads to heavy
economical and temporal loss. The software modules forms an integral part of the c
checkout system. So the testing of these modules, bug detection and rectification are the
questions facing quality assurance.
The present checkout system is configured as a distributed system. The operation
consoles are situated at the Launch Station (LC) and the remote consoles and the
Input/Output interfaces at the Remote Terminal Room near the launch pad. The consoles
in the remote room are interconnected together on a LAN. The Launch Station is located
at about 6km away from the Remote Terminal Room and is interconnected by fiber
optical cables and hard-line. The Launch Checkout test procedures are initiated from
Checkout system consoles at the Launch Vehicle Center and are executed by the consoles
at the remote terminal. The responses of the commands are collected from Launch
Vehicle through the Input/output interfaces and passed on to the respective system for
data analysis, surveillance and logging.Page 32

16
Chapter 3
CONTROL ROOM
REMOTE ROOM
Fig1 : Block Diagram of Checkout System
The figure shows a model of Checkout System for the Launch Vehicle. This is a
distributed computer system with consoles stationed at different geographic locations,
which communicate through an Ethernet. The different modules in Checkout System may
be classified as commanded consoles, control consoles, remote consoles, front-end nodal
consoles. Each console has its own function to be performed. It has several software
modules, which communicate through the network. These software modules include a
control console called Hardline Signaling Unit (HSU), commanding console called
Governing console(GC), Coordinators Console, Remote Console called Acquisition
Console (AC) and interfacing console called Interface Unit(IU). In addition to these
CONTROL
CONSOLE
COMMANDING
CONSOLE
GOVERNING
CONSOLE
INTERFACE
RELAY
AC
ETHERNETPage 33

Checkout System
17
software modules, there are other hardware cards attached to these units for various
purposes.
The aim of the project is to create a suitable virtual environment to validate the
Checkout Software. The project aims at achieving the validation and testing of the
software in the absence of the actual hardware present in the real testing and launch
scenario. The simulator developed helps in testing the exhaustive testing of the software
modules. This testing method helps to check not only the nominal paths, but also the
error handling present in the software.
3.2 ACQUISITION CONSOLE
Acquisition Console is the critical software in the Launch Vehicle Checkout
System. AC computer has a key role to play in the communication with the Launch
Vehicle. It has interfaces with various other independent hardware units. The AC
software takes the initiative to communication with these units. It has several functions
like
Receiving and interfacing commands from the various units through the
network
To acquire the digital monitoring signals
To acquire the analog parameters such as relay pole voltages, battery
voltages, pressures etc.
To provide the prime/redundant selection of the checkout computers
To fill the real-time broadcast buffer according to the acquired signals
sequencePage 34

18
Chapter 3
The total environment of the system can be modeled as shown in the figure.
The AC console can work in two modes during testing: standalone mode and
integrated mode. In Standalone mode, manual commanding can be done so that there is
no need for the reception of commands from the commanding console. In Integrated
mode, the commands are send by the commanding consoles through the network and the
AC sends suitable signal words to the hardware packages present. The change in the
hardware will be acquired by another set of hardware cards to the AC. The AC makes
appropriate changes in its Real time Broadcast Buffer depending on the status change
received from the hardware cards, which are transmitted on a regular interval to all the
participating consoles.
COMMAND
MONITORING
DB BROADCAST
COMMANDING
CONSOLES
AC
V
E
H
I
C
L
E
COMMAND
Fig 2: Total environment of the systemPage 35

Checkout System
19
The AC is found to have maximum number of interfaces with various hardware
cards. In addition, it is connected to the network and can receive commands from other
consoles and send broadcast packets. The fig shows the various interfaces the AC
module.
digital data
acquisition
Commands
analog data
acquisition
Network Links
Fig 3: Role of AC
The AC receives commands from the various commanding units like Governing
Console (GC), Power System Console(PC) etc. The commands from the commanding
consoles will be diode ORed and will operate the relay circuits in the INTERFACE 2
relay pack. For redundancy, each relay of the controlling circuit will be operated from
three different modules residing in three different INTERFACE 1 chassis.
ACQUISITION
CONSOLEPage 36

20
Chapter 3
3.2.1 INTERFACE 1 Chassis Configuration
Each INTERFACE 1 chassis accommodates different types of cards such as
Relay cards, TTL, ADC and OPTO cards. Relay cards are used to operate relay coils. In
every INTERFACE 1 chassis, there are five relay cards each with a capacity of 80
channels. TTL cards are used to acquire intermediate relay status. a total of four TTL
cards with 256 channel capacity are used in one system. OPTO cards are used to acquire
on board digital parameters. A total of 2 OPTO cards/system of 128 channel capacity are
used. 64 channel ADC modules are used for the analog parameter acquisition.
The INTERFACE 1 system acts as an integral I/O subsystem for AC console. All
the umbilical commands are routed to the vehicle through the vehicle interface. These are
executed by AC through the INTERFACE 1 relay module located in the INTERFACE 1
racks. The analog and digital data are acquired from onboard and ground systems through
the INTERFACE 1 channel intensive modules located in INTERFACE 1 racks.
3.2.2 COMMAND EXECUTION
INTERFACE 1 I/O
System
Fig 4: Basic Relay Communication
AC
INTERFACE 2
RelayPage 37

Checkout System
21
The execution of the commands involves commanding INTERFACE 1 relays.
The basic relay configuration is as shown in figure. Library functions have been defined
for INTERFACE 1 relay operations such as
Closing a relay
Opening a relay
Closing a relay after a specific duration
The INTERFACE 2 relay coils are activated through the low current relays in
INTERFACE 1 relay cards. AC commands the INTERFACE 1 relays. Only when two of
the three INTERFACE 1 relays are activated, the INTERFACE 2 relay is energized.
3.2.3 ACQUISITION
Analog parameters related to onboard such as pressure (PR values), Relay Pole
Voltages (RPV), as well as Terminal Voltage and Current (TR values) are monitored
through the Analog to Digital Converters (ADC). The TTL cards are used to monitor the
on/off status of commands. Three individual statuses representing on/off status of a
command is given to three TTL cards respectively. In order to get the TMR status the
TTL cards representing the individual status have to be acquired at the same time. The
OPTO acquired module post the acquired digital status to the Real-Time Data Buffer
(RDB). Data collected from the various sources will be available in RDB maintained
locally in Acquisition Console (AC). RDB will be used to synthesize a data packet (BC1
and BC2) to send through the network to the Control Center. Hardcore Updation provides
fault tolerance to the system. During normal operation both AC prime and redundant will
be executing in parallel. If any of the system misbehaves, cutting the network connection
to the Ethernet switch using relays will isolate it.Page 38

22
Chapter 3
The acquisition of data is done by various hardware cards as mentioned before.
The OPTO card acquires the digital status and the ADC acquires the analog values. These
are properly timed so that there is no loss of data that is being acquired. The figure is a
cyclogram showing the 200 milliseconds timing cycle of different tasks in AC. This
include ADC acquisition (PR1, PR2, PR3, TV1, RPV, BATTERY), OPTO Acquisition
(OPTO), TTL acquisition (TTL), Data broadcasting (BC1, BC2), Hardcore Updating
(H/C), Command Stripping and Command Execution.
3.3 INTERFACE UNIT
The remote room houses the Interface Unit. So minimal functioning is
implemented directly in it. Additionally, functionalities where execution time is critical
are also implemented in Interface Unit. It is found to act as an interface between the
Control Center and the Onboard packages. It is configured as the bus controller. It is
found to have a direct interface with the Hardline Signaling Unit (HSU) through the
peripheral Input Output (PIO) card. The whole set of initialization data set is downloaded
to Interface Unit on fresh receipt of initialization file.
Windows NT/2000 operating system and Visual C++ framework with MFC class
library form the development environment and executing environment. Real-time
extension of Windows Add on “ INTIME is incorporated. Usage of VC++
framework with MFC class library gives enormous number of classes with tremendous
inbuilt functionalities for designing applications. These classes are mostly used for
designing user interfaces and improving the look and feel of the application.
Interface Unit is heavily dependent on the network interfaces for providing
services the consoles in the Launch Control Room. There will be two Interface Unit-Page 39

Checkout System
23
prime and redundant. Interface Unit prime will be controlling the 1553 buses. In case of
failure, redundant Interface Unit will take over control of both the buses. Each Interface
Unit will be equipped with two network interface cards. Interface Unit will receive
commands from the Launch Station (Governing Console) and send command response
packet back to the command originating node. It will alsobroadcast frames every 100ms.
3.4 GOVERNING CONSOLE (GC)
The Governing Console is the front end unit of the Interface Unit. It is positioned
in the Control Center, which is located 6kmfrom the remote room. It has the ability to
command various other consoles as well as to receive their status changes by acquiring
the broadcast frames from the various units. It sends commands to AC as well as to IU in
the current testing environment. The command received from the GC was issued to the
AC as well as to IU.
The functions of GC are as below:
¢
Accept commands from menu
o Executed if it is local
o Form packets and port command to IU or AC
¢
Display data from command response packet identified
¢
Display onboard status
¢
Display network data
o Monitor IU
o Indicate Interface status and restart
¢
Execute network commands
¢
Configure IU for control system check
Network InterfacesPage 40

24
Chapter 3
User Interfaces
Digital I/O
Fig 5: Governing Console
3.5 COORDINATORâ„¢S CONSOLE (CC)
The Coordinators Console is a part of the Test Checkout System. It is located at
the Checkout Control Room. It acquires and process the network frames from the various
units including AC. It has to acquire four data frames from AC through the checkout
LAN, which is broadcast every 200 milliseconds. The console also generates the count
down HOLD signal based on the surveillance of critical parameters during the tests and
interfaces these signals with control system. It is found to have interface with a Digital
Input Output card (DIO).
GOVERNING
CONSOLEPage 41

Checkout System
25
Coordinators Console informs the Hardline Signaling Unit signal reception to
Interface Unit for actions at the Interface Unit. Coordinators Console informs other
consoles, the reception of Hardline Signaling Unit signals through a broadcast.
Coordinators Console should acquire the periodic broadcast frames of Interface Unit and
AC through the network. It has to acquire four data frames from Acquisition Console
through LAN, which is broadcast every 150 milliseconds. Coordinators Console asserts a
broadcast failure from Interface Unit/ Acquisition Console- prime and redundant on
missing broadcast frame continuously for 1 second.
LAN
HARD-LINE
Fig 6: Coordinator's Console
In its normal working, this unit asserts a broadcast failure from AC “ prime or
redundant on missing broadcast frame continuously for 1 second.
AC
¦.
¦.
NETWORK
CC
HSUPage 42
Page 43

4. SOFTWARE ENVIRONMENT
4.1 INTIME
INTIME real time operating system is developed by TenAsys. They provide the
only line of real-time operating systems and extensions designed and optimized
specifically for the Intel x86 architecture and Microsoft windows Software. This software
combines deterministic, hard real-time control with standard specifically to take
advantage of the powerful capabilities of x86 processor architecture. Therefore the real-
time and non-real time applications run in separate virtual machines on a single
computer, for cost effective, reliable control that is easy to develop and maintain.
4.1. 1 INTIME SOFTWARE ARCHITECTURE
INTIME Software extends Windows NT to provide the tools to create and run
RT (real time) applications. An INTIME application includes these components.
¢
RT processes: RT processes contain threads that typically handle time-
critical I/o and control. Rthreads preempt Windows NT threads.
¢
Windows NT Processes: Windows NT Processes contain threads that
handle aspects other than time-critical I/O and control, including the user interface,
network communication, data manipulation, computation and data storage.
Communication between Windows NT and RT threads
When an INTIME application runs, Windows NT threads communicate with RT
threads via the Windows NT extension (NTX) API. The RT threads in INTIMEPage 44

28
Chapter 3
applications may reside on the same PC as the Windows NT threads or in a remote
computer accessed via the serial or Ethernet cable. The NTX API automatically detects
the connection type and determines the transport mechanism to use between Windows
NT and RT threads in memory (local), serial or Ethernet.
Fig 7: Transport mechanism for NTX communication
Considerations for INtime applications running on a single PC
When both Windows NT and RT portions of an INtime application run on a
single PC, INtime software transfers control between the Windows NT and RT
environments as in figure:
1.
When a Windows NT thread runs, the full Windows NT environment
exists, including its interrupts, interrupt masks, and handlers
2.
When an RT interrupt occurs, control immediately switches to the RT
Kernel, when an RT interrupt handler deals with the event. This, in turn may cause one or
more RT threads to execute.
Windows NT host
Intime applications
(Windows NT portion)
1-n
RT Clients
Intime applications
(RT portion)
NTX
Transport MechanismPage 45

Checkout System
29
3.
Windows NT processes and interrupts stop until the RT threads
complete.
4.
When all RT threads complete their work, leaving no RT threads ready
to run, control switches back to the Windows NT environment, and standard Windows
NT scheduling resumes.
Fig 8: Transferring control between Windows NT and INtime softwareâ„¢s kernel
When running on a single microprocessor, the INtime runtime environment
encapsulates all Windows NT processes and threads into a single RT thread of lowest
priority. As a result, RT threads always preempt running Windows NT threads,
guaranteeing determinism for RT activities within the system.
Windows NT runs
1
RT Interrupt
occurs
Switch to RT kernel
Switch to
Windows NT
Windows NT
Activity stops
RT threads idle
3
2
4Page 46

30
Chapter 3
The RT and Windows NT threads can share sections of memory allocated by
INtime applications. A Windows NT thread can obtain handle for this shared memory,
then map the memory referenced by that handle into the threads address space.
When designing INtime applications, one must divide the labor appropriately
between Windows NT processes and INtime processes and, to a finer degree, between the
threads in each process. For the best performance, limit RT processes to performing only
critical functions, and determine which Windows NT threads require the greater relative
priority.
When an INtime application runs on an INtime node, Windows NT threads
communicate with RT threads via the Windows NT extension (NTX) library as shown:
Transport
Mechanism
Fig 9: INtime components
INtime software application
Windows NT
process
Real time process
NTX
library
Realtime C
lib
Real time
RT Kernel
Windows NT
kernel
Transport
driver
Modified hal.dll
3
5
4
6
1
2Page 47

Checkout System
31
INtime components
The INtime components include:
1.
RT Kernel:
Provides deterministic scheduling and execution of RT threads within RT
processes.
2.
Real-time applications, C and EC++ libraries:
Gives direct access to RT Kernel services for RT threads.
3.
NTX library:
Provides RT extensions for Win 32 API that allows Windows NT threads to
communicate and exchange data with RT threads within the application.
4.
Transport driver:
A driver that converts information to the protocol needed by the specified
transport mechanism.
5.
Transport Mechanism:
The communication protocol or method used by NTX to communicate between
Windows NT and RT threads. Whether the various portions of INtime applications reside
on a single PC, or on multiple computers accessed via serial or Ethernet cable, NTX
provides this essential communication.
6.
Modified Windows NT hardware abstraction layer (hal):
A special version of Windows NT hal improves the overall reliability and
robustness of an INtime node, allowing RT threads to continue executing properly even if
Windows NT crashes.
System Requirements
Platform
: Windows XP.
Language
: Microsoft Visual C++
Database
: MS AccessPage 48

32
Chapter 3
Description of the project
This section covers the various stages and work included in this project.
Simulation based software testing has better performance compared to hardware
testing. Several hardware and packages has to be simulated. It will be very effective and a
number of errors can be detected. The vehicle simulator is to be designed so as to
replicate the actual behavior of the vehicle. These include simulation of a range of faults
with respect to time.
The vehicle simulator contains a number of simulators like SDU simulator,
telemetry simulator, hardcore simulator etc. With the view of building all these in a
standard approach, SDU simulator is designed initially with Rational Rose.
The requirements were captured using the tool Requisite Pro in a organized
manner. After identifying the requirements, an SRS is prepared for the simulator. Use
case diagram is also designed using Rational Rose. A design document is also prepared.
Next the class diagrams are designed. From that the code is generated
automatically in Visual C++ by adding the individual components to the project.
Sequence diagrams are also designed.
The interface cards like ADC, TTL, OPTO, Relay cards are also simulated.
The tool Requisite Pro is used to capture requirements.The tool RTRT is
integrated in the project for the coverage analysis of various functions.Page 49

5. SERIAL DATA HANDLING UNIT SIMULATOR
The Serial Data Unit Simulator is a part of the launch control sequence (LCS)
Simulation Test Bed for testing the LCS Software without the actual flight elements. The
Serial Data Unit Simulator incorporates all the functionalities of Serial Data Unit required
during the launch sequence phase. With this software the required behavior of Serial Data
Unit as well as a number of error conditions can be simulated with different combinations
of data in the configuration file thus testing the LCS Software thoroughly.
5.1 PRODUCT FUNCTIONS
Serial Data Unit System are data handling units onboard the launch vehicle
through which a large number of analog and digital parameters of the vehicle are
monitored during the pre launch phase. During LCS, a number of relay operating
commands is given to Serial Data Unit and RAC and correct execution of these
commands are verified by monitoring the status of a number of digital parameters and
values of analog parameters in the Serial Data Unit frames. Serial Data Unit
communicates with host through a serial page link using a serial INTERFACE Card. Each
Serial Data Unit is connected to each port of the INTERFACE card. The Serial Data Unit
System configuration is as shown in the figure.Page 50

34
Chapter 5
Fig 10: Position of SDU
The Serial Data Unit Simulator replicates the exact behavior of the Serial
Data Unit System. Other than using a serial link, Serial Data Unit Simulator
communicates with host through a LAN using TCP/IP protocol. This eliminates
the need of a serial INTERFACE card. For testing the LCS Software, the only
change required in the host Code is to remove obj library from the project and
include file sim.c, which contains the implementation for the driver calls.
ONBOARD
H
O
S
T
SDU 1
SDU 2
SDU 3
SDU 4
I
N
T
E
R
F
A
C
EPage 51

Serial Data Unit Simulator
35
Fig 11 : Overall system configuration
The important functionalities of the Serial Data Unit Simulator are:
1.Read all the configuration details from the database “ The various commands send
to Serial Data Unit and the digital and analog parameters that are affected due to
execution of these commands are stored in a table, DATATABLE, in the database. It
contains the status of digital parameters and value of analog parameters and LCS
specifies the time after which these changes are to be reflected. On start of Serial Data
Unit Simulator, it reads all these configuration details and stored within it.
2.Reception and Execution of Commands from host “ The command reception module
task are
1.Reception of command frames through network
The command frame format for Serial Data Unit is as shown below
HOST
Serial Data Unit
SIMULATOR
DATA
TRANSMISSIO
N
COMMAND
RECEPTION
DATA TABLE
DATA FRAMES
COMMANDS
LANPage 52

36
Chapter 5
STX
Com
mand
Com
mand
Complement
RS
Command
Command Complement
2.Validation of command frames: This includes
i) Checks whether command frame starts with STX (0x02)
ii) Checks whether command complement is valid
iii) Checks whether command frame ends with RS (0x1E). Ie:
3rd frame from STX
3.Execution of Commands
1.Relay Actuation Commands.
Each Serial Data Unit system can execute 24 relay actuation commands.
These commands are classified in to three groups GROUP A, GROUP B and
GROUP C with each group comprising of 8 commands each. A one byte
command code is LCS identified for each these 24 commands. But these
commands will be executed at the Serial Data Unit only if the flags GLOBAL-
ENA and GROUP-ENA flag for respective group are set. These flags are
PA
C6
C5
C4
C3
C2
C1 C0
PA
__
C6
__
C5
__
C4
__
C3
__
C2
__
C1
__
C0Page 53

Serial Data Unit Simulator
37
modified using reserved commands. Thus when a relay actuation command is
received at the Serial Data Unit Simulator, it checks whether GLOBAL-ENA and
GROUP-ENA flag for the group to which the command belongs is set. If so, the
parameters that are to be modified, their value and the time after which they are
to be to be modified are read from the configuration file and this information is
stored in a response queue. The response queue is a sorted list.
2.Reserved Commands “ The valid reserved commands send from host during LCS are:
1.Command enable “ This command is global enable for executing all the relay
commands. On reception this command the flag GLOBAL-ENA is set.
2.Command disable - On reception this command the flag GLOBAL-ENA is
unset.
3.Relay Command authorization (enable & disable)-These commands
individually enable or disable executing the three relay command groups. To execute
these commands GLOBAL-ENA has to be set.
a. Cmd 1-8 (Group-A) Relays “ GLOBAL-ENA
b. Cmd 8-16 (Group-B) Relays
c. Cmd 17-24(Group-C) Relays
3.Transmission of Serial Data Unit Frames
Each Serial Data Unit data frame consists of 149 bytes of data and contains 64
analog channel and 96 digital channel information. Serial Data Unit data frames have
even parity and for all valid bytes the transparency bit has to be set. Each analog channel
is represented by two bytes and each digital channel block contains information of six
digital channels. Before transmission of each data frame, Serial Data Unit Simulator
checks whether there are any pending responses for that frame in the response queue forPage 54

38
Chapter 5
commands received earlier. If so, the corresponding bytes are modified and the packets
are transmitted to host.
4.Response Queue
When a valid relay actuation command is received at Serial Data Unit, the
multiple responses for the command and the Serial Data Unit frame on which these
changes are to be reflected are added to a response queue. The queue is always sorted in
the ascending order of the Serial Data Unit frame count. Thus responses can be retrieved
from the queue in the minimum time. Before transmission of a Serial Data Unit frame,
the responses for that particular frame are read from the queue.
5.Simulation of a specific value for an analog or digital parameter without any
Serial Data Unit Command -
The system shall have provision for changing the value of an analog or digital
parameter without reception of any command. The parameter to be changed and the time
after which this change has to be incorporated should be mentioned in the DATATABLE.Page 55

Serial Data Unit Simulator
39
5.2 FUNCTIONAL MODULE DECOMPOSITION
Fig 12: Functional Decomposition of SDU Simulator
5.3 DESIGN DESCRIPTIONS
MODULE DETAILED DESIGN
The Serial Data Unit Simulator software is implemented in Windows XP operating
system and Graphical User Interface realized with Dialog Based Application in Microsoft
Visual Studio.
Serial Data Unit
SIMULATOR
READ FROM THE
CONFIGURATION
FILE
COMMAND
RECEPTION
DATA FRAME
TRANSMISSION
RESPONSE
QUEUEPage 56

40
Chapter 5
6.1.1 Overview of the Classes for Serial Data Unit Simulator Software
1.
CvsimDlg
Purpose: Serial Data Unit Simulator starts from this class. Allocation of objects,
their de-allocation etc.
Input
:
Output
:
Interfaces
:
2. ScoutApp
Purpose: The base class of Serial Data Unit Simulator. To check whether the
command is valid, whether it is Serial Data Unit LCS command, whether it is a new
command, add to action list , update scout packet etc.
Input
: NIL
Output
:
Interfaces
: Interfaced to CvsimDlg for dialog application
2. Sct_Response
Purpose:The action list contains scout response objects. Each object contains a
particular action for the LCS command received. It contains information like frame
count, the byte to be modified , the status of bit for digital parameter and the value for
analog parameter.
Input
: NIL
Output
: Response list
Interfaces
:
3. Sct_DataPage 57

Serial Data Unit Simulator
41
Purpose:To store the Serial Data Unit LCS command details from the database,
Each record in the table is stored as an object of this class.
Input
:
Output
: All the commands, scout id, byte position and value
Interfaces
:
4. Database1 :
Purpose: To perform Open, Read, Close operations on Serial Data Unit
Simulator database written in MSAccess.
Input
: Database table
Output
:
Interfaces
:
5. NIS
:
Purpose: To perform the actual sending and reception of data through the
network. This is a derived class of the MFC CAsyncSocket
Input
:
Output
:
Interfaces
:
5.4 CLASS DIAGRAMS
A class diagram is a picture for describing generic descriptions of possible
systems. Class diagrams and collaboration diagrams are alternate representations of
object models. Class diagrams contain classes and object diagrams contain objects, but it
is possible to mix classes and objects when dealing with various kinds of metadata, so the
separation is not rigid.Page 58

42
Chapter 5
Class diagrams are more prevalent than object diagrams. Normally you will build
class diagrams plus occasional object diagrams illustrating complicated data structures or
message-passing structures.
Class diagrams contain icons representing classes, interfaces, and their
relationships. You can create one or more class diagrams to depict the classes at the top
level of the current model; such class diagrams are themselves contained by the top level
of the current model. You can also create one or more class diagrams to depict classes
contained by each package in your model; such class diagrams are themselves contained
by the package enclosing the classes they depict; the icons representing logical packages
and classes in class diagrams.
You can change properties or relationships by editing the specification or
modifying the icon on the diagram. The associated diagrams or specifications are
automatically updated.Page 59

Serial Data Unit Simulator
43
CDialog
<<virtual>>CDialog()
<<virtual, const>> Dump()
<<virtual, const>> AssertValid()
<<virtual>> OnCmdMsg()
<<virtual>> PreTranslateMessage()
<<virtual>> CheckAutoCenter()
<<virtual>> SetOccDialogInfo()
<<virtual>> DoModal()
<<virtual>> OnInitDialog()
<<virtual>> OnSetFont()
<<virtual>> OnOK()
<<virtual>> OnCancel()
<<virtual>> PreInitDialog()
(from Dialog Boxes)
CAsyncSocket
<<virtual>> Accept()
<<virtual>> Close()
<<virtual>> Receive()
<<virtual>> Send()
<<virtual>> OnReceive()
<<virtual>> OnSend()
<<virtual>> OnOutOfBandData()
<<virtual>> OnAccept()
<<virtual>> OnConnect()
<<virtual>> OnClose()
<<virtual>>CAsyncSocket()
<<virtual, const>> AssertValid()
<<virtual, const>> Dump()
<<virtual>> ConnectHelper()
<<virtual>> ReceiveFromHelper()
<<virtual>> SendToHelper()
(from Windows Sockets)
Sct_Response
sct_id : int
byte_pos : int
value : int
sct_frame_no : double
<<const>> operator<()
<<const>> get_byte_pos()
<<const>> get_sct_frame_no()
<<const>> get_value()
<<const>> get_sct_id()
set_sct_frame_no()
set_value()
set_byte_pos()
set_sct_id()
SctAlsData
m_SctId : int
m_CmdCode : int
m_delay : int
m_nosrcs : int
m_BytePos : int*
m_Value : int*
m_src : int*
SetDataDetails()
<<virtual>>SctAlsData()
SctAlsData()
<<const>> get_Value()
<<const>> get_BytePos()
<<const>> get_nosrcs()
<<const>> get_SctId()
<<const>> get_src()
<<const>> get_CmdCode()
<<const>> get_delay()
NIS
rcv_data[BUFSIZE] : unsigned char
cmd_buf[BUFSIZE] : unsigned char
brd_buf[BUFSIZE] : unsigned char
nRcvPort : int
senddata()
sendcmd()
nisinit()
<<virtual>> OnReceive()
<<virtual>>NIS()
NIS()
ScoutApp
global_cmdenb : bool
grp_cmdenb[GRPS] : bool
Sct_Frame_Count : double
Sct_Supply_On : bool
sct_frame[SCT_FRM_LEN] : unsigned char
last_cmd : unsigned char
No_Records : int
IsValidCommand()
IsSctAlsCmd()
Add_ActionList()
UpdateSctPkt()
IsNewCmd()
ScoutApp()
<<virtual>>ScoutApp()
<<static>> PktRcvd()
<<const>> get_No_Records()
set_No_Records()
CmdRcvd()
<<static>> UpdateDataBuf()
NonSctResp()
-$SctActLst
+theSctAlsData
+ptrSct
AlsDatabase
m_Recordset : CDaoRecordset*
m_Database : CDaoDatabase*
m_TableDef : CDaoTableDef*
m_Fieldinfo : CDaoFieldInfo
GetFloatValue()
GetRecordCount()
GetRecordData()
GetStringValue()
GetIntValue()
Opendatabase()
Closedatabase()
<<virtual>>AlsDatabase()
AlsDatabase()
CVsimDlg
+m_RcvSocket
+pScoutApp
+db
Fig 13: Class Diagram of SDUPage 60

44
Chapter 5
5.5 USE- CASE DIAGRAM
Use-case diagrams graphically depict system behavior (use cases). These
diagrams present a high level view of how the system is used as viewed from an
outsiderâ„¢s (actorâ„¢s) perspective. A use-case diagram may depict all or some of the use
cases of a system.
A use-case diagram can c