ML20099J045
| ML20099J045 | |
| Person / Time | |
|---|---|
| Site: | 05000601 |
| Issue date: | 11/30/1984 |
| From: | WESTINGHOUSE ELECTRIC COMPANY, DIV OF CBS CORP. |
| To: | |
| Shared Package | |
| ML19269B210 | List:
|
| References | |
| NUDOCS 8503190578 | |
| Download: ML20099J045 (11) | |
Text
. . -
O
- 78. WESTINGHOUSE DESIGN APPROACH FOR SOFTWARE DEVELOPMENT FOR THE INTEGRATED PROTECTION SYSTEM Software instructions will be stored in read-only memory and hence will not be alterable by the hardware system.
This section describes the Westinghouse approach which will be used in the development of the sof tware for use in the Integrated Protection System. The following areas are covered in this section:
~
Description of the Modularity Concept (Section 78-1)
Control Over Nesting and Interrupts (Section 78-2)
System Software Organization (Section 7B-3)
Programing Language (Section 78-4)
Software Test and Verification (Section 78-5)
Software Documentation (Section 78-6)
Applicable Industry Standards (Section 7B-7)
The Westinghouse approach provides a very structured, disciplined, and systematic program for all phases of the software design from system specification, through design and coding, to testing, verifying, and documenting the final package.
78.1 DESCRIPTION
OF MODULARITY CONCEPT i
i In order to ensure that the software performs .its design function, constraints will be applied to the sof tware structure. The most ef fective method is to separate the software into sections called nodules which have clearly specified interfaces.
A module is defined as the smallest element of sof tware independently tested
! O and stored in the library. A module has well defined interfaces and a limited number of states. Module state in this context means a nodule function. The O
WAPWR-I&C/EP 78-1 NOVEMBER, 1984 2084e:1d 8503190578 850227 PDR ADOCK 05000601 K PDR
O statement expresses the requirement that module complexity should be limited in such a way as to make the module manageable and easily understandable as, for example, in the execution of a decision table. Limiting module state is a principle rather than an absolute number. A module may be considered as a function routine or a subroutine used in a repeated manner. A module represents a mathamatical or logical expression. A module will have only one entry and one exit point. A module may name other modules to be called as a function or subroutine procedure, but this " nesting" will be constrained as discussed in Section 78.2. A collection of several modules can be considered as another level of module, per se, if it also performs a well defined task and has only one entry and exit point. In other words, the modular concept can be generalized by applying the same requirements to varying levels of software.
The modular approach when used in conjunction with structured programming and top-dcwn development offers several advantages (see Section B-3). Top-down development minimizes the writing of any code for which testing is dependent on another code not yet written or one for which data is not yet available.
It minimizes the requirement to integrate many pieces of independent code and allows testing to be conducted in parallel with the design phase. Structured progranrning imposes a strict procedure on writing the module software and on the integration of modules into the system.
The software generation procedure is shown in block-diagram form in Figure 7B-1.
In order to increase reliability, extensive use will be made of the library concept. The library will include collections of verified modules which will be used by higher level modules. Stringent acceptance requirements will be placed on the programs before they are entered in the library. Similarly, procedures will ensure that only authorized modifications are nede to the modules in the library. The linking of library modules into a program will be done automatically by a linking leader utility program. The library editor will enable the listing of the contents of a library, deleting, inserting or replacing a module, or merging two library files into a single one.
WAPWR-I&C/EP 7B-2 NOVEMBER, 1984 2084e:ld
O The use of libraries allows for the orderly development, release, and maintenance of the protection system software. In the development phase, the sof tware module source is written, the module is assembled, and the module is
tested. If necessary, it will be modified, reassembled, and retested. When the programer is satisfied, the module is reviewed by the librarian for proper documentation and coding style. When satisfied, the librarian assigns to the module official identification and files the source listing. The
-module is now ready for verification. When the verification team is satisfied The librarian
~
with tha performance of the module, it is ready for release.
.. assigns it revision number 00 and the relocatable object (the assembler output) of the module is placed on the module library. All further revisions increment the revision number and must be documented in suf ficient detail to reproduce the transition from one revision level to the next. All revision levels must be verified by the verification team.
Examples of several modules of dif ferent complexity are:
l 1. Multiply / divide module
- 2. Lead / lag compensation module
! 3. DNBR calculation module The module described in 3 is a functional mot.ule, which may consist of several modules of type 2. In turn, modules of type 2 will consist of several modules
! of type 1. Module 1 is .the basic software module.
s ,.
l m l
78.2 CONTROL OVER NESTING AND INTERRUPTS In real-time software systems, such as for the protection system, the number of a110w3ble interrupts has to be limited. This constraint is introduced since'it is extremely difficult to test and verify sof tware in the presence of interrupts. Interrupts in general have a random nature. By limiting the number of interrupt levels, the cases when the interrupt actually occurs can ,
be accounted for during the test and verification process. The Westinghouse integrated protection system software, will use no software interrupts.
Software interrupt, in this context, refers to an interrupt that is always 1
t O WAPWR-I&C/EP 78-3 NOVEMBER, 1984 20a4e:1d
made by hardware. In conventional systems, the sof tware manages interrupt O
processing by saving the program counter, comparing priorities, and returning f rom interrupt. The IPS will limit interrupt in several ways. Firstly, the number of interrupts will be limited to the minimum number necessary to halt the program for such conditions as power failure, operator reset, or memory priority error. Secondly, there will be only a single level of interrupt.
Thirdly, the interrupt will cause the program to branch into a specific location where execution continues without returning to the location where the interrupt occurred.
A power up sequence will be accomplished through hardware implementation and will serve to initialize the program upon return of power.
To enhance the readability of the program and to fully utilize the structured programing approach, the nesting of subroutines will be controlled. By leaving the number of nesting subroutines limited, testing and verification are more easily planned and executed, both by comparison to the functional requirements and by execution on the computer.
The single entry / single exit requirement on modules will be met by requiring called subroutines to always return to the calling module. Nesting subroutines will be controlled by this rule. Nesting refers to a subroutine which is being executed and in turn, calls another subroutine. Return from a subroutine will be made to the calling module at the first executable i statement after the subroutine call. Figure 7B-2 gives a pictorial l
- representation of the sof tware nesting requirements. Note that each called subroutine always returns to the module which called it.
Re-entering terms refers to ) subroutine which is being executed, and before l its execution is completed, the same subroutine is entered again. Typically, this situation can occur in two cases. If the program is recursive, then a subroutine can call itself, either directly or through a second time before the first execution was completed. Both recursive programing and interrupt nesting will be forbidden.
O WAPWR-I&C/EP 78-4 NOVEMBER, 1984 2084e:1d
h a
78.3 SYSTEM SOFTWARE ORGANIZATION The protection system software will be based on the principles of top-down development, structured progransning, and modularity. Basically, top-down programming means that the entire program is first layed out in one top segment. At the " top" the sof tware will be specified in general terms. Once this is done, the next level of nodule will be outlined. The process is repeated as levels of program details are relegated to various levels of modules. The process is repeated until the software specification is satisfied.
Structured programming is both a design and coding technique. It encourages code readability, enforces modularity, encourages changeability, enhances maintainability, simplifies testing and permits improved manageability and accountability.
4 The protection system sof tware will be. organized in a simple chain structure.
Figure 78-3 depicts this structure.
The modules will be cyclically executed asynchronously. The program sequences
'through the chain advancing from module to module. No traceback external to
- modules will be permitted and there will be no nesting of interrupts as was noted in Section 78.2. The operating system, as it is known in minicomputer-based systems, will not exist in the protection system. The chain . program, as described, replaces the operating system. To further elaborate on this point, the data bus and its controller processor are not performing functions usually attributed. to an operating system. This can be assured because the trip function processors do not require the operation of the data bus controller to perf onn the trip functions. The data bus is several two ported random access memories (RAM) connected in series. The data bus is controlled by a dedicated microprocessor which accesses information d f rom one of the two memory ports. The function processors access information f rom the other port as - shown in Figure 7B-4. All processors have a single loop execution sequence. There is no synchronization of the data bus WAPWR-I&C/EP 7B-5 NOVEMBER,1984 2084e
- 1d
controller processor and the function processors. Information is accessed by O l all processors with normal memory references. Contention between processors for the shared memory is resolved by the two ported memory card.
78.4 PROGRAMMING LANGUAGE O ,
I The most important software tool available to the programmer is the programming language. Most of the programming will be done using a high level language. Sections of the program which operate directly with external hardware or which require a very high speed will be programmed in assembly l language. The compiler will output a comprehensive listing which includes the
, source code together with the assembly language code that was generated for l
each statement. An option to print an alphabetized list of variables and procedures with reference to their location in the program text is available.
Readability is the key feature of a good programing language. The language will include control structures (IF THEN ELSE, D0 WHILE, etc.) to encourage structured programming and to discourage excessive use of Go To statements.
The following features of the high level languaga will aid in the development and maintenance of reliable software:
- 1. Structured programming support and software modularity.
- 2. Explicit module interfaces with single-entry and single-exit.
l l
- 3. Eacy to learn and use.
- 4. Self-documenting.
l S. Support of noncontiguous memory addressed such as read-only memory, read-write memory, and memory mapped input / output.
- 6. Convenient access to system software and services.
O O
WAPWR-I&C/EP 7B-6 NOVEMBER, 1984 2084e:1d ;
1 I
- 7. Provision for syntax and context checking.
- 8. Support of numerous data structures and variable types such as bits,
/ bytes (8 bits), integers (16 bits), and real numbers (32 bits).
- 9. Support multidimensional arrays.
,Q 10. Language extensions.
U The programing language can encourage good programming practices but cannot enforce them. The additional programming style guidelines will be used to improve the readability and reliability of the program.
- 1. The size of each software module will be limited to a few pages of code.
- 2. Simple control structures will be used and Go To statements will be avoided.
- 3. All subroutines will return to the caller directly following the call.
-4. All subroutines will have single-entry and single-exit. ,
- 5. Interrupts will.not be permitted.
7B.5 SOFTWARE TEST AND VERIFICATION Verification is intended to provide an adequate level of assurance that the l
software actually performs the functions which are specified by the functional requirements. It gives assurance that the protection system sof tware meets its specification and will perform its protection function.
WAPWR-I&C/EP 78-7 NOVEMBER, 1984 2084e:1d
(a.c O
O O
i O
O FIGURE 7B-l' SOFTWARE GENERATOR BLOCK DIAGRAt EAPWR-I&C/EP unurunro ice,
l l
i
. MAIN _
^ '
SEQUENCE u
j I P CALL I l
l t s I
l l'
CALL 2 a
i l CALL 3 41 i , _ _ _ i1 - . . .,
I- I e
- i Call N
8 I 1 L_______a l
l FIGURE 7B-2 SOFTWARE NESTING DIAGRAM i
i l
WAPWR-!&C/EP NOVEMBER. 19At.
i
' -.,- ...- ,.~...- . . - , . _ - - - - _ _ _ _ . . . . - _ - . . - - - - - _ , - _ , _ , -... _ - -., .-- . - . . . - _ . . . - - - , - ,
e O
O O
Y A
l i r B
O
-u t
C l
Md 0
O l
FIGURE 78-3 SYSTEM SOFTWARE ORGANIZATION O
HAPWR-I&C/EP NOVEMBER. 1984
. ~ _ .
_ . _ .t
- i
- i. i I
+ ,
a f 1
i' i I
+. ;
t ,
e h '
+ ,
- l i .
I t
i; '
4
- m l-
- (a,c) ,
k 1
- i I J
l-1
!O i
t i
.: t i
t f
j.
I 1-4 l
t u
I i,
e I
i
, . t I i
). e i r
1 1
t-e i
9 !
I f
r I l
!. r i ,
t FIGURE 7B-4 IPS DATA BUS c I
I i
i' F
_ _ - - - - . , - - ___ _ _ ---- _ w_.---