LCA AVIONICS - As per different sources

[ptltejas]

AVIONICS


The avionics system enhances the role of Light Combat Aircraft as an effective weapons platform. The glass cockpit and hands on throttle and stick (HOTAS) controls reduce pilot workload. Accurate navigation and weapon aiming information on the head up display helps the pilot achieve his mission effectively. The multi-function displays provide information on engine, hydraulics, electrical, flight control and environmental control system on a need-to-know basis along with basic flight and tactical information. Dual redundant display processors (DP) generate computer-generated imagery on these displays. The pilot interacts with the complex avionics systems through a simple multifunction keyboard, and function and sensor selection panels.
A state-of-the-art multi-mode radar (MMR), laser designator pod (LDP), forward looking infra-red (FLIR) and other opto-electronic sensors provide accurate target information to enhance kill probabilities. A ring laser gyro (RLG)-based inertial navigation system (INS), provides accurate navigation guidance to the pilot. An advanced electronic warfare (EW) suite enhances the aircraft survivability during deep penetration and combat. Secure and jam-resistant communication systems, such as IFF, VHF/UHF and air-to-air/air-to-ground data link are provided as a part of the avionics suite. All these systems are integrated on three 1553B buses by a centralised 32-bit mission computer (MC) with high throughput which performs weapon computations and flight management, and reconfiguration/redundancy management. Reversionary mission functions are provided by a control and coding unit (CCU).

Most of these subsystems have been developed indigenously.

The digital FBW system of the Tejas is built around a quadruplex redundant architecture to give it a fail op-fail op-fail safe capability. It employs a powerful digital flight control computer (DFCC) comprising four computing channels, each powered by an independent power supply and all housed in a single line replaceable unit (LRU). The system is designed to meet a probability of loss of control of better than 1×10-7 per flight hour. The DFCC channels are built around 32-bit microprocessors and use a safe subset of Ada language for the implementation of software. The DFCC receives signals from quad rate, acceleration sensors, pilot control stick, rudder pedal, triplex air data system, dual air flow angle sensors, etc. The DFCC channels excite and control the elevon, rudder and leading edge slat hydraulic actuators. The computer interfaces with pilot display elements like multi-function displays through MIL-STD-1553B avionics bus and RS 422 serial link.

Multi-mode radar (MMR), the primary mission sensor of the Tejas in its air defence role, will be a key determinant of the operational effectiveness of the fighter. This is an X-band, pulse Doppler radar with air-to-air, air-to-ground and air-to-sea modes. Its track-while-scan capability caters to radar functions under multiple target environment. The antenna is a light weight (<5 kg), low profile slotted waveguide array with a multilayer feed network for broadband operation. The salient technical features are: two plane monopulse signals, low side lobe levels and integrated IFF, and GUARD and BITE channels. The heart of MMR is the signal processor, which is built around VLSI-ASICs and i960 processors to meet the functional needs of MMR in different modes of its operation. Its role is to process the radar receiver output, detect and locate targets, create ground map, and provide contour map when selected. Post-detection processor resolves range and Doppler ambiguities and forms plots for subsequent data processor. The special feature of signal processor is its real-time configurability to adapt to requirements depending on selected mode of operation.

Following are the important avionics components:

Mission Computer (MC): MC performs the central processing functions apart from performing as Bus Controller and is the central core of the Avionics system. The hardware architecture is based on a dual 80386 based computer with dual port RAM for interprocessor communication. There are three dual redundant communication channels meeting with MIL-STD-1553B data bus specifications. The hardware unit development was done by ASIEO, Bangalore and software design & development by ADA.

HUD: The Head-up-Display of the LCA is a unit developed by the state-owned CSIO, Chandigarh. The HUD is claimed to be superior to similar systems in the international market. According to Mr. CV M L Narasimham, head of CSIO's Applied Optics division, compared to Israel's HUD, the CSIO equipment is noiseless, silent, and offers a better field of view. It is compact, reliable, non-reflective and designed for high-performance aircraft on the PV-2 version of the LCA.


www.lca-tejas.org/avionics.html

 

[ptltejas]

LCA AVIONICS AND WEAPON SYSTEM MISSION COMPUTER SOFTWARE
DEVELOPMENT: A CASE STUDY

Srikant Visweswariah
Deputy Project Director (Avionics System)
ADA, Bangalore
(Currently Chief Technology Officer at Bitsoft Systems)
&
B C Banerji
Group Director (Mission Software)
ADA, Bangalore

Abstract: The development of software ver 3.0 for the Light Combat Aircraft (LCA)
Mission Computer was a large and complex project in which Ada was used as both
design and code language. The development process and the experience gained are
covered in this paper.

1. INTRODUCTION

The Avionics and Weapon System (AWS) in any modern day fighter aircraft
enables the pilot to perform various mission functions and thereby meet the stipulated
operational role of the aircraft.

The AWS must meet the following functional requirements in order to complete a
Mission:

a) Receive inputs from
- Sensors

o Radar, INS, Airdata system, LDP, FLIR, Radio Altimeter etc
- Communication Systems

o Data link, voice link
- Radio Navigation System

o TACAN
- Identification System

o IFF (Responder and Interrogator)
- Missiles

o Identification signal, seeker head position, locked-on to target
signal etc.
- Electronics Counter Measures System

o Radar Warning receiver
o Self Protection Jammer
o Offensive Jammer

- Pilot Controls

o Hands on stick and throttle (HOTAS) controls

o Other controls

Page 2

2

b) Compute required parameters for navigation and fire control

- Navigation algorithms: Guidance to steer point etc

- Fire Control algorithms: weapon aiming, missile launch etc.

c) Output computed results to

- Displays:

o Basic flight, steering and navigation parameters

o Weapon aiming, missile launch symbologies

o Sensor outputs

o Failures and warnings

- Audio System: AWS status and warnings

- Weapons

d) Control weapon launch/firing

- Weapon selection and preparation

- Launch/fire sequencing

- Jettison

e) Control/co-ordinate/manage sensors optimally

- Mode commands

- Slaving commands

2. LCA AVIONICS AND WEAPON SYSTEM FUNCTIONS

The major functions performed by the LCA Avionics and Weapon System are:

- Operational (or mission) functions including fire control functions

- Mission preparation and data retrieval functions

- System-crew dialogue functions

- Aircraft communication functions

- Integrated maintenance functions

The operational functions include Navigation Guidance functions as well as Air-to

Air, Air-to-Ground and Air-to-Sea weapon functions. Mission preparation involves the

preparation of a data cartridge on the ground and transferring this information onto the

aircraft. Data retrieval consists of the avionics system recording or storing information on

the data cartridge, which could then be read on the ground. System-crew dialogue

functions include cockpit controls/inputs management, display synthesis and

management, and warnings management. Aircraft communication functions include both

voice and data communication. Integrated maintenance functions include both in-flight

maintenance and on-ground supplementary maintenance.

In the LCA, a number of utility system management systems (USMS) are

integrated with the AWS. These systems are for fuel/oxygen management, engine health

monitoring, environmental control system management etc.

Page 3

3

The above mentioned functions are achieved through integrated functioning of the

Mission Computer, sensors, controls, displays and the weapon systems - all software

driven and in real time mode.

3. AWS SOFTWARE DEVELOPMENT PROCESS

As indicated in fig.1, an analysis of the Air Staff Requirements (ASR), the LCA

mission profiles and the system requirements in each profile led to the definition of AWS

requirements. An analysis of these requirements then led to AWS design. The first step in

the design was the generation of AWS Broad specifications as indicated in fig.1. The next

step was the generation of the AWS functional architecture and the Global specification

of each Operational or mission function. Each Global specification describes completely

a specific operational function from the Pilot’s point of view. It includes operation of

Pilot’s controls, symbologies, warnings etc.

4. AWS FUNCTIONAL ARCHITECTURE

The definition of the AWS functional architecture involved:

- Classification of the AWS functions into various categories or groups

- Definition of the hardware units and software functions for each functional

element in each group

The LCA AWS functions have been broadly classified into

- Central processing functions performed by the Mission Computer

- Functions performed by various external equipments like sensors (Radar,

LOP, FLIR, RWR, etc), Weapon release/stores management units,

communication units, etc.

- Cockpit man-machine dialogue equipment functions performed by Display

Processor and various control panels and Display Surfaces in the Cockpit.

The above categorisation is based on a distributed processing concept with sensor-

oriented functions being performed by various sensor computers and mission oriented

functions being performed by a Central Computer (Mission Computer). Cockpit Man-

machine dialogue equipment functions form another very important category of LCA

AWS functions. The LCA AWS consists of a large number of units, like the Mission

Computer, sensors, cockpit dialogue units etc, connected together by MIL-STD-1553B

serial multiplex data buses.


LCA AVIONICS AND WEAPON SYSTEM MISSION COMPUTER SOFTWARE DEVELOPMENT: A CASE STUDY Srikant Visweswariah

 

[ptltejas]

The MC is the manager of the LCA AWS and performs the following functions:

Page 4

4

- Operational/Mission functions like Navigation and Guidance management,

Fire control computations and management, etc

- Cockpit man-machine dialogue management functions

- Functions which manage/link external equipments like sensors, armament

stores, communication, and radio navigation equipment etc.

- AWS Initialisation functions

- Miscellaneous functions like Air data Computations etc.

- AWS Maintenance management functions

- 1553B data Bus Controller functions

The MC hardware consists of a dual 80386-based computer with dual port RAM

for inter-processor communication.

6. MC SOFTWARE DEVELOPMENT OVERVIEW

6.1 DEVELOPMENT RESPONSIBILITY

The MC software has been jointly developed by ADA, HAL, ASIEO and two

private sector companies, M/s Processware System Pvt Ltd., and M/s Accord Software

and Systems with ADA taking total responsibility and leadership. An independent V&V

team from ADA was also involved during every step of the development process.

6.2 DEVELOPMENT STEPS

The steps involved in the MC software development were the following:

- Definition of MC software functional architecture

- Definition of MC Software Requirement Specifications (SRS)

- Design, code and unit testing

- Integration testing

The functional architecture was defined using Structured Analysis and Design

Technique (SADT). SRS was defined using Ward and Mellor DFD methodology. Ada

language was used as both design and code language. The MC software development and

documentation broadly followed the MIL-STD-2167A standard. The MC software has

been categorised as a computer software configurable item (CSCI) that executes on the

MC hardware configurable item (HWCI).

6.3 DEVELOPMENT ENVIRONMENT

- Hardware

o VAX 3195, VAX 3196, VAX 3400, MICROVAX II with VMS

o About 20/25 VAX terminals

o MC targets (Qty 4)

Page 5

5

- Software

o VAX Ada Native compiler running on VAX/VMS

o DDCI Ada Cross compiler running on VAX/VMS producing code

for MC target

o VAX debugger

o DDCI Ada cross debugger running on VAX and Debug monitor

running on MC target

o Code Management System (CMS) for configuration management

o C Cross compiler/debugger for bus controller development

- MC Static Test Rig

o The test rig consists of a large number of Pcs (one PC per hardware

unit in the AWS) connected to the MC through 1553B data buses.

This rig simulates the Inputs/Outputs of all the units connected to

the MC on 1553B data buses. Provision is there to display all the

1553B data bus traffic to/from each unit as well as modify the data

bus inputs to MC.

7. MC SOFTWARE FUNCTIONAL ARCHITECTURE

The first step in the generation of MC software requirements specifications (SRS)

was the definition of the MC software functional architecture using SADT methodology.

This consisted of

- Decomposition of MC functions hierarchically into various functional

modules

- Definition of tasks performed by each module

- Definition of information flow between these modules

7.1 FACTORS IN FUNCTIONAL ARCHITECTURE DEFINITION

The driving factors have been modularity, flexibility and growth potential. As the

MC performs a large number of Operational/Mission functions, the following

requirements were specified and taken into account while defining the functional

architecture:

- There is one specific operational function for each specific weapon

- There are specific operational functions for Navigation functions

- Each operational function is independent of other operational functions. It may

be specified, implemented and tested independently of other operational

functions

- During the life of the AWS, new operational functions would get added as

new weapons are added

- According to pre-defined selection rules, operational functions may be

selected to run concurrently (superposed) with each other or exclusively.

Page 6

6

- No operational function is tied to specific cockpit controls or external

equipment/sensors though it receives input from them

- No operational function is tied to specific display surfaces or external

equipment/sensors though it sends outputs to them

- Separate development teams would work on various operational functions.

- Each operational function performs its tasks in the following manner

o It receives

Inputs from the Pilot: From Cockpit Controls

Inputs from external equipments: sensors etc.

o Then mission computations are performed

o After computation, it produces

Outputs to the Pilot: Flight/Steering information,

Guidance/Release cues, warnings etc, for display

Outputs to external equipments: Stores/weapons, sensor control

information etc.

o If the operational function does not receive the required inputs in order

to enable it to produce its outputs, it generates warnings.

7.2 CATEGORIES OF MC FUNCTIONAL MODULES

Based on the above driving factors, the following categories of MC functional

modules were defined:

- OPERATIONAL MACROFUNCTION MODULES:

o These modules perform core mission tasks. There is one such module for

each weapon and the various macrofunction module are independent of

each other.

- ENVIRONMENT MODULES

o These modules provide the environment for the operational macrofunction

modules to perform. These modules are further categorised as

System Logic Modules: (Cockpit Input Synthesis and

Output Synthesis Modules

- These modules manage the cockpit man-machine

dialogue including warnings, etc and activate other

modules. These modules exchange information with

operational macro function modules

Modules Managing/Linking external equipment

- These modules manage various sensors and link other

external equipment to the MC. These modules

exchange information with operational macrofunction

modules. These modules are further categorised as

- Sensors management modules

- Armament/stores management modules

- Communication linking modules

- AWS INITIALISATION MODULE

Page 7

7

- BUS EXCHANGE MANAGEMENT MODULE

- GROUND SUPPLEMENTARY MAINTENANCE MODULES

Under each category of functional modules, specific modules were defined and

these were termed as terminal functional modules. These terminal functional modules

were not decomposed further in the functional architecture.

8. MC SOFTWARE REQUIREMENTS SPECIFICATION (SRS)

The MC SRS represents the essential model of the MC software and was defined

in terms of the SRS for each of the terminal functional modules defined in the MC

functional architecture. The SRS was generated using Mentor Graphics CASE tool and

Ward and Mellor Data Flow Diagram (DFD) with real time extensions methodology.

Essentially the MC functional architecture in SADT form was first hierarchically mapped

onto context diagram/levelled data flow diagrams etc up to the terminal functional

module level. Then the SRS for each terminal functional module was generated by

different teams using the Mentor Graphics CASE tool. Each SRS team was defined the

context of their terminal functional module (called a process in Ward/Mellor

methodology) in terms of higher-level data flow diagrams etc. After the SRS of each

terminal functional module was completed these were then integrated/balanced with the

higher level DFD’s/context diagram on the CASE tool to generate

- MC context diagram

- Complete set of levelled DFDs

- Complete set of state-transition diagrams

- Complete MC Data Dictionary

- Complete set of process specifications including role of each process

- Functional descriptions/explanatory notes wherever required

- Design constraints (including real time constraints)

- Data exchanges between various functional modules

The above list constituted the MC SRS. In ver 3.0 of the MC SRS, 26 terminal

functional modules were considered and there were approximately 150 DFD’s and the

data dictionary size was about 10,000 lines (includes Data/Control elements and

Data/Control flows). The SRS team consisted of about 25-30 systems engineers.

 

[ptltejas]

9. MC SOFTWARE DESIGN, CODE AND TEST (DCT)

The MC software DCT was done by a team of about 35-40 engineers. There were

separate teams for Design, Design V&V/testing, QA, configuration management,

hardware related software etc.

9.1 DESIGN APPROACH

Ada was used as the design language, as well as the coding language except for

Bus Exchange Management module, which was implemented in C. The whole design

Page 8

8

process was driven by a set of DESIGN DIRECTIVES in various aspects of the design.

These directives were issued to the design team members during the course of

development by the design team leader in consultation with the project team. These

directives addressed issues common to all team members as well as specific to each

member. These directives served to achieve uniformity and cohesiveness in design. Some

of the issues covered by the directives are; guidelines for preliminary design from SRS,

design consideration for handling overflows in BUS interface procedures, design

considerations for bus outputs etc. To date 69 directives have been issued.

Following MIL-STD-2167A standard, the MC CSCI was decomposed into a

number of first level computer software components (CSC’s). Each CSC corresponded to

a specific functional module defined in the functional architecture. Additional CSC’s

were defined to cover implementation requirements.

9.1.1 PRELIMINARY DESIGN

A uniform approach was adopted for preliminary design of a functional

module/first level CSC from the SRS. This involved the definition of a Ada

package specification for each CSC, as well as Ada data/types packages

specifying data exchanges between that CSC and other first level CSC’s. Each

first level CSC package specification contained procedures, which were called by

the user of that package - namely, the MC scheduler in our case. When the

procedures defined in first level CSC package specifications were called by the

MC scheduler, they achieved the functionality defined in the SRS of that

functional module/CSC. The package specification design was based on the

concept of data abstraction and information hiding for which Ada language was

eminently suitable. Data exchanges between various first level CSC’s were strictly

on the basis of formal parameters defined in the procedures in the package

specifications. Sufficient care was taken to ensure that data element names etc.

used in the SRS were retained to a large extent in the design for better traceability.

Prior to preliminary design review, all package specifications were compiled and

checked for absence of circular dependency. The design of each CSC was handled

by one or two members of the design team.

9.1.2 DETAILED DESIGN

The Ada package bodies of the above-mentioned first level CSC package

specifications constituted the detailed design. In many cases, the package bodies

themselves contained one lower level package specification and their bodies. These were,

of course, not visible to the MC scheduler. In detailed design, each first level CSC was

further decomposed into lower level CSC’s and each last level CSC was decomposed into

several Computer Software Units (CSU’s). A CSU was defined as the lowest level

procedure/function which achieved a certain small but specific functionality. In addition,

to Ada being used as a design language, the main design features of each CSC were

recorded in English and formed a part of the design document.

Page 9

9

9.1.3 DESIGN EVALUATION

During the design/code process, Design/code walkthrough’s were conducted for

- Traceability checks from SRS to Design/code

- Correctness

- Completeness

- Compliance to design directives/coding standards

- Understandability

9.2 TEST APPROACH

The testing of the MC software was done at three levels:

a) CSU level testing (done by the design team). Each CSU was subject to

white box testing. Each execution path in the CSU was identified and

tested.

b) CSC level testing (done by the Design V&V/testing team). Each CSC was

subject to black box testing and tested for functionality. The design V&V

team independently generated test plans and test software for each

functional module (first level CSC) on the basis of the SRS. Each design

V&V team member handled the testing of 1-3 functional modules. The

CSC level tests were first conducted on the HOST Computer (VAX) and

then on the MC target. An Automated Test Software (ATS) has been

developed to automate CSC level testing on both the Host and the Target.

Using the ATS, multiple runs of the test CSC is possible; with

independent sets of test data (input and expected output date) for each run.

Testing of a few CSC’s on the target took about 15-20 hours.

c) CSCI level testing (done by the total software development team)

MC CSCI level testing is black box testing on the target and was done

using the MC test Rig and 1553B data bus monitors. After completion of

CSC level testing on the target, the CSC’s were integrated to form the

CSCI and ported onto the target. CSCI testing was done in two stages:

- In the first stage, the MC CSCI software was down loaded into the

target from the VAX 3195 through an RS422 link with the Debug

monitor running on the target. The software was then run and

tested under debugger control.

- In the second stage, the MC CSCI software was loaded onto the

target EEPROMS as would be the case under actual operating

conditions. Testing was then carried with the MC disconnected

from the development environment.

Page 10

10

Each cycle of MC CSC1 testing carried out by the development team as

well as by the independent V&V team took about 3.5 to 4 months.

In the final MC CSCI testing 60 errors were detected in about 100,000

lines of Ada source code and an analysis of the type of errors detected is as

follows:

Type of Errors Percentage of total errors

System Design 32

SRS 33

Design/Code/CSC Test 20

ICD (1553B Interface Control Document) 10

Others 5

A significantly higher percentage of errors in System design/SRS was due to the

inherently manual nature of system design and SRS even though a CASE tool had been

used.

10. MC SOFTWARE CONFIGURATION MANAGEMENT

Software Configuration Management is absolutely essential for large software

projects. To take care of configuration management, a Configuration Control Group

(CCG), comprising of the MC Project Manager, Design Team Leader, Design V&V

Team leader, Internal QA and Configuration Control Manager was formed.

10.1 DEVELOPMENT CONFIGURATION ITEMS

The following were the Development Configuration items used in the MC CSCI

development:

1. Change notice for Software Requirements Specification

2. Software Design (Preliminary and Detail Design)

3. Requests for ICD (Interface Control Documents) Changes

4. CSU, CSC Test Description

5. CSCI Test Plan

6. CSCI Test Description

7. CSC Software Problem Report

8. CSC Software Problem Response Report

9. CSCI Software Problem Report

10. CSCI Software Problem Response Report

11. Source Code - File Header and Modification History

12. CSC Code Walk Through Reports

13. CSC Code Walk Through Response Report

14. Request for Change in Design

15. Change Notice to Design

Page 11

11

16. CSC Test Completion Report

17. Test Rig Problem Report

18. Ada Program Library on Host used by Design team

19. Ada Program Library on Host used by Design V&V Team

20. Ada Program Library on Target used by Design and Design V&V Team

21. CSC wise Ada test Programs

10.2 FLOW OF CONFIGURATION CONTROL AND CORRECTIVE ACTION

PROCESS DURING DCT

The Configuration Control during DCT started from the time the SRS was handed

over to the Design and Design V&V Teams. The two teams operated in parallel,

interacting whenever changes were required at any stage of the software development.

The Design Team studied the SRS and proceeded with the Preliminary Design,

followed by the Detailed Design. In parallel, the Design V&V team also studied the SRS

and prepared the CSC Test Plans and Test Descriptions, followed by CSCI Test Plan and

CSCI Test Descriptions.

- Whenever any problems was noticed in the SRS for any CSC by either of

the teams, Change Notice for the SRS for that CSC was raised in the

appropriate format, by the team member in consent with the respective

CSC member of the other team and the CCG.

- The Change Notice was then reviewed by the CCG. The CCG then

approved/disapproved the change based on the technical merit, potential

side effects, overall impact on other system functions and other related

issues.

- If the change was approved, the Change Notice to the SRS was released,

with copies of the same being distributed to all the affected members of

Design team, Design V&V team, Design Leader, Design V&V Leader,

Internal QA, Project Manager and Independent V&V.

- Once the change notice was released, the changes were affected in the

design, test plans and test software.

- Informal reviews of the Design were conducted by the Design V&V team

at various stages of the design.

- Formal Code Walk Through reviews were conducted by the Design V&V

team at the completion of the base version of the Preliminary Design and

Detail Design, and Code Walk Through Reports were generated by the

Design V&V team.

- Based on the review of the Code Walk Through report, the Design Team

prepared the Code Walk Through Response Report.

- If the designer wanted to change the design based on his own analysis or

due to change in the design directives, he generated a Request for Change

in Design.

- Based on the reviews by CCG, the designer then generated Change notice

to Design.

Page 12

12

- Any changes the designer made to the code after the base version, were

reflected in the modification history of that file.

- Any changes needed in the 1553B data bus Interface Control Document

were generated by either of the team with the consent of the CCG. The

change was requested in the format for Request for ICD change.

- The request for ICD Change, after the approval from the CCG, was

handed to the avionics group maintaining the Interface Control Document,

which issued the change in the form of ICD Revision.

- Based on ICD revision history, the Design, Test Plans and Test software

were updated.

- The design team tested the CSU during the CSC coding phase. The design

team corrected any errors and no formal reports were generated.

- Once CSC coding was over and all the CSU’s were tested, the code was

then handed over to the Design V&V team for the CSC testing.

- The Design V&V team generated the CSC test programs and the databases

based on the Test Plans.

- On receipt of the Code from the Design Team, the Design V&V team after

testing the CSC generated Software Problem Report (SPR).

- The Design team then responded by generating the Software Problem

Response Report (SPRR).

- After the SPR and SPRR were reviewed and released by the CCG, suitable

changes notices were initiated for change in SRS, Design, ICD, Test Plan

and Description, Test software and databases.

- Once the CSC testing was completed, the Design V&V team generated

Test Completion Report for that CSC.

- All the Changes needed in the CSC Test Plan Document were

consolidated and new revision for the Test Plan Document was released.

The new release listed all the change notices taken care in that release.

- The CSCI test plan and descriptions were generated based on the SRS and

ICD, supplemented by the Global Specifications, etc. Newer revisions of

the CSCI Test plan and description documents were released to

incorporate the Change notices.

- Any problems noticed during the CSCI testing were reported in the form

of MC Software Problem Report.

- A response for the same was generated in the form of Software Problem

Response Report. After the approval of the solution from the CCG, the

appropriate change notices were generated as explained previously.

- The CSCI testing was performed using the Test Rig and problems found in

the Rig were documented in the form of Test Rig Problem Report.

 

[Chanakyaa]

Great Effort. Keep it Up.

 

[ptltejas]

11. MC SOFTWARE DEVELOPMENT EFFORT AND STATUS

The total software development effort upto ver 3.0 level was about 150 man-

years. About 40-45 engineers worked on the project during peak effort periods.

Page 13

13

The embedded software developed in Ada language came to about 100,000 lines

of source code and the total software developed including test code came to approx

4,50,000 lines. More than 2000 hours of software testing on the target has been done. The

testing by Independent V&V team and CRE (type certification authority) has been

completed and the MC has been delivered for Integrated AWS testing at the Dynamic

Avionics Integration Rig.

12. EXPERIENCE GAINED FROM THE MC SOFTWARE DEVELOPMENT

PROJECT

For the success of large and complex software development projects, the

following are considered essential:

- Good Project Management and leadership

- Teamwork with engineers mutually supporting each other and communicating

with each other.

- A comprehensive and effective software development process control with no

short cuts.

- Testing engineers/teams to be independent from Design engineers/teams.

- Automating the testing process as far as possible

- Effective Internal QA different from design/test teams with adequate

experience and peer acceptance

- Effective Configuration Management

- Effective error correction mechanisms/processes

- Documented Design directives/Test directives for communication when large

teams with different backgrounds are working together and personnel attrition

rates are high.

- Good design

o Amenable to modification and growth

o Testable

o Maintainable

Ada language has been found to be extremely suitable for large embedded projects

for the following reasons:

- Preliminary designs can be compiled. This minimises integration problems

later on.

- Readability of design/code

- Strong type checking

- In-built exception handling

- Packaging concept: For Data abstraction, information hiding and,

programming in the large.

Page 14

14

AVIONICS AND WEAPON SYSTEM

SOFTWARE DEVELOPMENT PROCESS ( UPTO SOFTWARE SPECIFICATION LEVEL )

SYSTEM REQUIREMENT ANALYSIS/DESIGN

ASR MISSION ANALYSIS AVIONICS SYSTEM REQUIREMENT

BROAD SPECIFICATION

DEFINITION GUIDELINE

DOCUMENT

GLOBAL

SPECIFICATION OF

OPERATIONAL

FUNCTIONS

FUNCTIONAL

ARCHITECTURE

SOFTWARE SPECIFICATION

-
DETAILED SOFTWARE REQUIREMENT SPECIFICATION OF MC AND CCU

- DETAILED FUNCTIONAL SPECIFICATION OF OTHER EQUIPMENTS

-
SYMBOLOGY SPECIFICATIONS

-
INTERFACE CONTROL SPECIFICATIONS

SOFTWARE REQUIREMENT ANALYSIS

-
H/W ARCHITECTURE

-
S/W FUNCTIONAL

ARCHITECTURE

-
METHODOLOGY FOR S/W

REQUIREMENT ANALYSIS AND

FUNCTIONAL SPECIFICATIONS

-
DESCRIPTION OF COCKPIT

-
BUS UTILISATION GUIDELINES

-
EMI/EMC AND TEST PLANS

-
COCKPIT CONTROLS

AND DISPLAY

-
RADAR MODES,

CONTROLS, DISPLAYS

-
DEGRADED MODES

-
COCKPIT

RECONFIGURATION

-
INITIALISATION

-
PILOTS WARNINGS

-
DATA BUS

MANAGEMENT

-
FUNCTIONS

ACTIVATION

-
SUBSYSTEM

FUNCTIONAL

SPECIFICATIONS

-
BASIC FLIGHT AND

NAVIGATION

-
AIR TO AIR

-
AIR TO GROUND

-
AIR TO SEA

-
MISSION SCENARIO ANALYSIS AND SYSTEM REQUIREMENT

www.google.co.in/gwt/x?source=m&u=http%3A%2F%2Fwww.bitsoftsystems.com/mydocs/Avionics%2520Mission%2520Computer%2520Case%2520Study.pdf&wsi=1d2d55a2b612600f&ei=T0buTeyxKYHJkgWUh-XxBA&wsc=tb&ct=pg1&whp=30

 

[kali]

is all the system develop by India or in joint venue?

 

[ptltejas]

LCA AVIONICS AND WEAPON SYSTEM MISSION COMPUTER SOFTWARE
DEVELOPMENT: A CASE STUDY

Srikant Visweswariah
Deputy Project Director (Avionics System)
ADA, Bangalore
(Currently Chief Technology Officer at Bitsoft Systems)
&
B C Banerji
Group Director (Mission Software)
ADA, Bangalore

Abstract: The development of software ver 3.0 for the Light Combat Aircraft (LCA)
Mission Computer was a large and complex project in which Ada was used as both
design and code language. The development process and the experience gained are
covered in this paper.

this is person who did study. I dont know whether all system made by India but yeah now i do understand why its take time to develop new plane.

 

[ptltejas]

what about design, engine etc. The mordern fighters 40% to 60% cost-price gone to avionics.

 

[ptltejas]

a

AVIONICS
.
The high agility and manoeuvrability requirement of a modern fighter leads to the choice of a fly-by-wire design for the flight control system in which the on-board computer performs the central function. Integrated avionics is the key to its mission effectiveness and reliability. The advent of powerful digital processors, data buses, synthetic displays and artificial intelligence in the cockpit promises to revolutionise the way military aviation will develop in future. Dramatic advances in airborne radar and electronic warfare systems and electro-optic sensors have made them key elements of modern fighter aircraft, even more than the speed and agility features of these machines. The development of unmanned air vehicles makes special demands on technologies related to telemetry, telecommand, secure data link, navigation and mission sensors. Major DRDO accomplishments in this critical field of avionics technology are reviewed.



Avionics System of LCA

. Avionics System of LCA


The avionics system enhances the role of Light Combat Aircraft (LCA) as an effective weapon platform. The glass cockpit and hands on throttle and stick (HOTAS) controls reduce pilot workload. Accurate navigation and weapon aiming information on the head up display helps the pilot achieve his mission effectively. The multifunction displays provide information on engine, hydraulics, electrical, flight control and environmental control system on a need-to-know basis along with basic flight and tactical information. Dual redundant display processors (DP) generate computer-generated imagery on these displays. The pilot interacts with the complex avionics systems through a simple multifunction keyboard, and function and sensor selection panels. A state-of-the-art multi-mode radar (MMR), laser designator pod (LDP), forward looking infra-red (FLIR) and other opto-electronic sensors provide accurate target information

to enhance kill probabilities. A ring laser gyro (RLG)-based inertial navigation system (INS), provides accurate navigation guidance to the pilot. An advanced electronic warfare (EW) suite enhances the aircraft survivability during deep penetration and combat. Secure and jam-resistant communication systems, such as IFF, VHF/UHF and air-to-air/air-to-ground data link are provided as a part of the avionics suite. All these systems are integrated on three 1553B buses by a centralised 32-bit mission computer (MC) with high throughput which performs weapon computations and flight management, and reconfiguration/redundancy management. Reversionary mission functions are provided by a control and coding unit (CCU). Most of these subsystems have been developed indigenously.

Flight & Propulsion Controls


The digital FBW system of the LCA is built around a quadruplex redundant architecture to give it a fail op-fail op-fail safe capability. It employs a powerful digital flight control computer (DFCC) comprising four computing channels, each powered by an independent power supply and all housed in a single line replaceable unit (LRU). The system is designed to meet a probability of loss of control of better than 1x10-7 per flight hour. The DFCC channels are built around 32-bit microprocessors and use a safe subset of Ada language for the implementation of software. The DFCC receives signals from quad rate, acceleration sensors, pilot control stick, rudder pedal, triplex air data system, dual air flow angle sensors, etc. The DFCC channels excite and control the elevon, rudder and leading edge slat hydraulic actuators. The computer interfaces with pilot display elements like multifunction displays through MIL-STD-1553B avionics bus and RS 422 serial link.The digital FBW system of the LCA is built around a quadruplex redundant architecture to give it a fail op-fail op-fail safe capability. It employs a powerful digital flight control computer (DFCC) comprising four computing channels, each powered by an independent power supply and all housed in a single line replaceable unit (LRU). The system is designed to meet a probability of loss of control of better than 1x10-7 per flight hour. The DFCC channels are built around 32-bit microprocessors and use a safe subset of Ada language for the implementation of software. The DFCC receives signals from quad rate, acceleration sensors, pilot control stick, rudder pedal, triplex air data system, dual air flow angle sensors, etc. The DFCC channels excite and control the elevon, rudder and leading edge slat hydraulic actuators. The computer interfaces with pilot display elements like multifunction displays through MIL-STD-1553B avionics bus and RS 422 serial link.

Engine Control

The Kaveri engine is controlled by two digital engine control units (KADECU) in a redundant fashion. The units are mounted on the engine and thus face a demanding environment in terms of temperature (135 0C) and vibration. A variety of analog electronics interface various sensors and actuators on the engine to the high performance Intel i960 CPU. Time critical (30 ms inner loop) software, programmed in Ada, implements complex engine control algorithms to effectively control the propulsion system. Since the full authority engine control is a safety-critical function, an independent mechanism is provided to monitor critical parameters and perform corrective action independent of the main controller (independent limiter).

Multi-Mode Radar

Multi-mode radar (MMR), the primary mission sensor of the LCA in its air defence role, will be a key determinant of the operational effectiveness of the fighter. This is an X-band, pulse Doppler radar with air-to-air, air-to-ground and air-to-sea modes. Its track-while-scan capability caters to radar functions under multiple target environment. The antenna is a light weight (<5 kg), low profile slotted waveguide array with a multilayer feed network for broad band operation. The salient technical features are: two plane monopulse signals, low side lobe levels and integrated IFF, and GUARD and BITE channels. The heart of MMR is the signal processor, which is built around VLSI-ASICs and i960 processors to meet the functional needs of MMR in different modes of its operation. Its role is to process the radar receiver output, detect and locate targets, create ground map, and provide contour map when selected. Post-detection processor resolves range and Doppler ambiguities and forms plots for subsequent data processor. The special feature of signal processor is its real-time configurability to adapt to requirements depending on selected mode of operation.

 

[ptltejas]

Electronic Components & Packaging



The revolution in avionics has been brought out by the developments in the electronics industry which has reached on chip packing densities of 15,000 transistors per square millimetre. Frequencies, normally encountered in RF circuits, are now driving digital circuits in the range of hundreds of MHz. Hence, heat dissipation and EMI/EMC problems have come to the fore. Also, the avionics equipment have to work at very high temperatures, acceleration and vibration environment. For example, KADECU has been designed to be cooled by the aircraft fuel circulating through its chassis to enable it to work at 130o ambient. DRDO has established state-of-the-art tools and facilities in the area of RF circuit design, analog and digital circuit design, and thermal design. Detailed design and analysis are performed using logic circuit simulation and VHDL-based complex circuit design tools. Facilities for hybrid microwave circuit development and fabrication have been established. Some of the special components that need mention here are:

High Power Pulse TWTs



Broad band high power gridded, helix travelling wave tubes (TWTs) have been designed and developed in association with BEL.

High Voltage Power Supplies & Modulators (HVPS/M)

These modulators, suitable for pulse and CW high power TWTs, are capable of generating up to 12 KV.

Broad Band Microwave Integrated Circuits (MIC) & Super Components for Channelised EW Receivers
AR&DB Aircraft Systems Panel

The Aircraft Systems Panel of the Aeronautics Research and Development Board promotes research in the field of avionics by sponsoring projects at academic and research institutes. The panel invites proposals for projects in areas such as:

Radar: Radar environmental simulation, advanced signal processing etc.

Airborne Antennae : Steerable antenna for GPS etc.

Avionics Software: fault tolerant S/W, Reliability studies etc.

Navigation Systems: Hybrid Systems, Kalman filters etc.

Cockpit Displays: Advanced graphic engines and algorithms etc.,

Interested researchers could obtain an exhaustive list of subjects from :

The secretary, Aircraft Systems Panel, ARDB

Directorate of Aeronautics, "B" Wing, Sena Bhavan,

Specifically, an MIC version of high speed microwave antenna select switch (MASS) as a front-end of digital instantaneous frequency measurement unit (DIFM) realised within 5.5" x 4.5" x 0.35" and operating with a switching speed of 35 ns has been designed and developed. Miniaturisation of complex circuits has been accomplished through hybrid microcircuit design and fabrication. Sync generators for the LCA display processor, filters for the MDI system, and signal conditioners for Nishant are some important examples.

 

[Conqueror]

In documents, so far so good. Lets see how it is built when put to a test.

 

[IndianArmy]

In documents, so far so good. Lets see how it is built when put to a test.

Ever since the LSP series these are the systems which are being put to test.... What is that you are trying to say?

 

[shaktiman2010]

Ever since the LSP series these are the systems which are being put to test.... What is that you are trying to say?

He is trying to say that he is jealous.

 

[Black Widow]

In documents, so far so good. Lets see how it is built when put to a test.

you are late But still
Its not only tested but Included in IAF...