Post on 08-Jan-2016
description
AVIONICS SYSTEMS AND SOFTWARE
Part 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
AVIONICS SYSTEMS AND SOFTWARE
• 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
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).
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.
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.
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
• 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
REAL TIME CONSIDERATIONS IN AVIONICS
SYSTEM / SOFTWARE DESIGN
* 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.
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.
GENERAL AVIONICS COMPUTER
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
Avionics System/Software Development Process
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
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
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
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 !
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
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
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
Avionics Simulation and Prototyping
• 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
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
Detection
Propagation
Effect
Remote
Assured
Probable
Critical
Example of Defensive Programming
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.