Transcript real time considerations in avionics system

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
REAL TIME CONSIDERATIONS IN AVIONICS
SYSTEM / SOFTWARE DESIGN
* CONCEPT OF DATA LATENCY:
T1
T2
T3
Acquisition
Process
Acquisition
Output
Process
Acquisition
T4
Output
Process
T5
Output
• 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
* 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 ( 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
TYPICAL SOFTWARE FUNCTIONAL ARCHITECTURE
(IN TERMS OF FUNCTIONAL MODULES)
(MISSION OR FLIGHT MGMT COMPUTER)
DISPLAY
RADAR
PILOT
CONTROLS
INS
RADAR
MGMT
6.25-50Hz
PILOTS
INPUTS
ACQUISITION
INS
MGMT
BANK OF NAVIGATION
GUIDANCE
AND
WEAPON RELEASE
MACRO FUNCTIONS
6.25-50 Hz
COMMUNICATION
LINKING
DISPLAY
PARAMETERS
SYNTHESIS
AIR DATA
COMPUTATION
COMMUNICATION
AIR DATA
SETS
SENSORS
PROCESSOR
WEAPONS
WEAPON
MGMT
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
PILOT INPUTS
- 50
INS-MGMT
- 25
ADC -6.25
DISPLAYSYNC
-50 Hz
DISPLAYSYNC
-6.25
RDRMGMT
-12.5
PILOT INPUTS
- 50
COMMLINK
-6.25
DISPLAYSYNC
-50 Hz
PILOT INPUTS
- 50
INS-MGMT
- 25
PILOT INPUTS
- 50
PILOT INPUTS
- 50
INS-MGMT
- 25
M6
PILOT INPUTS
- 50
DISPLAY- DISPLAY- DISPLAY- DISPLAYSYNC
SYNC
SYNC
SYNC
-50 Hz
-50 Hz
-50 Hz
-50 Hz
RDRMGMT
-12.5
RDRMGMT
-12.5
M7
M8
PILOT PILOT INPUTS
INPUTS
- 50
- 50
INS-MGMT
- 25
DISPLAY- DISPLAYSYNC
SYNC
-50 Hz
-50 Hz
RDRMGMT
-12.5
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
Minor
Cycle
Major 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.
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
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.
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
ASR/QR
MISSION ANALYSIS
COCKPIT CONTROLS AND
DISPLAY
DEGRADED MODES
COCKPIT
RECONFIGURATION
INITIALISATION
PILOTS WARNINGS
DATA BUS MANAGEMENT
ENTERTAINMENT
BASIC FLIGHT AND
NAVIGATION
AIR TO AIR
AIR TO GROUND
AIR TO SEA
AVIONICS SYSTEM REQUIREMENT
BROAD SPECIFICATION
DEFINITION
GLOBAL
SPECIFICATION OF
OPERATIONAL
FUNCTIONS
GUIDELINE
DOCUMENT
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
METHODOLOGY FOR S/W
REQUIREMENT ANALYSIS AND
FUNCTIONAL SPECIFICATIONS
DESCRIPTION OF COCKPIT
BUS UTILISATION GUIDELINES
EMI/EMC AND TEST PLANS
H/W ARCHITECTURE
S/W FUNCTIONAL
ARCHITECTURE
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 Tags
Corrective 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
Improbable
Detection
Probable
Propagation
Assured
Effect
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
Remote
Detection
Assured
Propagation
Probable
Effect
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
Negligible
Detection
Probable
Propagation
Probable
Effect
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 flow
Eg. 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 can
start-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.