87-2602 TECHNOLOGY REQUIREMENTS OF INTEGRATED, CRITICAL DIGITAL

FLIGHT SYSTEMS

Anthony DeThomas, PhD* AFWAL/FIGX WPAFB, OH

Abstract

The architectural complexity and the fault tolerance requirements of the control systems for the next generation of aircraft are much higher than for current vehicles. Appropriate method- ologies, tools, techniques and environments must be developed which can effectively support those advanced systems throughout the life cycle. The characteristics of the environment required to support the next generation system are identified. The critical technology areas are architecture design and analysis, and software development and verification. Promising techniques are described which can effectively support development of integrated systems.

1.0 Introduction

The next generation of fighters require integrated control systems to achieve the desired level of maneuverfng performance and weapon delivery capability. Configurations with thrust vectoring, for example, incorporate highly inte- grated flight and propulsion systems control. Fire Control Systems can also be integrated with Flight Control Systems. Technologists are now exploring the concept of an integrated Vehicle Management System (VMS) which integrates all the flight critical subsystems: Flight Control, Pro- pulsion Control, Power Management and Control, Thermal Management, Fuel Hanagement and Environ- mental Controls. At the same time, there will continue to be a certain degree of integration and interface with the avionics systems, such as integrated sensors for trajectory and flight path control. The functional, composition for these integrated systems is shown in Fig. 1. A generic architecture for the VMS system is shown in Fig. 2. The VMS Integrated Management Processor provides a centralized management function for all controls and. utility functions and the integration of all. information generated by each subsystem. By integrating, controlling and managing all functions and information, benefits in vehicle performance, efficiency of operation, reliability, fault tolerance and maintenance/diagnostics can be achieved.

In the near future, flight critical research and technology progress must emphasize techniques to improve the design, development and veriff- catfon of these high1.y integrated digital control systems. Main issues to be examined are the

t This work was performed by Sparta and partially funded under a contract from the Flight Dynamics Laboratofy

Senior Member AlAA * * Member AIM

Thls paper is declared a work of the U.S. Government and is not subject to copyright protection in the United States.

Pio de Feo, PhD*" Sparta, Inc.

Laguna Hills, CA

TRAJECTORY OPTIMIZATION ENVIRONMENTAL ENGINE CONTROL

COMPUTER 7 REDUNDANT

FLYING OUALITIES

GUIDANCE

Fig. 1 Advanced integrated control system concept

Fig. 2 Generic VMS Architecture

partitioning of functions, definition of the architecture and determination of necessary levels of redundancy, real-time testing with the target machines in a simulator facility, ironhird testing and then flight test. Testing is performed to assure that a1 l aircraf t performance parameters are met and that system mode and fault logic performs as specified. No standardize$ tools or enviro~ments are specified for this process. This paper addresses some of the technology requirements for implementing such systems.

2.0 Digital Flight Control System Software Configuration

Current conff gurations of Digital Flight Systems (DFS) for military aircraft have many similarities with commercial DFS. In both cases, the increasing complexity anc! criticality has resulted in redundant, fault tolerant architec- tures (quad, triplex or dual dual, depending on the required level of fault tolerance ) .

Concequently the technology requirements of the two applications 2re also very similiar with only few exc~ptions: a) highly integrated military configuratioric require additional capabiljties for supporting the design and analysi~ of complex architectures, and b) the technology requirements of military DFS is ccncistent with military stan- dards, like the Ada software language, the 1553 bus protocol, and the 1750 instruction set. Diffe~ent standards might apply to commercial cppli catio~?. Because of the many eristing commowljties, the current development technology and Software Configuration for military and commercial applications are lrery similar. They are analy7ed in the next sections of this paper to estahlish a benchmark of current requirements and of available technology. The configuration of the advanced DFS and the corresponding technology requirements are then estahlished and methods of integrating currmt environments and advavced techniquts are proposed.

2 . 1 Software Characteristics

The typical DFS software structure is by design very simple, given thc criticality of application. It implies the repetitive erecution of sequences of application tasks, at fixed execution rates multiple of a basic frequency. Common values of the basic frequency are ?0C, 100, 80, and 60 Hz. The application tasks are not interruptable; once initiated they must execute to completion, within the allocated time. Jf addi- tiowl processing time is available, low priority, fnterruptable tasks are euecuted. This commonly used foreground/barkground structure makes optimum use of the available resources and, at the same time, it significant1 y reduces the complexity of critical software modules.

The memory requirements of the flight soft- ware varies from case to case, typically from 10K to 50K. The software can be partitioned into five major categories according to the predominant algorithmic content and function performed.

1 Application. It implements computations for the vehicle control, guidance and navigation, and the related pilot displays.

2) Logic. It performs mode switching logic.

3 ) Testing. Tt tmplements failure detection snd isolation algorithms, and reconfigurat'on management strategies.

110. It performs data transmission, 4 , - display, hadling and formatting.

5) Executive. It perform initializations procedures, timing, scheduling, and device dri- VfTS .

The relative magnitude of each category varies from case to case. Average values for military and commercial applications are given in Table I .

An information useful for establishing the technology requirements of DFS is the history of error data during the life cycle of each system. High quality data however are rare because: a) most programs do not establish a formal documents-

Table 1 Software Algorithmic Content

APPLJCATION 25% LOGIC 20% TESTING 20% I/O h EXECUTIVE 2C% MISCELLANEA 15%

tion process for software errors; b ) mjssing standard procedures for error classification and documentation; and c) most companies consider the data as proprietary. An estimate of or dis- tribution, based on feu published ~Iat3~'' docu- ments of airframers and avionics houses, and informal conversation of the authors with DFS sortware developers, is given in Table 2.

Table 2 Software Error Distr~bution

ESOR CATEGORY FREQUENCY

COMPUTATIONAL 10% LOG I C 25% DATA EANDLING 35% INTERFACES 10% MISCELM'FA 20%

The errors most difficult to detect and costly to correct are generated in the early phases of the development process. They include: missing, misinterpreted or incorrect requirements, software/hardware mismatches, and design errors, etc. It is important to notice that the computa- tional error has the lowest frequency of occurance (lox). This results from two factors, 1) the relative si7e of the application software is small (See Table 11, and 2 ) the technology to develop and verify application software is well understood and developed. Other error categories can be attributed mostly to fault tolerance requirements and architecture complexities. The next genera- tion of advanced DFS will have higher fault tolerance requirements and architecture complexity than current systems. The complexity of logic, testing and interface algorithms will also be correspondingl-y higher. The most critical tech- nology needs of the advanced DFS are in those areas. The techniques proposed address these specific critical issues.

2.2 Current Development Technology

A typical current software development and verification process is supported by two distinct environments.

The first environment, usually hosted in a main frame o; mini computer operating in batch or interactive mode, is applicable to a broad cate- gory of DFS programs and provides general purpose capabilities in the following areas:

1) Control laws analysis. Tools are provided which support design and analysls of continuous and discrete control systems using classical and modern techniques. An example is frequency

response and root locus analysis to assess the performance and stability of classical control systems. In the case of optimal control systems, eigenvalues/eigenvector analysis is used for the same purpose.

2) Reliabilitv and Failure Mode/Effects Analysis. Reliability analysis is used to eval- uate the probability of a svstem to successfully perform specific tasks. Failure Kode and Effects Analysis (FPIFA) establisllrs the effects of system components failures on overall system performance. The combined results of the two analyses is to verify that any failure, or combination of fail- ures, which could have catastrophic consequences, has only a very low and acceptable probability of occurrence.

3 ) Software development. Software tools support several software development tasks, such as software design and documentation, code genera- tion, and configuration management. The tools which support the critical task of code generation are required to be very mature; com- pil-ers, assemblers and liners fall in this cate- gory.

The second environment has the capability cf exercising the flight software in real time. This environment is typically developed for and dedica- ted to a single program. It incltldes essential elements of the Flight Control System (FCS), and the airplane dynamics, so that closed loop analy- sis can be made. Some FCS components are simulat- ed, some are emulated and other are directly included in the environment. Typically, the flight computer hardware is incl-uded so that the flight software can be exercised in a representa- tive environment. The simulation of the aircraft dynamics and of those FCS hardware components that would be impractical to include in the environ- ment, are implemented in a dedicated host process-. or linked to the flight computers. These environ- Dents play an extremely jmpcrtant role in DFS development.

The advanced technologies required by the next generation of DFS must be effectively inte- grated with current environments.

3.0 Technology Needs

The techniques described address critical technology needs in the areas of system architec- ture design and analysis, and software development and verification. They are intended to be inte- grated with existing and new technologies in cost effective and easy to use environments.

3.1 Advanced Architecture Analysis Methods

The selection of a DFS configuration is the result of difficult compromises among several, and often contrasting, requirements and constraints. The designer needs tools for simulating and analyzing the relative merits of competing con- figurations, very early in the development cycle, prj-or to committing to any specific configuration. Two different methods of analysis are proposed. The first method, is based on the complexity analysis of the topography of the architecture, and of the structure or the software. The second method is based on a non real time simulation of the actual sequence of events.

3.1.1 Complexity Metrics

Complexity metrics can support software code, software deslgn and system architecture analysis. A most promising approach is the graph theory based McCabe's metrics, which calculates a Cyclo- matic Number (CN) from the difference ??tween the number of nodes and the number of edges . A node is a straight line segment of code, a functionally cohesive software module or an hardware inhedded function, in case of software code, soitware design, and system architecture analysis, respec- tively. IXges represent in a11 cases control transfers. The CN represents the minimum number of independent logical paths. It !s a function of the deficient structure only, and it increases if control flow is added.

\hen the McCahe's model is applied to PFS lrchitecture the real time execution of the software embedded in each processor must be considered. The following factors must be con- sidered:

1) Flight software executes at different rates, depeding on the dynamics of the control algorithms. This charateristic can be rnodele? hy grouping the application modu'es according to the required executton rates. Then a cyclomati c number can be determined for each group for application modules. The overall cyclomatic number can then be determined by assigning to each individual number a weight equal to the frequency of execution of the corresponding group, and computing the weighted Fverage of all numbers.

2 ) Advanced, multimode, flight control systems perform different tasks depending on the aircraft flight and mission mode. Then a differ- ent ryclomatic number must he deternjned based on the application modules which are active in each possible operational mode.

3) Some low priority application modules can be interrupted, which increase the complexity of the control flow and the correspondent CTI. P a analysis must then be made to determine the frequency of interruptions of each module. Each interruption increases the CN by one.

4) Distributed architectures have - - ' pe r re oi complexity higher than a single processor because they require additional communication for exchang- ing data, time synchroni7ation, failure detection and reconfiguration. The added control flow complexity is reflected by higher CNs.

The architecture and software complexity metrics are static tools which czn be applied throughout system design phases in a mapner that permits the inclusion of more from c'esign details as they become available. They can he effectively utilized for early development Phases for compar- ing competitive architecture and analyzing the effects of design modifications.

3.1 . : Simulation Techniques

A measure of the quality of the architecture is achieved from dynamic parmeters such as the distribution of the computation load among pro- cessors, the utilization of, and competion for, ~hared resources such as common busses, and other

+ jme sensitive parameters. The parameters can be ~stimated by simuleting, in a non real time environment, the relevant sequences of tasks to be performed, and by keeping track for the time needed by the allocated rcsources to perform those tasks. To generate these data, the environment must be able to simulate: procedural processes, such as the highly structured flight control algorithms which execute under rigid, predetermin- ed time sequences; parallel processing, as in the case of redundant, distributed configurations; shared resources, such as common busses; and, in those cases which require detailed analysis of the time sequences of events the executive logic which controls the execution flow within each processor. The output of these performance simulation runs are : statistics of resource utilization and detailed tjme sequences events like the exact tining of data exchange among redundant proces- sors. Most of the elements included in the performance simulation environment just described have been developed for, and effectively used in, npplic~5jon such as Command, Control and Comrnuni- cation . This type of simulation has not been applied to DFS because of the relatively simple configuration structures of current systems. On the other hand, the architectural complexities of the next generation DFS justifies the need for those capabilities.

The simulations and the complexity metrics tools, described in this section of the paper, can be hosted in the same environments which currently support control law development and FEY? analysis, and sof torare development.

3.2 Software Verification

Software is often the most critical element in terms of development, verification and main- tenance cost, and software is a major contributor to the overall failure rate of current DFS. The current, state of the art, software test strate- gies are structured to exercize all independent software logical paths. A removal of all implemen- tation faults, however, can not be guaranteed even if 100% test coverage is achieved. In fact failures can still occur as a result of unusual logical or timing sequences of events. Then if one of these combinations should occur in flight, a system failure could result with unpredictable consequences.

To achieve a high level of confidence that all the failure triggering combinations are detected, a Stress Test technique is described which is a highly automated, very effective way to test cede with an extremely large number of test data sets while it is executing in the target processor (s). Several properties of the Software can be Stress Tested :

1) Data Stress Test. This test verifies the correct alg~rithmic(~)execution of a software application function .

2 ) Timing Stress Test. This test measures the statistical distribution of the computational and transport delays between the time variables are set in one processor and the time they are

used in other processors; and it verifies that the delays do not exceed predetermined maximum values.

3) Partitioning Stress Test. This test verifies the partitioning between two functions. Function "A" is partitioned from function "B" if not action of function "B" can cause a failure of function "A".

3.2.1 Data Stress Test

The essence of this test is to execute critical software functions in the flight computer (target computer) concurrently with the execution of alternate benchmark versions in a host machine. To achieve the full benefit of a dual independent and dissimilar implementation, the benchmark is coded directly from the design document. The same exhaustive input sequence of data, within and outside the specification boundaries of each function, are then used to exercise both imple- mentations. Then errors in either implementation will result in different outputs, under certain test conditions, because it is extremely impro- bable that the same errors are made in both versions. The benchmark implementation, hosted in a Simulation Computer, can be made quite simple, compared to the flight version, because of the lack of hardware constraints especially in the 110 portion; and because of the capability of using floating point arithmetic, rather than integer as commonly done in DFS for speed of execution. Because of the extremely large number of test data involved, it is necessary to automate the entire Stress Testing process, including:

1) Execution control of the target and benchmark programs ;

2 ) Generation of the test data set;

3) Analysis and documentation of results;

4) Development of benchmark programs.

Data Stress Testing is applied primarily to numerical intensive algorithms such as those implementing guidance and controls 'Laws and logical intensive algorithms such as those found in fault detection/isolatjon and system reconfig- uration.

3.2.2 Timing Stress Test.

The objective of this test is to analyze the computational and transport delays which can develop within a DFS configuration. The primary goal is to establish the delay between the time a variable is set in one processor and the time it is used in another processor. The two main factors are:

1) The computational delay between the time the inputs to a software algorithm, implemented within one processor are read by that processor, and the time the outputs of that algorithm are actually updated. This delay is a function of the computational logic path, within that processor, which can vary from one algorithm execution to another. Software multirate structures, changes of aircraft flight mode or cockpit display mode, and, sometimes, changes of some parameters values can modify these delays.

? ) The transmission delay between two process- o r s inc lud ing : a ) The computational delay between the t i n e t h e input of an algori thm js updated within one processor and t h e tjme t h e output s ta tements a r e e ~ e c u t e d , arid b ) The time needed t o t r a n s f e r t h e d a t a from t h e output b u f f e r of one processor t o the input buf fe r of ano ther process- o r , i n c l u s i v e of any buf fe r access ar.d transmis- s i o n t imes. These components vary a s a func t ion of t h e execut ion paths of the two processors and of t h e a v a i l a b i l i t y of shared resources such a s hus j n t e r f a c e s .

The u l t i m a t e ob jec t ive of Tjming S t r e s s Test is t o determine, f o r each tjmc c r i t i c a l v a r i a b l e , the d i s t r i b u t i o n of computational and t r a n s p o r t de lays ; an2 v e r i f y t h a t , under no s i t u a t i o n , those delays do not exceed predetermined maximum va lues . The implementation of Timing S t r e s s Test r e q u i r e s :

1) Special instrumentat:on of t h e t a r g e t code t o send i n t e r r u p t d r iven messages t o the hos t computer, every time a c r i t i c a l v a r i a b l e i s updated or used;

2) A t e s t monitor program, jn t h e hos t processor , t n c a t a l o g and time l o g a l l those occurrences and then t o properly process them;

3 ) The i n s e r t i o n , i n c r i t i c a l computation paths of t h e f l i g h t sof tware , of time de lay loops of dura t ion c e n t r o l l e d by t h e hos t processor . The f e a t u r e provides t h e c a p a b i l i t y nf s t r e s s i n g t h e f l i g h t sof tware and of perforning a s e n s j t i v i t y analysis.

The e n t i r e process of Time S t r e s s i n g can he e a s i l y automated i n a manner very s i m i l a r t o t h a t ?escr ihed f o r Data S t r e s s Test .

3 .2 .3 P a r t i t i o n i n g S t r e s s Test . - The need f o r t h j s t e s t d e r i v e s from two

r o n s i d e r a t i c n s : 1) DFS c o r ~ f i g u r a t i o n s inc lude func t ions and component of d i f f e r e n t l e v e l s of c ~ i t i c a l i t y ; and 2) The required development e f f o r t and development r o s t vary a g r e a t d e a l a s a funct ion of t h e c r i t i c a l i t y .

Tn t h e case t h a t a system percorm two func- t i t n s wi th d i f f e r e n t l e v e l of c r i t i c a l i t y , then t h e funct ion with the lower l e v e l of c r i t i c a l j t y i s assumed t o have the same h igh l e v e l of c r i t i - c a l i t y a s the o ther iunc t ion un less i t can be demonstrated t h a t no a c t i o n of t h e lower c r i t i - r a l i t y func t ion can cause a f a i l u r e of t h e higher c r i t i c a l i t y funct ion. In t h i s case the h igher r r i t i c a l i t y func t ion i s aef ined t o be " p a r t i - t ioned" from t h e lover c r i t i c a l i t y functior. .

The o b j e c t i v e of P a r t i t i o r j n g S t r e s s Test i s t o demonstrate partitioning between two func t ions q f d i f f e r e n t l e v e l of c r i t j c a l i t y . To achieve t h i s o b j e c t i v e i t must 5e demonstrated t h a t no outpot d a t e from the l e s s c r j t i c a l func t ion , and no time skcwness between t h e execut ion times of the two func t ions , can cause a f a i l u r e of t h e more c r i t i c a l func t ion . P a r t i t i o n i n g S t r e s s Test j s c l e a r l y a combination, and a s p e c i a l case o f , t h e two previously described Data and Timing S t r e s s i n g s t r a t e g i e s .

embedded software i d e a l h o s t s f o r t h e s t r e s s techniques which r e q u i r e t h a t t h e software under t e s t execute under condi t ions which a r e repre- s e n t a t i v e of t h e f i i g h t condi t ions .

4 .0 Conclusion - An a n a l y s i s of t h e a v a i l a b l e technology f o r

DFS development and v e r i f i c a t i o n has been complet- ed. The technology requirements of t h e f l i g h t c o n t r o l systems f o r t h e next generat ion of highly i n t e g r a t e d m i l i t a r y a i r c r a f t , such a s Vehicle Nanagement Systems, has a l s o been conducted. Then, t h e major technology needs have been i d e n t i - f i e d i n the two c r i t i c a l a r e a s of system a r c h i t e c - t u r e design and a n a l y s i s and software development and v e r i f i c a t i o n . F i n a l l y , promising t o o l s and techniques have been described which, integr;r ted i n advanced environments can e f f e c t i v r l y support the development of those systems.

5.0 REFERENCES

1. Hecht, H , Hecht, M "Trends of Software Re- l i a b i l i t y f o r D i g i t a l F l i g h t Control" NASA Con- t r a c t Report P.O. A53024B, Apr 1983

2 . WcCahe T.J. " A complexity measure" IEEE Transact ions on Software Engineering, Vol. SE-2, NO. 4 , DEC. 1976

3 . Kneeburg S . "Automated I n t e r a c t i v e Simulation Model (AISIM)" Contract tF33615-81-C-5'298; Elec- t r o n i c Systems Divis ion, Hanscom Air Force Base, MA

4 . Rajan N., De Feo P. e t a l . "S t ress t e s t i n g of f l i g h t c o n t r o l systems software: IEEWAIAA 5T1I 1)igj t a l Avionics Systems Conference. NOV. 1983

The c u r r e n t l y used, r e a l t ime, dedicated environment which include the t a r g e t computers and