FC2 Session 5-8 AFC

8/13/2019 FC2 Session 5-8 AFC

1/140

Aircraft Systems Integration

Andrs Feito

[email protected]


2/140

FC2 Session: 2 A.Feito,B.Delicado, Airbus Military 2011

Contents

Origin and Background of Aircraft SystemsIntegrationInter-System CommunicationFlight Deck

Aeronautical Requirements for Aircraft Systems:Environmental requirementsEMI/EMC

Safety AssessmentRequirements for Embedded Software


3/140


Inter-System Communication

Origin and Background of AircraftSystems Integration


4/140


On December 17th , 1903 , Wilbur and Orville Wright performed a featnever before accomplished; taking off, flying and landing in a manned,powered, heavier-than-air craft.

4

Flight and Systems


5/140

FC2 Session: 2 A.Feito,B.Delicado, Airbus Military 2011 5

At the beginning flight was controlled and managed by mechanicalsystems totally , introducing progressively pneumatic and hydraulicsystems to reduce the requirement of force from pilot.

Flight and Systems


6/140


The 1930s saw the introduction of the first electronics aids to assuregood operational reliability sucha blind flyingradio rangingnon-directional beaconsground-based surveillance radar

and the single-axis autopilot

Systems evolution


7/140FC2 Session: 2 A.Feito,B.Delicado, Airbus Military 2011 7

AVIONICS is a word coined in the late 1930s to provide a generic namefor the increasingly diverse functions being provided by AVIationelectrONICS .

Avionics

Nowadays any system in the aircraft isdependant on electronics for its operation



The 1940s saw developments inVHF Communications, Airborne intercept radar,Identification Friend or Foe (IFF),Gyro compass, attitude and heading reference systems,First electronic warfare systems,Military long-range precision radio navigation aids,and the two-axis autopilot.

Systems evolution

Estimu lated by World War II



The 1950s saw the introduction of Tactical air navigation ( TACAN ),

Airbone intercept radar with tracking capability and Doppler radar,Medium pulse repetition frequency ( PRF ) airbone intercept radar,The early digital mission computersInertial navigation systems.

The 1960s saw the introduction ofIntegrated electronic warfare systems,Fully automated weapon release,Terrain-following radar,

Head-up display,

Systems evolution



Many of the aircraft systems andsubsystems up to the early 1970s ,were still largely analogue in theirimplementation with synchro andpotentiometer outputs/inputs requiringpoint to point wiring to interconect them.

Systems evolution



By the late 1970s and early 1980s , itbecame possible to implement moresystems and sub-systems digitally , andso eliminate the analogue computingelements and the analogue input/outputelements and devices.

The integrated circuit permitted extremalysophisticated electronics to be stuffed intothe smallest of containers ( chips ).

Systems evolution



Digital electronics providefor greater reliability,faster response,smaller components,lighter equipment,and lower operating costs than can beprovided by analog systems.

That is why that modern civilian andmilitary aircraft contain countless digitalsystems,

EF2000 has more than 34 digital computers.

Systems evolution



The microcomputer , having reached alevel of maturity, was and is controllingmany tasks required for flights.

The workload of the flight crew isbeing reduced , thus lessening fatigueand increasing performance.

Systems evolution



Digital systems increase the mean time betweenfailures ( MTBF ) and reduce the subsequent repairtime for failed equipment.

The built-in test equipment ( BITE ) found in mostdigital systems provides rapid fault isolation andcontributes also to safety aspects.

The majority of the digital aircraft systems containseveral line replacement units ( LRUs ).Defective LRUs may be quickly identified by theBITE system and exchanged during groundmaintenace. So it reduces aircraft maintenacedowntime.

Normal mode (continuous) and Interactive BITE.

Systems maintenance



Internal fault detection andInterfaces monitoring

Power ONSelf Test

Confirmation

Unitinternal

Monitoring

Peripherals

BITE

FWS, CDS, HUD, Panels

cockpit/cabin effect

System reconfiguration

Failureadaptation

stimuli Manual tests

I n t er a

c t i v eM

o d e ( O

n Gr o

un

d )

Memorisation

Failuremessage

CMS (Central Maintenance System)

Transmission toCMS

Analysis(Fault

isolation)

Rawfailure

data

N or m

al M

o d e

Systems maintenance



More and more electronic systems werebeing installed in civilian and military aircraft.

The early airline crew of three was reducedto two in civilian aircraft, the flight engineerbeing replaced by electronic systems.

The glass cockpit permitted graphicdisplays of flight data and parameters that ismore intuitive and easy to understand.

Systems evolution


17/140


Nowadays most systems dependson electronic digital computers orLRUs for its effective operation, butthere are also equally essentialelements in the system ( sensors,

electro-mechanical elements anddevices, etc. )

Systems evolution


18/140


Those avionic systems ( HW/SW ) which manage flight critical

information ( Safety Critical classification ) require further certificationrequirements than others.

HW-SW Design


19/140


20/140


Saving fuel

20% Materials20% Aerodynamics20% Systems40% Engines


21/140


More Electrical Aircraft

22


22/140


22

More Electrical Aircraft


23/140





24/140


25/140


The avionics use digital data buses

with standardized physical andelectrical interfaces to send theirinternal data to other avionics

The data ( in buses ) may comprisesensor information,the results of internal calculations,system commands,information from internal storage,relayed data,

or any information that may be generatedby a computational device.

Systems to control Flight Parameters


26/140


Digital buses overview

ARINC 429Linear

Mono-sender /Multi-receivers

ARINC 629Linear

Multi-senders /Multi-receivers

ARINC 629extHUB


AFDXSwitch


1970 1980 1999 2005

100 Kb/s

1 Mb/s

10 Mb/s

> 100 Mb/s

DataThroughput

Year

Avionics communication busses progress

MIL 1553BLinear 1 BC

Multi-sender /Multi-receivers

A664Optic fiber/Switch

Multi-senders / Multi-receivers

2009

CAN BusLinear

Multi-sender /Multi-receivers

Wireless ???


27/140


ARINC 429Receiver

ARINC 429Receiver

ARINC 429Receiver

ARINC 429Transmitter

100 Kb/s Voltage Mode Up to 20 receivers

ARINC 629Terminal

2 Mb/s Current Mode Up to 120terminals

ARINC 629Terminal

ARINC 629Terminal

A629 / MILBUS -1553 configuration (linear bus)

AFDX configuration (Star bus)

AFDX E/S AFDX E/S AFDX E/S

SWITCH100 Mb/s Voltage Mode

Up to 24 portstransmitters/receiver

s

A429 configuration (linear bus)

Digital buses overview


28/140


A429 Overview

Each bus has only one transmitter and up to 20 receivers;however, one terminal may have many transmitters or receivers on different buses. A receiver is not allowed toever respond on the same bus where a transmission hasoccurred

The transmitter sends out the 32-bit word, LSB first, over the wire pair in a tri-state clocking, Return to Zero (RZ)methodology.

The actual transmission rate may be at the low or highspeed of operation: 12.5 kHz (12.5 to 14.5 kHz) and 100kHz ( 1%).


29/140


A429. Topologies

The choice of wiring topology is usually related to thedistance and proximity of the sinks to the source.There are two topologies:

Star, andBus drop.

Safety vs. weight.


30/140


A429. Some details. Data

A typical ARINC 429 word provides 19 bits for data.Since the SDI is optional, 21 bits are available for use. Somemanufacturers custom data word configurations use only theLabel and the Parity, providing 23 bits available for their data

All BCD data are encoded using bit numbers 1 4 of the seven-bit-per-character code as defined in ISO Alphabet No. 5.BNR data parameters are defined by first determining theparameters maximum value, then the resolution required. TheLSB of the data word is then assigned a value equal to the

resolution increment .


31/140


A429.Some details. SDI

Is optional and considered to add an extension ontothe ARINC words LabelThe SDI has two functions:

1. To identify which source of a multisystem installationis transmitting the data contained.

2. To direct which sinks (destination) on a multilistenerbus (known as a multisystem installation) shouldrecognize the data contained within the ARINC word


32/140


A429. Sign Status Matrix

The Sign/Status Matrix (SSM) is used for two purposes:1. To provide a sign or direction indicator (+, , north, south,

east, west, etc.) for data contained within the ARINC 429word

2. To provide source equipment status information as relatedto the data word for the sinks:1. Report hardware equipment condition (fault/normal)2. Operational Mode (functional test)3. Validity of data word contents (verified/no computed

data)Each Label has its own unique implementation of the SSMSign function.


33/140


34/140


MILBus 1553B Overview

The standard defines four hardware elements:

1. The transmission media.

2. Remote terminals.

3. Bus controllers.

4. Bus monitors.


35/140


MILBus 1553B. Bus controller

Is responsible for directing the flow of data on thedata bus.

Is the only one allowed to issue commands onto thedata bus.


36/140


MILBus 1553B. Word Types

Three distinct word types are defined by the standard:


37/140


AFDX


38/140


Flight Deck

Flight Deck


39/140


Crew interfaces play an important role in :

1. assuring that the crew can interact withthis avionics.

Pilot/Crew Interfaces with Systems


40/140


Crew interfaces play an important role in :

2. the aircraft can be flown effectively andsafely since they provide the crewsituational awareness of the aircraft andinformation of the environment in which the

aircraft flies.



41/140




42/140




43/140


EFIS



44/140


System display



45/140


E/W display



46/140




47/140




48/140


Flight Deck Requirements

Control and Information requirements.Basic System. Aircraft system (Flight Control system,Power plant and Landing Gear system)

o control the aircraft around its center of gravityo control the aircraft speedo establish and keep the aircraft trajectory on a given patho control the aircraft configuration: slats, flaps, speed brakes,

landing gear o control the thrust delivered by the engineso steer the aircraft on ground .

48


49/140


50/140


51/140


Control and Information requirementsBasic System. Utility Control systemo to control and monitor the various aircraft systems (bleed air,

electrical, fuel, engines,)o to apply procedures in both normal and abnormal situationso to modify the flight plan as decided (rerouting, diversion,change of

flight level,).

Basic System. D&C systemo to achieve the above tasks, flight crew need appropriate control

meanso in order to properly monitor the airplane, the flight deck provides

the appropriate information

51



52/140


Control and Information requirements Additional System. Military Communications andNavigation system

o to communicate with the Military Tactical control, other militaryairplane ...

o to communicate with the Command and Control Centerso to fly the airplane along the expected route using military

navigation aids

Additional System. Mission systemo to maintain aware of the changes of the scenario, mission plan

and threat using Data Links networkso to re-plan the mission as required by Command and Control

Centers using Mission Planning System

52



53/140


Control and Information requirements Additional System. Air to Air Refuelling systemo to control and monitor Refuelling systemo to control Booms and Pods operation (Tanker)o To control boom receptacle (Receiver)

Additional System. Electronic warfare systemso to know the position of the missile threatso to fly the airplane follow the commands cueso to control the countermeasures dispensingo to control and monitor anti-jamming

53



54/140


55/140


Forward Fuselage requirementsThe external boundaries of the Flight Deck in terms ofwindshield and fuselage are often influenced morestrongly by aerodynamic, performance, structural andequipment installation (radar) considerations than byFlight Deck principles.Nevertheless, a compromise have to be found taking intoaccount the Internal FD Geometry (DEP, NSRP, ExternalVision, Windshield)

55


Crew Task Analysis /


56/140


Crew Task Analysis /System Function Allocation

Flight Crew Operational Concept:

Main Flight Crew Functions Assignmento Responsible R - the crewmember responsible for over-seeing that

the task is performedo Execute E - the crewmember responsible for executing the task o Verify V- the crewmember that verifies that the task has been

completed

56

Crew Task Analysis /


57/140


Flight Crew Operational Concept (con t):

57

MAIN CREW FUNCTIONS Capt MCD PF PNF ARO MCO

Mission Planning before flight R V E

On-aircraft Mission Management and Re-planning

R V E

Flying the aircraft (AAR speed, altitudeetc) R E V

Military navigation aids and Radiomanagement

R V E

ATC (civil/military) Communications R V E

Military tactical communications, HQ R V E

Follow-up ARA & Timing R E V

Communications with receivers forRV/formation

R E V

Calculation of the critical parameters forRV R V E

Communication with receivers for AAR R V E

Boom or pods operation R V E

AAR devices management R E V/E

Mission Fuel management R E V

Military Tactical Situational Awareness R V E

C ew as a ys s /System Function Allocation


58/140


HE in Test and EvaluationMethodology and metric: HMI evaluations. MCHscale

58


59/140


Methodology and metric: Workload. BedfordScale

59

Enough spare capacity for all desirableadditional tasks.

Workload Low.

Workload Insignificant.

WL 2

WL 1

WL 3

Little spare capacity. Level of effort allowslittle attention to additional tasks.

Reduced spare capacity. Additional taskscannot be given the desired amount of

Attention.

Insufficient spare capacity for easy attention

to additional tasks.

WL 5

WL4

WL 6

Extremely high workload. No spare capacityserious doubt as to ability to maintain level

of effort.

Very high workload with almost no spareCapacity. Difficultly in maintaining level of

Effort.

Very little spare capacity, but maintenanceof effort in the primary task not in

Question.

WL 8

WL7

WL 9

Task abandoned: pilot unable to applysufficient effort.

WL 10Was it possible to complete

the task?

Was workload satisfactory

tolerable for the task?

Was workload satisfactorywithout reduction?

YES

YES

YES

NO

NO

NO

DECISION TREE WORKLOAD DESCRIPTION RATING

Enoughspare capacity for all desirableadditional tasks.

Workload Low.

Workload Insignificant.

WL 2

WL 1

WL 3

Little spare capacity. Level of effort allowslittle attention to additional tasks.

Reduced spare capacity. Additional taskscannot be given the desired amount of

Attention.

Insufficient spare capacity for easy attention

to additional tasks.

WL 5

WL4

WL 6

Extremely high workload. No spare capacityserious doubt as to ability to maintain level

of effort.

Very high workload with almost no spareCapacity. Difficultly in maintaining level of

Effort.

Very little spare capacity, but maintenanceof effort in the primary task not in

Question.

WL 8

WL7

WL 9

Task abandoned: pilot unable to applysufficient effort.

WL 10Was it possible to complete

the task?

Was workload satisfactory

tolerable for the task?

Was workload satisfactorywithout reduction?

YES

YES

YES

NO

NO

NO

DECISION TREE WORKLOAD DESCRIPTION RATING

HE in Test and Evaluation


60/140


Aeronautical Requirements forAircraft Systems

Aeronautical requirementsfor aircraft systems

Environmental requirementsEMI/EMCSafety assessmentRequirements for Embedded Software

Requirement-setting for


61/140


q gSystems

For all aircraft, safety of flight in all possible flight regimes is theprim e requirement .Second only to safety, the mission of the aircraft is the principaldriver of requirements in terms of aircraf t perform ances .

61

Requirement-setting for


62/140


Finally, certification is a major factor in system design. As thecom plex i ty and c r i t ica l ity o f av ion ics increases so does the need forextensive certification activities.

62

q gSystems

Ai f C ifi i d Q lifi i


63/140


Aircraft Certification and Qualification

Certification Legal recognition,through issuance of a certificate byaviation authority, that a product,service, organization, or personcomplies with that authority srequirements.

Airworthiness Airworthiness isachieved, when the fulfilment ofcertification requirements has beendemonstrated for a flying system.

63

EASAEuropean Aviation

Safety Agency

Instituto Nacionalde Tcnica Aerospacial

Behind Aircraft/ Aircraft System certification is the achievement ofairworthiness to guarantee a safe f ligh t .


64/140

Ai f C ifi i d Q lifi i


65/140


Qualification The demonstrationto the customer that his systemrequirement are met by the finalproduct ( system ).

Qualification and Certification areparallel complementary processeswith a different final aim, beingpossible reuse some evidences forboth ( overlapping ).

CertificationAuthorities

Requirements

CustomerRequirements

Certification Qualification

CertificationAuthorities

Requirements

CustomerRequirements

Certification Qualification

Aircraft Certification and Qualification

Ai b S t C t i t


66/140


Airborne Systems ConstraintsAirborne System ( equipment ) is very different in many ways from

ground based system carrying out similar functions.Reasons are :o The importance of acheiving minimum weight .o The adverse operating environment particularly in terms of operating temperature range,

acceleration, shock, vibration, humidity range and electro-magnetic interference.o The importance of very high reliability and safety .o Space constraints particularly in military aircraft requiring an emphasis on miniaturisation

and high packaging densities.

66

To meet requirements can result in the system (equipment) costingup to ten times as much as equivalent ground based electronicsystem ( equipment).

Mi i i ht


67/140


Minimum weight

An increase in the weight of the equipmentand elements of a system, requires theaircraft structure to be increased in strength,and therefore made heavier, in order towithstand the increased loads duringmanoeuvres.

This increase in aircraft weight meansthat more lift is required from the wings andthe accompaning drag is thus increased. Anincrease in engine thrust is thereforerequired to counter the increase in drag and

the fuel comsuption is thus increased.

67

E i t l R i t


68/140


Environmental Requirements

The environment is which system

( equipment ) has to operate can be verysevere and adverse one in military aircraft;the civil aircraft environment is generallymuch more benign but is still an exacting one.

The operating temparature range for militarycockpit is usually specified from 40C to+70C.

68

DO-160 chapters69


69/140


DO-160 chapters

Section 1.0 Purpose and ApplicabilitySection 2.0 Definitions of Terms - General

Section 3.0 Conditions of TestsSection 4.0 Temperature and AltitudeSection 5.0 Temperature VariationSection 6.0 HumiditySection 7.0 Operational Shocks and Crash SafetySection 8.0 VibrationSection 9.0 Explosion ProofnessSection 10.0 Waterproofness

Section 11.0 Fluids SusceptibilitySection 12.0 Sand and DustSection 13.0 Fungus ResistanceSection 14.0 Salt SpraySection 15.0 Magnetic EffectSection 16.0 Power InputSection 17.0 Voltage SpikeSection 18.0 Audio Frequency Conducted Susceptibility - Power Inputs

Section 19.0 Induced Signal SusceptibilitySection 20.0 Radio Frequency Susceptibility (Radiated and Conducted)Section 21.0 Emission of Radio Frequency EnergySection 22.0 Lightning Induced Transient SusceptibilitySection 23.0 Lightning Direct EffectsSection 24.0 IcingSection 25.0 Electrostatic DischargeSection 26.0 Fire, Flammability


70/140



71/140


The electromagnetic compatibility( EMC ) requirements are also verydemanding.The system ( equipment ) must not exceedthe specified emission levels for a verywide range of radio frequencies and mustnot be susceptible to external sources of

very high levels of RF energy over a verywide frequency band.The system ( equipment) must be able towithstand lightning strikes and very highelectromagnetic pulses ( EMP ) whichcan be encountered during such strikes.

71


72

EMI basics


72/140


EMI basics

Lightning effects



73/140


Design of electronic equipment to meet

EMC requirements is in fact a very exactingdiscipline and requires very careful attention todetail design.

73


74

EMI basics


74/140


Conducted: Power lines Signal lines

Radiated: Electric field

Magnetic field Plane waves

EMI basics

Ways to mitigate EMIinterference: Supress the emission at thesource Obstruct the coupling path Hardening the receiver toemissions

EMI

Up to 150 KHz:Conducted interference dominates

150 KHz to 30 MHz:Interference propagates through acombined mechanism of conducted andnear field radiated coupling

30 MHz to 18 GHz:EMI propagation by radiation

75

EMI basics


75/140


EMI basics

Capacitive coupling:Increasing the distance betweenconductorsUsing an electric shield betweenconductorsDecreasing the value of dV/dt

Inductive coupling:Decrease source and victim loopareas

Put conductors oriented at 90angleIncrease the distance betweenconductorsShield, filter or add ferrites to sensiblecablesDecrease value of dI/dt

76

EMI basics


76/140


EMI basics


77/140

Route examples


78/140


Route examples

78

Route G: generation drives thepower from engine generators topower centers.

Route M: Is a miscellaneousroute for non sensible andlow power loads

79

Principle diagrams


79/140


Principle diagrams

Within a PD system designers shall define:Wire gauge, taking into account voltage drops and aircraft zoneThe routs to comply with segregation requirementsThe protections in the harnesses: shielding, twisted wires

Installation team will derive the Wiring Diagrams for electrical installation


80/140

Reliability


81/140


Every possible care is taken in the design of Avionics to achieve maximum reliability. The

quality assurance ( QA ) aspects are verystringent during the manufacturing processesand also very frequently call for what isreferred to as reliability shake -downtesting , or RST, before equipment isaccepted for delivery.

RST is intended to duplicate the most severeenvironmental conditions to which theequipment could be subjected, in order toeliminate the early failure phase of the

equipment life cycle ( what is generallyreferred to as the infant mortality phase ).

81

Reliability

Standards and Guidances


82/140



The most general design cycle proceeds from concept through adesign phase to a prototype test and integration phase(deve lopment ), ending finally in release to produc t ion .Requirements are defined at different levels :

EquipmentSystem or Sub-sytemOverall System ( platform )

82



83/140


To define Engineering Requirements for Design, Analysis, Validation and

Verification ( qualification & certification ), are used standards andguidances .

83

Standards,

Guidances,

Know-how,

Technical judgment,

Lessons-learnt, ....




84/140


Typical types of requirements [ SAE ARP 4754]:o Safety Requirementso Functional Requirementso Customer Requirementso Operational Requirementso Performance Requirementso Physical and Installation Requirementso Reliability, Maintainability, Testability Requirementso Security Requirementso Interface Requirementso Safety Requirementso Certification Requirementso Qualification Requirementso

Software Development Tool Requirementso Test Requirements

84

Mandatory to completeadequately the V+V plan and

therefore the productcertification.




85/140


US and European organisations are working on harmonisation ofstandards. Most important regulatory organisations or standardsdevelopers :

85

So c ie t y o f A u t o m o t iv e En g i n ee r s T h e E u r o p ea n Org a n iz at i o nfo r Civ i l Av ia t ion Equ ipmen t

The Radio TechnicalCommiss ion fo r Ae ronau t i c s

The Inst i tu te of Electr ica l andElectronics Engineers

FAAEuropean Av ia t ion Sa fety A gency(EASA)

North Atlant ic Treaty Organizat ion( NATO )

United States Department ofDefense ( US DoD)

Aeronautical Radio IncorporatedInternational Civil Aviation Organization(ICAO),

International Civil Aviation Organization(ICAO),




86/140


Typical standards and guidances used by airframe manufacturers todefine the overall requirements from design to certification for airbornesystems ( equipment ).

SAE ARP4761 Safety Assessment Guidelines ( criticality analysis, fault tree analysis techniques, Failure mode andeffects analysis )SAE ARP4754 Certification Considerations for Highly Integrated or Complex Aircraft SystemsISO 15288 Management for the Systems Engineering Process SAE ARP4761 Safety Assessment Guidelines (criticality analysis, fault tree analysis techniques, Failure mode and effects analysis )

RTCA DO-160 Environmental Conditions and Test Procedures for Airborne Equipment MIL-STD-810 Environmental Engineering Considerations and Laboratory Tests RTCA DO-178B Software Considerations in Airborne Systems and Equipment Certification MIL-STD-498 Software Development and DocumentationRTCA DO-254 Design Assurance Guidance for Airborne Electronic Hardware MIL-STD-464 ELECTROMAGNETIC ENVIRONMENTAL EFFECTS REQUIREMENTS FOR SYSTEMS MIL-STD-461 Electromagnetic Emission and Susceptibility Requirements for the Control of ElectromagneticInterference.

ED-107/ SAE ARP5388 Guide to Certification of Aircraft in a High Intensity Radiated Field (HIRF) EnvironmentED-84 / SAE ARP5414 Aircraft Lightning Environment and Related Test Waveforms StandardED-113 / SAE ARP5577 Aircraft Lightning Direct Effects CertificationEASA CS-25 Certification Specification for Large Aeroplane ( also FAA FAR -25 )MIL-STD-1553B Aircraft internal time division command/response multiplex data busARINC-429 - Standard for the predominant avionics data bus used on most higher-end commercial and transport aircraft

86


ARP 4754 overview87


87/140


ARP 4754 is the civilcertification mean ofcompliance to coverhighly-integrated or

complex systems

ARP 4754 overview88


88/140


DAL assignedthrough Safety

Assessment can bereduced by means ofredundantarchitectures

Requirements evolution89


89/140


q

Certification requirements for aircraft, systems andequipment is always evolving increasing flight safety.

An example is the OBIGGS (On Board Inert GasGeneration System) that fills fuel tank with nitrogen toreduce flammability.


90/140


91/140

Safety Assessment


92/140


y


93/140

Safety Assessment


94/140


y

Safety Assessment


95/140


MIL-STD-882:

y

Safety Assessment


96/140


MIL-STD-882:

y

Safety Assessment


97/140


MIL-STD-882:

y


98/140

Safety Assessment


99/140


y

Safety Assessment


100/140



101/140

Fault-tolerant architectures


102/140


Consistency checks use a priori knowledge about information to verifycontinuously the correctness of that information managed within asystem. Examples:

Signal check (robustness checks)o Rangeo Rate of change

Run-away detector for program pointer. The binarycode instructions are located in an specific directions ofthe memory, any attempt to go out of this boundarycould be detected and restored.

Predicted performanceData diversity: input consolidation of multiple measuresfor the same signals

Fault-tolerant architectures


103/140


Memory checks: Available memory checksWrite and read the memory in specific locations tocheck the proper behaviour of the memory.Complementary to information redundancy techniques.

Processor checks: ALU tests, compare the output of certain predefinedoperations with verified results in ROMExecution time checks, monitoring the amount of timededicated to an specific task is under the expectedrange

Safety Assessment


104/140


Safety Assessment


105/140


-Active Failure:

A failure which can not remain in an aircraft more thanone flight. It is detected before the following flight andrepaired if necessary

-Risk Times:

Mean Flight Time: T0 is defined for each programRisk Time: The period of time within the flight duringwhich an item must failed in order to cause the fearedevent (Failure Condition under study)Eg: Failure to extend or downlock LG the complete flight = T0Repercussion Phase : the period of time in which thefeared event has a determined repercussion.Eg: Failure to extend or downlock LG Landing

Safety Assessment


106/140



107/140

Safety Assessment


108/140


HIRF and LIEprotection


109/140

PRA Particular risk assessment


110/140


UERF Uncontainedengine rotor failPRB Propeller bladereleaseTEFO Total engine flame

outLMES Loss of mainelectrical sourceWheel and Tyre FailureBird Strike

ZSA Zonal Safety Snalisys


111/140


Segregation ofcomponents:EquipmentWiring routesVulnerability

concepts

CMA Common Mode Analysis


112/140


A Common Mode Analysis shall be performed on each System

that can have potential catastrophic repercussions in case of failure. Identification of Catastrophic Failure Conditions

The method may be used for Hazardous failure

conditions when necessary. Identification of Independence Principles for these FCs Check all possible Common Mode Failures / Events for these identified Independence Principles (use Check List) Identification of segregation requirements Compliance record Accepted deviations record


113/140


Requirements for EmbeddedSoftware

Requirements for embeddedsoftware

SW Requirements


114/140


Example of Aeronautical SW


115/140


Aeronautical SW Example: A330-MRTT RAAF BCCS SW

Introduction to the Aeronautical SW


116/140


DO-178B

Provides guidelines for the production of SW for airborne systemsand equipment with a level of confidence in safety that complies withairworthiness requirements. Such guidelines are provided in terms of:- Objectives (to be achieved by the SW Life Cycle Processes).- Activities and design considerations for achieving the objectives.- Evidences that indicate the satisfaction of the objectives.

Defines three types of processes as part of the SW Life Cycle :- SW Planning Process: defines and coordinates the activities of therest of processes.- SW Development Processes: produce the SW product andcomprise the SW Requirements Process , the SW Design Process ,the SW Coding Process and the Integration Process .- Integral Processes: ensures the correctness, control and confidenceof the SW Life Cycle and their outputs and comprise the SWVerification Process , the SW Configuration ManagementProcess , the SW Quality Assurance Process and the CertificationLiaison Process .



117/140


DO-178B / SW PLANNING PROCESSDefines the means of producing SW which will satisfy the systemrequirements and provide the level of confidence which is consistentwith the airworthiness requirements.Process objectives Table A-1, SW Planning Process Objectives.Process activities: SW Plans should be developed . The purpose ofthe SW plans is to define the means of satisfying the objectives.



118/140


DO-178B / SW PLANNING PROCESSPlan for Software Aspects of Certification, PSAC

Primary means for communicating the proposed developmentmethods to the certification authority for agreement.

System Overview functions, HW/SW architecture, HW/SW I/Fs, safety features.

Software Overview SW functions, proposed safety and partitioning solutionsCertificationConsiderations

summary of certification basis, means of compliance, proposedSW levels and justification (PSSA)

SW Life Cycle processes description and objectives satisfaction

SW Life Cycle

Data

data to be produced and/or controlled and to be submitted to

the certification authoritySchedule certification authorities reviews planning

AdditionalConsiderations

specific features that may affect the certification



119/140


DO-178B / SW PLANNING PROCESSSoftware Development Plan, SDP

Defines the SW Life Cycle and the SW Development Environment.

Standards SW Requirements Std., SW Design Std. and SW Code Std.

SW Life Cycle processes description and transition criteria

SW DevelopmentEnvironment Requirements development and design methods and tools,programming languages, coding tools, compilers, linkers andloaders and HW platforms



120/140


DO-178B / SW PLANNING PROCESSSoftware Verification Plan, SVP

Defines the means to comply with SW Verification Process objectives.The verification procedures may vary by SW Levels.

Organization Fix organizational responsibilities and interfaces.

Independence Methods for ensuring verification independence when required.

Methods Reviews, analysis and testing methods.

Environment Equipment for testing, tools and guidelines for applying the tools.

Transition Criteria For entering this SW Verification Process.

Partitioning If partitioning, method to verify the integrity of partitioning.

Compiler Assumptions about the correctness of compilers and linkers.

Reverification For SW modification, affected areas identification.

Previous SW Way of compliance if previously developed SW doesnt comply.

Dissimilarity Description of both SW Verification Processes.



121/140


DO-178B / SW PLANNING PROCESSSoftware Configuration Management Plan, SCMP

Defines the means to comply with SW Configuration Mngt. Processobjectives.

The configuration control procedures may vary by SW Levels.Environment Procedures, tools, methods, standards, organizational

responsibilities and interfaces. Activities Items Identification, baselines establishment and traceability,

problem reporting, change control and review, archive andrelease methods, load control, tools control and CC1 and CC2controls.

Transition Criteria For entering the SCM Process.SCM Data Definition of SCM Data: SCM records, SW Configuration Index

(SCI) and SW Life Cycle Environment Configuration Index(SECI).

Supplier Control Apply SCM process requirements to suppliers.



122/140


DO-178B / SW PLANNING PROCESS

Software Quality Assurance Plan, SQAPDefines the means to comply with SW Quality Assurance Process

objectives.

Environment Scope, organizational responsibilities and interfaces, standards,procedures, methods and tools.

Authority Statement of the SQA authority (also approval for SW products). Activities Reviews, audits, reporting, inspections, monitoring of processes,

problem reporting tracking and corrective action and SWConformity Review activity.

Transition Criteria For entering this SW Quality Assurance Process.

Timing Timing of SQA process activities.

SQA Records Definition of records to be produced.

Supplier Control Means of ensuring that suppliers processes and outputs complywith the SQA Plan.



123/140


DO-178B / SW DEVELOPMENT PROCESS

Comprise 4 sub-processes:- SW Requirements Process- SW Design Process- SW Coding Process

- Integration ProcessThe linear SW development model is not required.Each sub-process is considered as finished when all the objectiveshave been achieved and the Verification and ConfigurationManagement activities have been performed.

Table A-2, Software Development Process general objectives.



124/140



SW Requirements ProcessThe SW Requirements Analysis Standard (identified in the SDP) isapplied and the SW Requirements Document is generated.The objectives of this process are:- Develop the SW High-Level Requirements from SystemRequirements , including functional, performance, interface andsafety-related requirements.- Derived SW High-Level Requirements are identified and shouldbe indicated to the System Safety Assessment (return of experienceshow us that this is not typically done). Not directly traceable toSystem Requirements . The Preliminary System Safety Assessment(PSSA) should add the impact on the safety of the implementation ofsuch derived requirements.Table A-3, Verification of Outputs of Software Requirements Process


125/140



126/140


DO-178B / SW DEVELOPMENT PROCESSSW Design Process

The objectives are to establish the SW Architecture and the SWLow-Level Requirements from the SW High-Level Requirementsand to define the Derived Low-Level Requirements .Table A-4, Verification of Outputs of Software Design Process,establish verification criteria (review/analysis) of the output of theSW Design Process.The primary output of the process is the Design Description , whichincludes:- Description of SW high level requirements satisfaction and how SWrequirements are allocated to processors and tasks.- Description of the SW Architecture and the Input/Output.

- Data and control flow of the design.- Resources limitations and Scheduling procedures.- Design and partitioning methods.- Reuse of previously developed SW Components.- Means to ensure that deactivated code cannot be enabled.



127/140



SW Coding ProcessThe objective of the SW Coding Process is the development of theSource Code , that should be traceable, verifiable, consistent andcorrectly implements the low-level requirements .Source code should implement the low-level requirements, conform

the SW Architecture, the SW Code Standards and be traceableto the Design Description .The output of the process consists of the code generated in sourcelanguage(s) and compiler and linker instructions for generatingthe object code.

Table A-5, Verification of Outputs of Software Coding & IntegrationProcess, establish verification criteria (review/analysis) of theoutput of the SW Coding Process. The most severe criteria is theverification of the robustness and the execution time.



128/140



Integration ProcessThe objective of the Integration Process is the loading of theExecutable Object Code into the target HW for HW/SWintegration.The Executable Object Code should be generated from the

Source Code and, once generated, loaded into the target computer.The output of the process consists of executable object codethat is directly usable by the CPU of the target computer and its theSW that is loaded into the HW or the system.Table A-5, Verification of Outputs of Software Coding & Integration

Process, establish verification criteria (review/analysis) of theoutput of the SW Coding Process. The most severe criteria is theverification of the robustness and the execution time.



129/140



TraceabilityThe traceability description is included into the SW DevelopmentProcess and its verification is included into the SW VerificationProcess.The traceability requirement depends on the SW Level .

Traceability is required in tables A-3, A-4 and A-5:- For Level A and/or B, traceability from source code to systemrequirements is required.- For Level C, traceability from SW low level requirements to systemrequirements is required.

- For Level D, traceability from SW high level requirements to systemrequirements is required.



130/140


DO-178B / INTEGRAL PROCESSESSW VERIFICATION PROCESS

RTCA is more precise when defining verification effort, whichincreases with the SW Criticality Level.Verification is not simply testing .Verification as a combination of reviews, analysis and tests .Reviews and analysis provide an assessment of the accuracy,completeness and verifiability of the SW requirements, SW

Architecture and Source Code.Test Cases may provide further assessment of the internalconsistency and completeness of requirements, and their executionprovides a demonstration of compliance with requirements.

Tables from A-3 to A-6 summarize review/analyses requirements fordevelopment activities.Table A-7 summaries review/analysis criteria for test cases definitionand results, including coverage checking.



131/140


DO-178B / INTEGRAL PROCESSES

SW VERIFICATION PROCESSReviews- Provide quality assessment of correctness.- May consist of an inspection, peer review, proof reading guided bya checklist or similar aid.

- To be performed on: Plans , SW High Level and SW Low LevelRequirements , SW Architecture and Design , Source Code andTest Cases, Procedures and Results .


132/140


133/140



134/140



SW VERIFICATION PROCESSOutputs of the SW Verification Process:- SW Verification Cases and Procedures : detail how the SWVerification Process activities are implemented (scope and depth ofthe review or analysis methods, test cases, expected results,

pass/fail criteria, execution instructions, test environment descriptionand how test results are evaluated).- SW Verification Results : summarizes the verification activitiesresults (reviews, analysis and tests).RTCA doesnt use the formal reviews SRR, PDR, CDR, TRR that

typically are used as project management mechanism. RTCArequires the review of the artefacts and the evidencesgeneration before they were used by further processes.



135/140


DO-178B / INTEGRAL PROCESSESSW CONFIGURATION MANAGEMENT PROCESS

Activities (guidelines for each activity are provided):- configuration identification : label each configuration item- change control : changes recording, evaluation, resolution,

approval and review

- baseline establishment and traceability : intermediate and SWproduct baseline should be established- problem reporting and tracking : record non-compliance with SW

plans or standards, deficiencies of outputs and anomalousbehaviour of SW products.

- archiving of SW product : ensure that only authorized SW is used- load control : ensure that the executable object code is loaded into

the airborne system with appropriate safeguards (P/N, Media ID,)


136/140



137/140



SW QUALITY ASSURANCE PROCESS Assesses the SW Life Cycle Processes and their outputs to obtainassurance that the objectives are satisfied , that deficiencies aredetected, evaluated, tracked and resolved, and that the SW productand SW Life Cycle Data conform to certification requirements.

Activities:- audit that SW plans and standards are developed and reviewed- audit that SW Life Cycle processes comply with SW plans and

standards- audits of the SW development and integral processes- audit that transition criteria between processes have been satisfied- audit that SW Life Cycle Data are controlled- conduct a SW conformity review prior to delivery of SW products



138/140


DO-178B / INTEGRAL PROCESSESSW QUALITY ASSURANCE PROCESS

SW Conformity Review (for each formal delivery): to obtainassurances, for a SW product submitted as part of a certificationapplication, that the SW Life Cycle processes and data are completeand the Executable Object Code is controlled and can beregenerated.



139/140


DO-178B / INTEGRAL PROCESSESCERTIFICATION LIAISON PROCESS

Establish communication and understanding between the applicantand the certification authority.The applicant should:- submit the PSAC to the certification authority- resolve issues identified by the certification authorities- obtain agreement with the certification authority on the PSAC- submit for each SW product to the certification authority :Software Accomplishment Summary (SAS) : shows compliancewith the PSAC and other plans, change history, deviations

justification, problem reports unresolved at certification time,including statement of functional limitations.Software Configuration Index (SCI) : Identifies the SW product, theexecutable object code, each source code component, documents,instructions for regenerating the executable object code

References


140/140

Aircraft systems Ian Moir and Allan Seabridge,Wiley and Sons, Third edition 2008.Introduction to Avionics, R.P.G. Collinson, Chapman & Hall.

The Avionics Handbook, CRC Press LLC, 2001 Airbus A330 Flight Deck and Systems Briefing for Pilots (Book Aircraft Manual),1999 ATA100 (Air Transport Association)MIL-HBDK-881 (US DoD) WORK BREAKDOWN STRUCTURES FOR DEFENSE

MATERIEL ITEMSAircraft systems Ian Moir and Allan Seabridge,Wiley and Sons, Third edition 2008.Introduction to Avionics, R.P.G. Collinson, Chapman & Hall.The Avionics Handbook, CRC Press LLC, 2001

Airbus A330 Flight Deck and Systems Briefing for Pilots (Book Aircraft Manual),1999EASA Part 21 Subpart JSystems Ingeneering Fundamentals, US Department of Defence, Systems

Management College.http://www.eads.com/http://www airbus com/en/
http://www.eads.com/http://www.airbus.com/en/http://www.airbus.com/en/http://www.eads.com/

Documents

FC2 Session 5-8 AFC