Hardware Reference
In-Depth Information
The second of the design phases involves defining the various program mod-
ules and procedures. These will often be associated with the individual stages
of the flowchart model (or its equivalent) and may be separately documented.
The action of each module can be summarized using structured English (or
pseudo code
). Each line of
pseudo code
will generally correspond to one, or
more, lines of program code.
As an example, consider the case of a process employed within a grain drying
plant which is responsible for filling a hopper from a conveyor. In structured
English (
pseudo code
) the process can be summarized along the following
lines:
Begin
Close hopper outlet
Start conveyor
While hopper not full
Run conveyor
EndWhile
Stop conveyor
End
The equivalent flowchart for the hopper filling process is shown in Figure 4.6
(note the use of a conditional loop).
Steps (5), (6), and (7) of the software development cycle involve routine
program entry, testing, and debugging. All but the simplest of programs should
be developed on a modular basis making it possible to work on a single mod-
ule (procedure) at a time. Modules can also be drawn from a standard library
whenever one is available. Furthermore, whenever a module has been success-
fully developed and tested, it should be added to the appropriate library so that
it is available for future use in other programs. A routine which will read a
remote keypad and return its status to the system might, for example, be useful
in a variety of applications.
Having produced a functional control program, the next stage is implemen-
tation. Since the software will almost certainly have been developed within
a controlled environment removed from the environment in which it is to be
finally imbedded, it will generally be necessary to install the software and carry
out some rigorous testing with real (rather than simulated) inputs and/or out-
puts. This is often the most critical phase in the entire project cycle and it will
sometimes reveal problems which were not foreseen during the earlier stages.
Problems and difficulties are often associated with:
Figure 4.6
Flowchart
for the hopper
filling process
●
Speed of response
:
the real-world system may be too fast or too slow in
comparison with that of the simulated development
environment.
●
Noise
:
signals in the real-world environment are rarely ideal and often
contain a significant amount of noise.
As an example, a system installed to monitor the flow of gas along a pipeline
behaved erratically when an apparently functional (and fully debugged) pro-
gram was installed within its industrial PC-based controller. Sixteen remote
sensors (based on rotating vanes) were used to sample the flow rate at various
