AVIONICS SYSTEMS AND SOFTWARE Part 2. AVIONICS SYSTEMS AND SOFTWARE Real time considerations in...

AVIONICS SYSTEMS AND SOFTWARE

Part 2


• Real time considerations in Avionics System / Software design

• Software functional architecture ( mission computer/flight mgmt computer )

• Scheduling• General Avionics computer features(hardware)

• Avionics System/Software Development Process

• Avionics Simulation and Prototyping

• Avionics Integration and Integrated Testing

• System design methods & tools


• Software safety engineering

• Software design for system safety

• Defensive Programming

REAL TIME CONSIDERATIONS IN AVIONICS

SYSTEM / SOFTWARE DESIGN

* PERIODIC PROCESSING

Most Units in an Avionics System (eg. Flight Management or Mission Computer) have following periodic processing :

• ACQUIRE INPUT• COMPUTE / PROCESS• SEND OUTPUT


SYSTEM / SOFTWARE DESIGN* INPUTS

Most Inputs (Pilot controls, processed sensor data, raw sensor data, system monitoring data, etc.) are of sufficiently low bandwidth such that :

• Acquiring these inputs periodically at intervals of between 5 msec to 160 msec is adequate.• Data acquisition frequencies vary from 200Hz (5 msec interval) to 6.25 Hz (160 msec interval).• The fastest aircraft movement is roll. Maximum roll rate about 200 degrees/sec.• It is more than enough to acquire Air data at 6.25 Hz (Air pressure, temperature, air speed do not vary much in 160 msec time frame).


SYSTEM / SOFTWARE DESIGN(Inputs continued)

• It is sufficient to pick off pilot control at rates ranging from 12.5 Hz to 6.25 Hz.• Raw INS data (from RLGS) are picked off at 200Hz (5msec)• Radar Tracked Target data is acquired at between 50 Hz (20 msec) and 6.25 Hz (160 msec) depending on type of data• So Input data acquisition is done periodically and in polled mode. • Interrupt data acquisition is almost never used - there is no need most of the time.



* COMPUTE / PROCESSING

• Computation for each type / class of inputs is also periodic. Cycle times / rates need to match data acquisition cycle times / rates so that input data is not lost.

• So computation rates vary from 200 Hz to 6.25 Hz.



* OUTPUTS

• Outputs are also periodically generated as computation is done periodically. Again Output rates vary from 200 Hz to 5 Hz.

• Most outputs are sent to :• Display Units ( Maximum rate 50 Hz is required for HUD)• Sensor Control and Management• Weapon Control

• Data acquired in T1 by Unit A is Output in T3 to another Unit B which then acquires it in either T3 or T4 (in case of Transmission time) for further processing• Data Latency must be borne in mind during design

* CONCEPT OF DATA LATENCY:

T1

Acquisition

T2

Process

T3

Output

Acquisition Process

T4

Output

Acquisition Process

T5

Output



* Software Design in an avionics computer is driven by :

• Multi rate Input Data Acquisition (Polled, rarely Interrupts)

• Multi rate Computing

• Multi rate Outputting

• Data latency

Software functional architecture ( missionComputer/flight mgmt computer )

• Mission Functions ( Navigation, Weapons)• Avionics Initialisation • Management and Linking of different Sensors and Nav Aids (Radar, IFF, INS, Radalt, ILS, Communication, etc.)• Acquisition of Pilot Controls• Display Parameter Generation and Display Surface Page selection ( The parameters and page selections are sent to a symbol generation unit which draws the symbols on the HUD/MFD’s )• Weapon release Control• Warning Generation

* FUNCTIONS ( Say)

TYPICAL SOFTWARE FUNCTIONAL ARCHITECTURE(IN TERMS OF FUNCTIONAL MODULES)

(MISSION OR FLIGHT MGMT COMPUTER)

BANK OF NAVIGATIONGUIDANCE

ANDWEAPON RELEASE

MACRO FUNCTIONS6.25-50 Hz

RADARMGMT

6.25-50Hz

PILOTSINPUTS

ACQUISITION

I N SMGMT COMMUNICATION

LINKINGAIR DATA

COMPUTATION

DISPLAYPARAMETERS

SYNTHESIS

WEAPONMGMT

RADAR

INS

PILOTCONTROLS

COMMUNICATION

SETS

AIR DATA

SENSORS

DISPLAY

PROCESSOR

WEAPONS

TYPICAL SCHEDULER OVER ONE MAJOR CYCLE* Major Cycle : 160 msec (6.25 Hz)* Minor Cycle : 20 msec (50 Hz) M1 - M8

PILOT - INPUTS- 50

INS-MGMT- 25ADC -6.25

DISPLAY-SYNC-50 HzDISPLAY-SYNC-6.25

RDR-MGMT-12.5

PILOT - INPUTS- 50

COMM-LINK-6.25

PILOT - INPUTS- 50

INS-MGMT- 25

PILOT - INPUTS- 50

PILOT - INPUTS- 50

PILOT - INPUTS- 50

PILOT - INPUTS- 50

PILOT - INPUTS- 50

INS-MGMT- 25

INS-MGMT- 25

DISPLAY-SYNC-50 Hz

DISPLAY-SYNC-50 Hz

DISPLAY-SYNC-50 Hz

DISPLAY-SYNC-50 Hz

DISPLAY-SYNC-50 Hz

DISPLAY-SYNC-50 Hz

DISPLAY-SYNC-50 Hz

RDR-MGMT-12.5

RDR-MGMT-12.5

RDR-MGMT-12.5

M1 M2 M3 M4 M5 M6 M7 M8

Scheduling

• The chosen scheduling regime will aim to meet most, if not all, of

the following criteria :

Minimal use of Interrupts

Protection of each Process from Faulty Process

Predictable Execution Time of Process

Predictable Iteration Rate of Process

Predictable Scheduling Order of Process

Simple Scheduler Design

• Driven by Periodic Clock Interrupt, (Eg. 6.25 -50Hz)

• Fixed Number of Clock Ticks Constitute a Major Cycle

• Fixed Scheduling Order

Major Cycle

50 Hz Processors: run to completionin every minor cycle.

25 Hz Processors: run to completionin every alternate minor cycle.

Remaining minor cycle time used torun Background Process: CBIT, etc.

Minor Cycle

GENERAL AVIONICS COMPUTER

FEATURES(HARDWARE)

* INPUT / OUTPUT

• DISCRETES (DISCRETES I/O chips, OPTO-COUPLERS).• ANALOG (A/D CONVERTERS, SIGNAL CONDITIONERS).• DIGITAL (D/A CONVERTERS).• SYNCHRO’S.• MIL STD 1553B.• ARINC 429/629.• RS 232C.• Special purpose buses for High Speed Data Transfers.


FEATURES(HARDWARE)

* COMPUTING RESOURCES

• General CPU / DSP.• STATIC RAM.• ROM / EEPROM / EPROM.• TIMERS (Real Time Clock, Watch dog Timers).• Interrupt Controllers.• Dual Port RAMs.• Special purpose chips - Graphics, Codec, etc.


FEATURES(HARDWARE)* SAFETY FEATURES

• Watch dog Timer (Both software and hardware protection).• Computer ‘Good’ discrete output.• Input other computer ‘Good’ or ‘bad’ discrete.• BUS Silence.• Mode and status words (including error messages) to other computers on 1553B / RS232C / Arinc buses.

The computer should assert its good functioning continuouslyand should shutdown(partially or wholly) in case of malfunction.Under no circumstances should it affect the working of other computers and data buses.

Avionics System/Software Development Process

• Air Staff Requirements (ASR) for Military aircraft • A 30-50 page document defining

• Combat roles of the aircraft• Aircraft performance ( turn rates, endurance, speeds,etc)• Avionics fit including major sensors• Weapons fit• Engine fit

• Qualitative Requirements for Commercial aircraft• Defines

• Passenger and cargo capacity , Range , fuel economy, engine, Nav aids• Seating type• Entertainment


H/W ARCHITECTURES/W FUNCTIONAL ARCHITECTURE

METHODOLOGY FOR S/W REQUIREMENT ANALYSIS AND FUNCTIONAL SPECIFICATIONSDESCRIPTION OF COCKPITBUS UTILISATION GUIDELINESEMI/EMC AND TEST PLANS

BROAD SPECIFICATION

DEFINITION GUIDELINE DOCUMENT

BROAD SPECIFICATION

DEFINITION GUIDELINE DOCUMENT

GLOBAL SPECIFICATION OF

OPERATIONAL FUNCTIONS

GLOBAL SPECIFICATION OF

OPERATIONAL FUNCTIONS

FUNCTIONALARCHITECTURE

FUNCTIONALARCHITECTURE

SOFTWARE SPECIFICATION*DETAILED SOFTWARE REQUIREMENT SPECIFICATION OF MC or FMCDETAILED FUNCTIONAL /SOFTWARE SPECIFICATION OF OTHER EQUIPMENTSSYMBOLOGY SPECIFICATIONSINTERFACE CONTROL SPECIFICATIONS

SOFTWARE REQUIREMENT ANALYSIS

COCKPIT CONTROLS AND DISPLAYDEGRADED MODESCOCKPIT RECONFIGURATIONINITIALISATIONPILOTS WARNINGSDATA BUS MANAGEMENTENTERTAINMENT

BASIC FLIGHT AND NAVIGATIONAIR TO AIRAIR TO GROUNDAIR TO SEA

ASR/QR MISSION ANALYSIS AVIONICS SYSTEM REQUIREMENT


• ASR/QR

•Avionics System Requirements

• Avionics System Design :Hardware Architecture and Software functional Architecture, Global specs., LRU functional specs., Symbology specs., Interface control specs. SIMULATION is used as a tool to generate all these specs.

• Software Requirements specifications(SRS) for each LRU For Each LRU• Software Design ( High level and detailed)

• Coding


• Unit ( CSU and CSC ) level testing

• LRU ( CSCI ) level testing• Static and Dynamic test Rigs required to simulate all inputs to the LRU and record outputs/display from the LRU. These rigs are fairly complex as they involve simulating inputs from all other LRU’s ( including control panels ) in the Architecture • LRU should meet all functional and Input/Output specifications including error handling and recovery

• First level Certification is done at LRU level


• Avionics System level Testing or Validation• Done on a Dynamic Avionics Integration Rig• System Certification point

• Avionics testing on Aircraft• Actual non Avionics equipment connected to Avionics for the first time ( in many cases) Eg. Engine• Testing done in-situ • Testing can bring out wrong assumptions and requirements !

Avionics Simulation and Prototyping

• Simulation is widely used during Avionics Requirements Generation , Avionics System Design and Cockpit Design

• Pilots , Engineers , and Customers( Users) are involved

• Combat Mission Analysis• involves aircraft performance, avionics and sensor performance, enemy threats,etc. Goals involve performance tuning and predicting aircraft victory over threats,etc

• Cockpit Prototype•A fibre glass cockpit is made and all cockpit equipment is installed as in the aircraft cockpit


• Cockpit Prototype ( continued)• Computer containing aircraft model accepts pilot inputs and drives Symbology on the HUD and MFD’s as the pilot flies the model. The computer also contains other sensor models : INS, AHRS, Radar,etc

• Symbology can be changed very quickly

• Cockpit controls and switches can be altered very quickly

• Sophisticated Cockpit Prototypes may contain domes with projected outside imagery


• Cockpit Prototype ( continued)• Objectives

• Evaluate Cockpit Ergonomics and Pilot work load• Evaluate and finalize Symbology including warnings,etc• Evaluate Symbology brightness using Sun Gun• Evaluate Combat effectiveness taking into effect Cockpit factors

• Evaluate Flight Control law algorithms. This is normally done on a simpler set up instead of using the cockpit prototype. Flight Control laws and Handling qualities of the aircraft are evaluated


• Simulation of Navigation Guidance and Weapon Aiming ( missiles, bombs ) Functions

• This simulation is used during algorithm development( a part of System Design ). The accuracy, errors and effectiveness of various navigation guidance and weapon aiming algorithms are evaluated .

• The algorithms are finally converted to software during software development of the LRU’s containing the algorithm

Avionics Integration and Integrated Testing

• Dynamic Avionics Integration Rig( DAIR) or• Avionics ‘ Hot Bench ‘ or• Validation Bench

• Avionics System level testing or validation. Also called Hardware in Loop testing of Avionics Testing

• All Avionics equipment have to be connected together and tested on the ground before installation on the aircraft. Even interconnection cables/wiring are of the same or very similar length as in the aircraft

• Both Hardware and Software is tested

Avionics Integration and Integrated Testing

• Both Static and Dynamic testing done

• For Dynamic testing, a separate computer running an aircraft or flight model is used and integrated with the rig. A pilot or engineer can ‘ fly the bench ‘.

• All Avionics modes and functions are exercised and tested. Error injection is also done to test reversionary modes, warnings,etc

• Milestone for certification for installation on aircraft

Flight Control System(FCS) Testing

• Rig for Hardware in Loop testing of Flight Control Systems

• Called ‘ Iron Bird ‘

• Made up of:• FCS Computers • Actuators• Control Surfaces• Pilot Controls / Displays to fly the aircraft• Computer running aircraft model• Inputs/Outputs from other Avionics LRU’s connected to FCS

•Eg. Air data, mode and status words

SAFETY REQUIREMENTS

• Redundancy requirements Multiple Hardware Cross - monitoring Signal routing / Installation Fault detection / recovery action / recording dormant failure detection(CBIT/PBIT/1st line/2nd line Servicing) Dedicated safety devices - Interlocks Pilot Procedures Maintenance Procedures

• Non Functional requirements in support of safety case

SOFTWARE SAFETY ENGINEERING

• METHODS FOR THE PRODUCTION OF SOFTWARE

• High level languages (Ada)

• Modular Software

• Structural analysis of the code

• Object as a mechanism for data abstraction and information

hiding

• Controlled change

• Process metrication (eg. Error injection/detection)

• Targeted methodical testing

• Systematic human inspection

SOFTWARE SAFETY ENGINEERING (continued)

• Each of these process aims have improved the quality of the

end products

• The combination of all these features is greater than the sum

of it’s parts

• This process represents “conservatism” within this new engineering

discipline

SOFTWARE DESIGN FOR SYSTEM SAFETY

* A design should exhibit the following characteristics

• Simple, Small Components

• Minimum of Data-flow Between Units

• Suitable Policing of Data-flow.

• Correct Definition of Hardware Interface

• Traceable to Specification.

• Satisfies All Specification Requirements (Complete)

• Unambiguous

• Consistent

• Sufficient Level of Detail

Simple, Small Components

* A Complex Design is Hard to Verify:

• Test Cases for Path Coverage increase exponentially with branches

10 IF Statements = = 1024 Paths • Easier to Understand and Review

Failure to Understand = = Failure to Review • Even simple design notation can be used to create a complex design

Minimum of Data Flow Between Units

* Ensures Units can be Tested Easily:

• Improves Maintainability - Units Less Dependent on Each Other

• Enables and Enhances Reuse • Enables and Enhances Maintenance

Policing of Data Flow (1)• Units should not be allowed to access data which they do not use:

- Ada Packages are “IN!”

• Units should always not have redundant data flows:- use all input data- define all output data

• The Access Modes (Read/Write) should also be controlled by the Design and Implementation Notations:

- OOD only allows Data Access between

Objects by Methods/Procedure Call

- Ada IN/OUT Parameters

Policing of Data Flow (2)

• Data-flow should be Formally Described at the Detailed Design Level using Flow Relations:

- procedure X derives DATA2 from DATA1

• Data flowing between independently scheduled units must use an appropriate message passing protocol to ensure data consistency. The message passing protocol must have defined predictable timing and freshness properties.

Correct Definition of Hardware Interface (1)

• Each Hardware Data Item must be Formally Defined:Eg. Mechanism (discrete, analogue, bus)

Required/Available Update Rate Accuracy Requirements (including how they are satisfied)

• Particular Problem Areas:- Ensuring that consistent bus data messages are read- Appropriate filtering of analogue data- Using correct addressing modes for hardware- Validation of hardware signals:

Dynamic & Static Tags, Range Checks, Trail TagsCorrective Action must be defined by the Specification

Correct Definition of Hardware Interface (2)

• Techniques for ensuring data consistency:- Semaphores

- Advantage: Simple, data always fresh- Disadvantage: Blocking of one process by another

- Multiple reads- Advantage: Simple, no blocking, static access- Disadvantage: Dependent on update time of source

process

- Double buffering- Advantage: No blocking, no waiting- Disadvantage: Complex, high memory usage

Traceable to the Specification

• Each function must be easily traceable to a specification statement:Eg. Scheduler - salient information must be in the Specification

Satisfies all Specification Requirements

• Must correctly implement every requirement

Unambiguous

• Notation must be simple and precise

Consistent

• There should be no Contradicting design statement

• There should be a consistent policy for data hiding,data access etc. Sufficient Detail

• The appropriate balance must be struck between a sparse design, with pointers back to the specification, and inclusion of all the algorithm in the design. Neither extreme leads to a useful design.

Deterministic

• In this context determinism is a relative term. The operation of the system must be easily predictable, both in terms of function, timing behavior and memory requirements.

• Examples of implementations which are difficult to predict:- Interrupts (function and timing hard to predict)- Tasking (function and timing hard to predict)- Processor Instruction Caching (timing)- Access Types, ie. Pointers (memory)

Defensive Programming• Objective :

To ensure the continued safe operation of the software in the presence of exceptional events.

• Exceptional Events could be : Transient Hardware failures causing incorrect system operation Software faults in other parts of the system

• Continued Predictable Operation could be : Performing some reversionary action defined by the specification Limiting the effect of the event so that degraded operation is

possible Correcting the effects of the event and continuing

The Need for Defensive Programming• The following factors must be considered in determining whether defensive programming is appropriate for a given exceptional event

The probability of the event occurring (EVENT) The probability the event will be detected by the defensive mechanism (DETECTION) The probability that the event will lead to an undesirable event (PROPAGATION) The degree of undesirability of the event (EFFECT)

• The decision to use a given technique will always be based on engineering judgement ratified during the software review. The effect of using any technique on complexity, testing and analysis must be considered.

Example of Defensive Programming

Variable in RAM

Case where Variables are held in RAM for Long Periods ie. periods longer than one processing cycle

Analysis

Event

Detection

Propagation

Effect

Improbable

Probable

Assured

Critical

• Detection Mechanism Options Stored Duplicate Stored Checksum Coded Representation

• Recovery Action Options Replacement by Application safe default Abandon function


Scheduler

The scheduler will have a mechanism for regaining control of the processor in the event of a non-critical process over-running its allowed time and hence affecting a critical process.

Analysis

Event

Detection

Propagation

Effect

Remote

Assured

Probable

Critical


Range Checking

To prevent the effect of data corruption each sub-program could range check all input variables.

Analysis

Event

Detection

Propagation

Effect

Negligible

Probable

Probable

Marginal

Defensive Programming

• Specific requirements or general guide-lines on error recovery action should be included in the Specification.

• The Design should define a consistent strategy for implementation of Defensive Techniques.

• The following techniques are not classified as Defensive Features : Hardware built-in test Input range checking Checking dynamic tags

These are all Functional Requirements and should be detailed within the Specification.

Disadvantage of Defensive Techniques

• Application of Defensive Techniques may result in logically infeasible code paths:

Difficult to test unintrusively Have to be justified during Code Analysis

• Application of Defensive Techniques increases the number of paths through the code :

More test cases required Code harder to understand / more complex

• Application of Defensive Techniques will increase data dependencies :

May impair Information Flow analysis by masking true flowEg. A checksum on a set of variables

Software Down-Loading

• Objective :To ensure that the complete software build is downloaded correctly to the Aircraft and to ensure that no computer canstart-up without a correct software load.

• Possible Source of Error : Configuration Control: (Wrong version of software loaded) Low integrity loader utilities: (Corruption of loaded image) Transmission errors: (Hardware failure) Partial loads

General Rules on Loading Integrity

• Target loading process should be controlled by high integrity software.

• Target loader should contain specific parity checks and checksums

to detect transmission errors.

• Target image should be read back to ensure that it is correct.

• Target unit should generate a checksum on every power-up which is

independently verified. Application should not start if the checksum

fails.

• Target unit should be capable of identifying its software version in

response to an external request.

AVIONICS SYSTEMS AND SOFTWARE Part 2. AVIONICS SYSTEMS AND SOFTWARE Real time considerations in...

Documents

Transcript of AVIONICS SYSTEMS AND SOFTWARE Part 2. AVIONICS SYSTEMS AND SOFTWARE Real time considerations in...