AVIONICS SYSTEMS AND SOFTWARE Part 2

1. AVIONICS SYSTEMS AND SOFTWARE Part 2

2. AVIONICS SYSTEMS AND SOFTWARE • 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

3. AVIONICS SYSTEMS AND SOFTWARE • Software safety engineering • Software design for system safety • Defensive Programming

4. 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

5. REAL TIME CONSIDERATIONS IN AVIONICS 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).

6. REAL TIME CONSIDERATIONS IN AVIONICS • 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.

7. REAL TIME CONSIDERATIONS IN AVIONICS SYSTEM / SOFTWARE DESIGN * 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.

8. REAL TIME CONSIDERATIONS IN AVIONICS SYSTEM / SOFTWARE DESIGN * 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

9. REAL TIME CONSIDERATIONS IN AVIONICS SYSTEM / SOFTWARE DESIGN * CONCEPT OF DATA LATENCY: T1 Acquisition T2 Process T3 Output T4 Output Acquisition Process T5 Output Acquisition Process • 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

10. * 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

11. Software functional architecture ( mission Computer/flight mgmt computer ) * FUNCTIONS ( Say) • 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

12. TYPICAL SOFTWARE FUNCTIONAL ARCHITECTURE (IN TERMS OF FUNCTIONAL MODULES) (MISSION OR FLIGHT MGMT COMPUTER) DISPLAY PROCESSOR RADAR MGMT 6.25-50Hz DISPLAY PARAMETERS SYNTHESIS RADAR BANK OF NAVIGATION GUIDANCE AND WEAPON RELEASE MACRO FUNCTIONS 6.25-50 Hz PILOT CONTROLS PILOTS INPUTS ACQUISITION WEAPON MGMT WEAPONS I N S MGMT INS COMMUNICATION LINKING AIR DATA COMPUTATION COMMUNICATION SETS AIR DATA SENSORS

13. TYPICAL SCHEDULER OVER ONE MAJOR CYCLE * Major Cycle : 160 msec (6.25 Hz) * Minor Cycle : 20 msec (50 Hz) M1 - M8 M1 M2 M3 M4 M5 M6 M7 M8 PILOT - INPUTS - 50 PILOT - INPUTS - 50 PILOT - INPUTS - 50 PILOT - INPUTS - 50 PILOT - INPUTS - 50 PILOT - INPUTS - 50 PILOT - INPUTS - 50 PILOT - INPUTS - 50 INS-MGMT - 25 INS-MGMT - 25 INS-MGMT - 25 INS-MGMT - 25 ADC -6.25 COMM-LINK -6.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 DISPLAY- SYNC -50 Hz DISPLAY- SYNC -6.25 RDR-MGMT -12.5 RDR-MGMT -12.5 RDR-MGMT -12.5 RDR-MGMT -12.5

14. 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

15. 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 Minor Cycle 50 Hz Processors: run to completion in every minor cycle. 25 Hz Processors: run to completion in every alternate minor cycle. Remaining minor cycle time used to run Background Process: CBIT, etc.

16. 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.

17. GENERAL AVIONICS COMPUTER 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.

18. GENERAL AVIONICS COMPUTER FEATURES(HARDWARE) * SAFETY FEATURES The computer should assert its good functioning continuously and should shutdown(partially or wholly) in case of malfunction. Under no circumstances should it affect the working of other computers and data buses. • 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.

19. 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

20. Avionics System/Software Development Process ASR/QR MISSION ANALYSIS AVIONICS SYSTEM REQUIREMENT • COCKPIT CONTROLS AND DISPLAY • DEGRADED MODES • COCKPIT RECONFIGURATION • INITIALISATION • PILOTS WARNINGS • DATA BUS MANAGEMENT • ENTERTAINMENT • METHODOLOGY FOR S/W REQUIREMENT ANALYSIS AND FUNCTIONAL SPECIFICATIONS • DESCRIPTION OF COCKPIT • BUS UTILISATION GUIDELINES • EMI/EMC AND TEST PLANS BROAD SPECIFICATION DEFINITION GUIDELINE DOCUMENT FUNCTIONAL ARCHITECTURE GLOBAL SPECIFICATION OF OPERATIONAL FUNCTIONS • BASIC FLIGHT AND NAVIGATION • AIR TO AIR • AIR TO GROUND • AIR TO SEA • H/W ARCHITECTURE • S/W FUNCTIONAL ARCHITECTURE SOFTWARE REQUIREMENT ANALYSIS • SOFTWARE SPECIFICATION • *DETAILED SOFTWARE REQUIREMENT SPECIFICATION OF MC or FMC • DETAILED FUNCTIONAL /SOFTWARE SPECIFICATION OF OTHER EQUIPMENTS • SYMBOLOGY SPECIFICATIONS • INTERFACE CONTROL SPECIFICATIONS

21. Avionics System/Software Development Process • 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

22. Avionics System/Software Development Process • 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

23. Avionics System/Software Development Process • 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 !

24. 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

25. Avionics Simulation and Prototyping • 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

26. Avionics Simulation and Prototyping • 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

27. Avionics Simulation and Prototyping • Simulation ofNavigation Guidance and Weapon Aiming ( missiles, bombs ) Functions • This simulation is used during algorithm development( a part ofSystem 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

28. 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 Hardwarein Loop testingof 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

29. 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

30. Flight Control System(FCS) Testing • Rig for Hardware in Looptesting 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

31. 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

32. 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

33. 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

34. 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

35. 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

36. 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

37. 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

38. 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.

39. 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 Tags • Corrective Action must be defined by the Specification

40. 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

41. 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

42. 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.

43. 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)

44. 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

45. 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.

46. Example of Defensive Programming Variable in RAM Case where Variables are held in RAM for Long Periods ie. periods longer than one processing cycle • Detection Mechanism Options • Stored Duplicate • Stored Checksum • Coded Representation Analysis Event Improbable Detection Probable • Recovery Action Options • Replacement by Application • safe default • Abandon function Propagation Assured Effect Critical

47. Example of Defensive Programming 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 Remote Detection Assured Propagation Probable Effect Critical

48. Example of Defensive Programming Range Checking To prevent the effect of data corruption each sub-program could range check all input variables. Analysis Event Negligible Detection Probable Propagation Probable Effect Marginal

49. 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.

50. 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 flow • Eg. A checksum on a set of variables