CHAPTER 3
TEST SOFTWARE
Test software is developed by using two different software packages which
are MATLAB and C++ Builder. The control algorithms for the tests are
generated, compiled and turned into code by using Simulink, xPC target and Real
Time WorkShop (RTW) modules in MATLAB. On the other hand, the user
interface, which is used together with the file prepared in MATLAB, is designed
in Borland C++ Builder.
MATLAB is one of the most popular softwares regarding this type of
control applications. Simulink is a platform that runs in conjunction with
MATLAB and makes it possible to model, simulate and analyze dynamic
systems. It provides an interactive graphical environment and a customizable set
of block libraries that let the user accurately design, simulate, implement, and test
control, signal processing, communications, and other time-varying systems.
On the other hand, xPC Target provides a high-performance, host-target
prototyping environment that enables user to connect Simulink models to physical
systems and execute them in real time on PC-compatible hardware. xPC Target
enables user to add I/O interface blocks to the models, automatically generate
code with Real-Time Workshop, and download the code to a second PC running
the xPC Target real-time kernel. Real-Time Workshop is an extension of
capabilities of Simulink and MATLAB that automatically generates, packages
and compiles source code from Simulink models to create real-time software
applications on a variety of systems.
As seen in the Figure 3.1, target application code to be used in real time is
generated in three steps by using three modules of MATLAB software.
1
Figure 3.1 – Steps of generating target application file
At this stage, the system can run by simply loading and running the
generated code on the target computer by interfacing MATLAB software.
However, a custom graphical user interface is aimed and MATLAB’s limited
interface doesn’t meet the need for a unique, flexible interface for the test
applications. This problem is solved by using a graphical user interface program.
At this point, there has to be something to establish connection between the test
algorithm code and the graphical user interface. For that connection, two
extensive application interface capabilities of xPC Target is considered, which are
xPC Target API and COM API. Both interfaces provide full access to the
controls, signals, and parameters of xPC Target for use in developing custom
graphical user interfaces which can be developed with Visual Basic, Visual
C/C++ or other programming tools, using subroutines (a type of program unit).
2
If the term API (Application Programming Interface) is to be defined, it can
be any interface that enables one program to use facilities provided by another,
whether by calling that program, or by being called by it. Depending on this
definition, xPC Target API consists of C functions that user can incorporate into
any high language application, whereas The xPC Target COM API consists of a
suite of interfaces that user can reference while building a graphical user interface
application. A user can use an application written through either interface to load,
run and monitor an xPC Target application without interfacing with MATLAB to
control real-time MATLAB Simulink applications running on a target PC.
When these two application programming interfaces are compared, xPC
Target API has superiority over xPC Target COM API that former one has some
extra functions such as file system functions. Considering this situation, xPC
Target API is preferred to be used with an appropriate third-party graphical
development environment.
For the graphical user interface, rapid application development programs are
appropriate because of their drag-drop properties. User can simply establish the
interface by adding components to the forms, setting the properties of them and
writing the code beneath. Microsoft Visual Basic and Borland C++ Builder are
good, widely used examples of this type of softwares. As xPC Target API is used
for application programming interface, Borland C++ Builder is preferred for its
compatibility to that interface.
To sum up, the target application file which includes control algorithms for
tests, is generated and compiled by using xPC target, Real Time WorkShop
(RTW) and Simulink modules in MATLAB and is loaded onto control hardware
by the help of the user interface which is prepared in Borland C++ Builder. As
can be seen Figure 3.2, test system is composed of three parts, first of which is a
host computer (desktop or a laptop PC) on that the user interface is running and
the target application file exists, second part is the target computer (PC/104 with
I/O units) onto which the target application file is loaded and started to run and
the last part is the physical test setup which the target computer communicates to
drive actuators and get signals while tests are running. When the target
3
application file is loaded and started to run in PC/104, in other words in the target
computer, according to algorithm established in the model and parameters set via
user interface, communication is accomplished with actuators and sensors over
input/output channels so that tests run in real-time. Test parameters can be
observed and altered through user interface during the operation.
Figure 3.2 – Test System Elements
Microsoft Access database program is used as data storage to save
parameters and information related to designed tests, compose test reports and
update test progress. User interface is automatically connected to the database and
provides data transfer while it is active.
Over the user interface, it is possible to design tests, run, control and
monitor predesigned tests.
3.1. Test Simulink Model
As indicated before, a test model is prepared using xPC Target, Real Time
Workshop (RTW) and Simulink modules in MATLAB software. Simulink model
is simply formed by dragging and dropping the Simulink blocks from the
Simulink Library Browser and making connections between them in an
input/output logic.
Model’s block diagram can be seen in Figure 3.3. It consists of 7 different
blocks which are input, output, sensor and actuator channel matching, relay,
4
channel numbers and test algorithm. All blocks in the model will be described
detailly.
Figure 3.3 – Simulink Model Block Diagram
3.1.1. Input and Output Blocks
Input and output blocks simply represent data acquisition boards on the
control hardware, PC/104. xPC Target module of MATLAB provides driver
blocks of many board manufacturers. Diamondsystems, whose PC/104 and DAQ
boards are used as a control hardware in this study, is one of these manufacturers.
Because the driver support for these boards is provided in MATLAB, one can just
drag and drop the board block directly to the model. As for input, A/D converter
blocks of related boards (Prometheus and MM-32) are added to the model since
analog inputs are used, whereas for output, D/A converter and relay output blocks
of related boards (Prometheus and MM-32 for analog, Pearl for relay) are added
since analog and relay outputs are used. After adding them to the model, their
source block parameters such as base address of the board, number of channels,
sample time, etc. are set. In the Figure 3.4, Prometheus board analog input block’s
source parameter settings can be seen. Single ended type 16 channels in the
unipolar voltage range (+/- 10 volts) are used. Sample time for the block is set to
be 1/100 (0.01 seconds) which is the same as model’s. This is the scanning time
5
for the block and for the entire model and is appropriate for the application. As for
the base address, 0x280 is set which is given in board’s default configuration.
Figure 3.4 – Prometheus Board Source Block Parameter Settings
3.1.2. Relay Blocks
In the installation and test stage of the system, sample runs are done for
particular tests and as a result, some abnormalities are observed such as not
stopping of motors on switches or not completing the duty cycle for cylinders.
After examining possible reasons that might lead to these kinds of unexpected
actions, it is realized that there exists noise on sensor signals although insulated
cables are used. After coming out the difficulty of physical filtering, relay blocks
are used between the input signals and test algorithm in the model in order to
filter out this noise. Relay block which is defined in Simulink library is a special
6
block which allows its output to switch between two specified values. When the
relay is on, it remains on until the input drops below the value of switch off point
parameter. When the relay is off, it remains off until the input exceeds the value
of the switch on point parameter. The block accepts one input and generates one
output. Thus, on and off output values are set as 10 and 0, whereas switch on and
off points are determined to be 9 and 1 respectively so as not to be affected from
in between values resulting from noise.
3.1.3. Channel Blocks
So called channel number blocks, connected to the actuator or sensor
channel matching, are constant blocks in the model. Constant block generates a
constant value throughout running of the model. These blocks are used to
determine the channel numbers that the actuators and sensors are physically
connected to. Every block in the input part represents one of the particular limit
switches or inductive sensors, while in the output part, it is one of the motor
drivers or pneumatic valves. The constant number set for the block refer to a
particular channel of the DAQ boards (i.e. the value of the constant block
appointed for switch 1: 104 refers to Prometheus channel 4, first digit for board, 1
is appointed for Prometheus, 2 is appointed for DMM-32-AT, last two digits for
channel number). All the values of the blocks are set to be 0 as default, because
no actuators or sensors are assumed to be connected to the system yet.
3.1.4. Actuator/Sensor-Channel Matching Algorithm
The sensor-channel and actuator-channel matching blocks are embedded
Matlab functions that make signal routing between input and test algorithm and
between test algorithm and output regarding the values of the constant blocks. In
Embedded Matlab function one can enter Matlab code to establish an algorithm
between input and output of the block, which provides flexibility.
7
A part of sensor-channel matching block is shown in Figure 3.5. These
constant values are set to zero at the compiling level of the model, because
nothing is assumed to be connected to the boards, at that time yet. However, when
the model, in fact generated code, is loaded onto PC/104 and started to run, it
becomes possible to change these values through the user interface according to
the physical connections of sensors or actuators in the designed tests.
Figure 3.5 – Sensor-Channel Matching Block Diagram
3.1.5. Test Algorithm
When test algorithm block is examined in the model, there can be seen two
different block types inside which are sensor-actuator matching block and
actuator algorithm blocks as seen in Figure 3.6. Sensor-actuator matching block is
an embedded Matlab function which is similar to sensor-channel matching or
actuator-channel matching blocks in terms of algorithm logic, which is described
above in detail. It basically matches sensors with actuators which will be driven
accordingly in the designed test scenario. For the motor driver input, there are
four types of sensors that determine driving sequence of it in a test, which are
8
motor forward, reverse, trigger and middle switches. Motors, in fact aluminum
profile arms connected to the motors, move between two limits so that for
instance they manage the slam action on the doors. So, forward and reverse
switches are used to determine these limits. Forward switch is the switch which
the profile connected to motor is standing on at the beginning of the test, in other
words the switch on which the first movement starts in the forward direction.
Whereas, reverse switch is the switch that stops the forward movement of the
motor arm (aluminum profile) and reverses the movement in the other direction.
Therefore, a reciprocal movement is accomplished by two switches. Trigger
switch is used to synchronize motor actions when there are more than one motors
running in the test. If there wasn’t such a switch assigned in the algorithm,
because time elapsed while motor is running between the switches couldn’t be
known, duty times of motors would overlap and confusions in the order might
have arised. Thus, by means of this switch, synchronization between motors is
accomplished. If no switch is appointed as a trigger switch, in other words there is
only one motor in the test, then the switch appointed as forward switch
implements the triggering task. Middle switch that is located between two limit
switches, can be defined as a switch that changes the speed of the motor in
forward or reverse directions. Trigger switch for the valve, as for the motor driver,
is for synchronization purposes when there are one or more motors used with the
valve in the test. So, the order of the valve to be driven is adjusted by the trigger
switch appointed to that valve and as a result opening or closing action is
triggered by one of the motor arms during the test. However, if there are no
motors used in the test, a valve can be driven by only adjusting its duty times,
there will be no need to appoint a trigger switch for that valve.
9
Figure 3.6 – Test Algorithm Block Diagram
10
3.1.5.1. Motor Driver Subsystem
Motor driver subsystem consists of 4 inputs, 1 output, 1 embedded function
block, constant blocks, a memory block and a subsystem that is used for cycle
counting of the tests. Cycle counting subsystem will be described in another
section detailly. Inputs are sensor signals (forward, reverse, trigger and middle
switch signals) and the output is motor driver signal. The constant blocks are used
for parameter setting for emergency pause, reset signal (0 for activating, 1 for
deactivating the command), motor’s forward and reverse speeds (-10 to 10 which
refers to motor driver signal and proportional to motor speed), switch on-off state
(1 for activating, 0 for deactivating the switch) and forward and reverse motion
delay and waiting timings. Time values are in the units of miliseconds. Memory
block outputs the input from the previous time step and is used as a counter for
delay and waiting time of motor motion. Embedded function block includes the
motor driver algorithm whose flowchart can be seen in Figure 3.7. This algorithm
simply checks the connected sensor signals and outputs the driver signal
proportional to the desired motor speed according to the predetermined timings
and sequences.
11
Figure 3.7 – Motor Driver Flowchart
This algorithm simply checks the connected sensor signals and outputs the
driver signal proportional to the desired motor speed according to the
predetermined timings and sequences. The model of the motor driver subsytem
can be seen in Figure 3.8
12
Figure 3.8 – Motor Driver Model Block Diagram
13
3.1.5.2. Valve Driver Subsystem
Valve driver subsystem simply consists of 1 input, 1 output, 2 embedded
function blocks (one for independent run, one for switch dependent run), constant
blocks, a memory block and a subsystem that is used for cycle counting of the
tests. Input is sensor signal and the output is valve driver signal. The constant
blocks are used for parameter setting for pause, reset signal (0 for activating, 1 for
deactivating the command) , switch dependence variable (0 for independent, 1 for
switch dependent), initial position open-closed variable (0 for closed, 1 for open)
and delay and waiting timings. Time values are in the units of miliseconds.
Memory block outputs the input from the previous time step and is used as a
counter for delay and waiting time of valve motion. Embedded function blocks
include the valve algorithm whose flowchart can be seen in Figure 3.9.
Figure 3.9 – Valve Driver Block Diagram
14
This algorithm simply checks the connected sensor signal and outputs the
valve driver signal according to the predetermined timings and sequences. The
model of the valve driver subsytem can be seen in Figure 3.10.
Figure 3.10 – Valve Driver Flowchart
15
3.1.5.3. Cycle Counting Subsystem
This subsystem is connected to the actuator subsystems and is used for
counting the cycles of the actuators, cutting actuator output signal when test is
finished and resetting the cycle number when a new test starts. Although one’s is
enough, all active actuators’ cycle is counted since the configuration is user
dependent and can change any time. The model block diagram of the cycle
counting system for motor driver can be seen in Figure 3.11.
Figure 3.11 – Cycle Counting Subsystem model block diagram
For motor, driver signal, reset signal and direction value are inputs, driver
signal is output, whereas for valve, driver signal and reset signal is input and
driver signal is output for the subsytem. For counting purpose, a triggered
subsytem which executes each time a trigger occurs, is used inside. By using a
falling type trigger, subsytem is triggered when control signal falls from a positive
value to zero. For motor, the control signal is adjusted to be 1 for forward
direction, 0 for reverse direction, whereas for valve, the control signal is the same
as valve driver signal, 1 for open position, 0 for close position of the valve. So,
16
every single full motion of an actuator leads to one cycle count. When test
finishes, in other words cycles are completed for the actuators, by the help of the
switch block, the actuator signals are cut and 0 value is given as actuator driver
signal.
3.2. User Interface
As mentioned before, Borland C++ Builder is used to design the user
interface which provides the user two basic functions which are test design and
test application. Designing a user friendly interface in Turkish, tests can be
designed and applied even in the technician level. The genaral structure of the
user interface can be seen in Figure 3.12.
Figure 3.12 – User Interface general structure
17
3.2.1. Test Design
By deciding to replace the old limited PLC system with a new system,
Ford OTOSAN Product Development Divison’s one of the important aim is to
have a flexible and ready to develop structure regarding vehicle life tests. What is
signified by this is to have a structure that gives opportunity to design new tests or
to adapt pre-designed tests conforming changing needs.
As mentioned before, test software is composed of two parts which are the
Simulink model running behind and the user interface. Simulink model which was
explained detailly in previous section, is constructed in such a flexible manner
that a new test can be designed by changing few parameters in the model over the
user interface. Following this design process, it is possible to simulate the
designed test on a simulation screen in the interface to see how it will work in the
application. In case of misadjusting a parameter or misarranging actuator
sequence or any undesirable setting in a designed test, unexpected situation stated
easily in simulation stage before running the test. This feature of the software
gains significance when a designed test becomes complicated which means it has
many actuators and sensors. Because any unseen mistake in the design stage may
cause damage in the test setup in the application stage.
Test information about the tests, actuators and sensors added to the test,
channels and boards that they are connected to in the control hardware and
parameters set by the user, have to be kept somewhere in order to apply the
designed test many times without entering data every time. Therefore, Microsoft
Access database program is used together with C++ Builder. By using related
components in C++Builder, user interface can easily connect to the database file
and append or retrieve information about the test automatically.
3.2.1.1. Test Information Entry
At the initial step of the test design, basic information about the test has to
be entered. These are the name of the test, test procedure number which is related
18
to the procedure standart describing equipments used and operational instrcutions,
vehicle type on which the test is applied, the name of related test engineer and
technician, and finally planned total cycle of the test. The program connects to the
database to check whether a test with the same name has been designed before or
not. This is to avoid confusions such as having two tests with the same name. If
nothing wrong with that situation, all the test information is appended to a table in
the database. Test information entry flowchart can be seen in Figure 3.13.
Figure 3.13 – Test Information Entry Flowchart
3.2.1.2. Actuator-Sensor Addition
The next step is to determine actuators and sensors for the test. For any
test setup electric motors with drivers, pneumatic cylinders with valves are used
as actuators whereas mechanical limit switches, inductive switches are used as
sensors. All the actuators and sensors are labeled with numbers so as to avoid
confusion and this makes easy to follow them physically through user interface.
The number of actuators and sensors in the database is limited with the maximum
19
channel capacity that actuators and sensors can be connected to. So, the database
is arranged in such a flexible structure that actuators and sensors can be added to
the tests in any combination without exceeding the system limit which is 8 for
motor drivers, 16 for pneumatic valves and 32 for mechanical and inductive
switches. Actuator/Sensor addition flowchart can be seen in Figure 3.14.
Figure 3.14 – Actuator/Sensor Addition Flowchart
After retrieving an actuator or a sensor from the database, its location in
other words its physical place in the setup is determined and then the channel that
the actuator and sensor is connected to, is selected. It is important to connect the
actuator or the sensor to that particular channel physically while connecting it
through user interface. Before completing this actuator/sensor addition process to
the new test, the program makes two inspections by scanning database. First one
20
is to control whether that actuator or sensor is being used in another test or not
and the other is to check whether the channel is being occupied by an another
actuator/sensor or not. After that, if no overlaps exist, the information about the
actuator/sensor related to the test is appended to tha database.
3.2.1.3. Test Parameter Setting
After actuator/sensor addition, parameters have to be set according to the
test scenario. What determined by these parameters are running sequences and
waiting times of the actuators, speed of the motors, switches with which the
actuators run in accordance, etc. The meaning and the role of each parameter in
the test scenario are explained detailly in the section where the test model is
described. So, they are not repeated here.
After entering all needed test parameters about the designed test via user
interface, they are appended to the database under that particular test’s section.
They are retrieved from the database and loaded to the target computer to set the
related parameters of the model when the designed test is to run. Test information
entry flowchart can be seen in Figure 3.15.
Figure 3.15 – Parameter setting Flowchart
21
3.2.1.4. Test Simulation
As indicated before, there is a simulation screen before completing the test
design process. This screen visualizes the designed test according to selected
actuators and sensors and parameters set. It gives opportunity the user to see
running sequences and duty times of the actuators, to control compatibility to the
planned test scenario. So, possible mistakes or critical points can be seen and
necessary changes can be done in advance, potential risks that can lead to physical
damages in the test setup during the test run, are eliminated. Although the test
algorithm is same as the algorithm in the model, the simulation has no connection
with the physical system, so no signals come in or go out of the system during
simulation. Due to this situation, some assumpstions are made to simulate the
physical system. A motor’s speed and running distance interval, a pneumatic
cylinder’s stroke time are assumed to be constant. Because, these depend on
actuator’s specifications and sensor’s physical locations in the test setup. They
don’t affect a test’s scenario, working sequences of actuators that is critical to
check for a user, they just have an effect on total cycle time of the test. Test
simulation screen can be seen in Figure 3.16.
Figure 3.16 – Test Simulation Screen
22
Completing these steps, test information entry, actuator/sensor addition,
test parameter setting and test simulation, a new test is designed and ready to run.
All the information, parameters and settings about a designed test can be accessed
and any changes can be made whenever desired.
3.2.1. Test Application
As mentioned in the beginning of this section, test system is composed of
three parts which are a host computer where the user interface exists, a target
computer in other words PC/104 onto which the target application file including
test algorithms are loaded and the test setup which the target computer
communicates, drives actuators and reads signals from sensors. All operations
related to the test application are implemented through the user interface which
runs on host computer. xPC Target functions are directly used to communicate the
target computer, control the system and tests, in other words test application
purposes.
3.2.1.1. System Control:
System control is composed of two main functions which are starting and
stoping the system. In order to control the test hardware, run, monitor or stop
tests, system has to be started which is in 3 steps. Firstly, a connection between
host and target computer is established, then target application file (TAF) which is
compiled and prepared in MATLAB, has to be loaded onto target computer from
host computer and finally this target application has to be started to run on the
target computer. Once these steps are followed and system is started to run, there
is no need to repeat loading and running the target application file (TAF) until
rebooting the target computer, even if the host computer is switched off. System
control flowchart can be seen in Figure 3.17.
23
Figure 3.17 – System Control Flowchart
3.2.1.2. Test Control:
Connection between host and target computer has to be established and the
target application has to be running on the target computer so as to control tests.
What defined by the test control are running, stopping and continuing predesigned tests. When a test is to run, related information about the test, name,
procedure and cycle number, connected actuators and sensors, etc. are loaded
from the database to the test screen. What meant by the test run is cyclic running
of actuators according to the designed test scenario. The test is started to run by
setting its paramaters which are determined in test’s design stage into target
application file (TAF). This parameter change is applied on the test related
actuator algorithms in the target model. There is always a test name control in
order to prevent re-running the same test and avoid confusion. When test stop is
24
concerned, there are two options to select which are stopping the test at the end of
its cycle and stopping the test immediately. If a planned stop is aimed, in order to
take measurements for instance, first stop, if there is an emergency situation like
danger of damage for the test setup or injury for workers, second type stop is
chosen. These two actions again are accomplished by setting related parameter in
the target application through user interface. Tests which stopped either normally
or urgently can be continued to run by following similar procedure to the stop
procedure. Tests which complete their total cycle stop automatically without any
interference. Test control flowchart can be seen in Figure 3.18.
Figure 3.18 – Test Control Flowchart
25
3.2.1.3. Test Monitor:
Cycle and state information about the tests are to monitor in the program.
These information are not continuously updated on the screen in order not to busy
the target host communication every time, moreover, monitored information are
not so critical to follow continuously. They are monitored when needed to see by
the user. This update is done in two situations. First one is when the program, the
user interface is closed and opened again, so information about the tests on the
screen are cleared. Secondly when user interface is still working, in order to
update test information to the current time. Test monitor flowchart can be seen in
Figure 3.19.
Figure 3.19 – Test Monitor Flowchart
26
3.2.1.4. Measurements:
Measurements have a significant role in vehicle cycle life tests, since they
help to understand the behaviour of the tested part under cyclic load conditions at
different cycles. So, results acquired from the measurements guide the engineers
to make changes and developments on a design. Measurements are taken
manually and the data are entered into the program. Two types of measurements
are applied which are effort and margin/flushness especially for vehicle door tests.
Effort measurements are for generally door latching and margin/flushness
measurements are for body parts. In the program, if a measurement is to be taken
in a test, that test has to be displayed on the test screen in advance. After entering
data about the measurement which are description or location and values, they are
appended to the database. The number of measurements that can be taken for
effort is 3, because the average of them may be needed for a better result, whereas
the number for margin/flushness is 9 which is for different locations on a body
part. Test measurements flowchart can be seen in Figure 3.20.
Figure 3.20 – Test Measurements Flowchart
27
3.2.1.5. Report:
The program generates two types of reports which are daily report and test
summary report. Daily report presents data in a systematic manner which informs
the user about active tests’ progress. The related information which are test name,
request and body number, present and total cycle, test start, estimated and actual
finish date if it is finished, state of the tests (running, stopped, finished), daily
cycle numbers are retrieved from the database, then Microsoft Excel program is
opened and finally these data are located in an Excel table in a predetermined
format. Report flowchart can be seen in Figure 3.21.
Figure 3.21 – Report Flowchart
28
All these procedures are impelemented automatically through the user
interface. progress related to active tests.following and they compose an archive
for future reference. On the other hand, by following the same logic, test report is
prepared including test information, active test duration charts, test measurements
and daily test cycle history when the test is finished.These reports not only guide
to follow test progress and results, but they form an test archive to refer in the
future when needed.
29