0% found this document useful (0 votes)
18 views14 pages

13 UsingDesignPatternForSafetyAssessment33rdDASC Humberto-Cun-VDi

Uploaded by

JosueFerreira
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
18 views14 pages

13 UsingDesignPatternForSafetyAssessment33rdDASC Humberto-Cun-VDi

Uploaded by

JosueFerreira
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 14

See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/267327795

USING DESIGN PATTERNS FOR SAFETY ASSESSMENT OF INTEGRATED


MODULAR AVIONICS

Conference Paper · October 2014


DOI: 10.13140/2.1.5084.1603

CITATIONS READS
4 9,231

3 authors, including:

Adilson Marques da Cunha Luiz Alberto Vieira Dias


Instituto Tecnologico de Aeronautica Instituto Tecnologico de Aeronautica
234 PUBLICATIONS 955 CITATIONS 223 PUBLICATIONS 600 CITATIONS

SEE PROFILE SEE PROFILE

All content following this page was uploaded by Adilson Marques da Cunha on 24 October 2014.

The user has requested enhancement of the downloaded file.


USING DESIGN PATTERNS FOR SAFETY ASSESSMENT OF INTEGRATED
MODULAR AVIONICS
Humberto Luiz Valdivia de Matos, Adilson Marques da Cunha, Luiz Alberto Vieira Dias
Aeronautics Institute of Technology (ITA), Sao Jose dos Campos, SP, Brazil

Abstract Even before the advent of IMA, it was an open


issue the assessment of reuse of software, Line
In commercial aircraft, safety assessment uses a
Replaceable Units (LRUs), and entire subsystems
combination of top-down and bottom-up techniques.
within different application domains.
This is performed for every system in each aircraft
installation. Since several functions and sub-systems
are common to different aircraft models, there is the Traditional safety assessment approach
need to consider reusing components and safety in commercial aircraft systems
artifacts across several platforms. This necessity has
become even more evident with the introduction of An overview of the framework defined in [2]
the Integrated Modular Avionics (IMA) concept. and [5] is shown in Figure 1. This paper is focused on
There is an increasing interest in developing design the development of system architectures and its
patterns in safety-critical systems. This paper associated components. Therefore, greater emphasis
provides an investigation of how SysML/UML will be placed on the highlighted activities.
design patterns can be used to assess the safety of
IMA systems in a modular manner, while
maintaining compliance with the existing civil
aircraft certification guidelines. A case study is
provided for a generic avionics system based on the
IMA concept, fulfilling safety requirements for civil
avionics.

Introduction
Aircraft systems in commercial aviation are
required to show compliance with safety regulations,
most notably 14CFR 25.1309 [1]. This compliance is
normally shown using guidelines found in SAE ARP
4761 [2], which is a generic process applicable to all
types of aircraft systems, from purely mechanical
hydraulic systems to software intensive systems like
avionics or fly-by-wire systems.

The Integrated Modular Avionics (IMA) is


defined in [3] as a shareable set of flexible, reusable
and interoperable resources that form a platform to
host applications performing aircraft functions. A key
concept in this definition is resource reusability. This
concept was further emphasized by the FAA in [4],
with the introduction of the process of incremental Figure 1. ARP 4754A/ARP 4761 Safety
acceptances for reusable IMA components. Assessment process model (adapted from:[2][5])
This framework starts with an assessment of [2]. Though the definition of system-level safety
aircraft-level functions, such as provide lift and drag, objectives from the System FHA is straightforward,
control aircraft path, or provide thrust. This activity is defining the system architecture to achieve these
the Aircraft FHA (Functional Hazard Assessment). safety objectives is not.
This initial evaluation has little to do with the design
of the aircraft systems themselves and more with the Definition of system architecture is performed in
aircraft operational profile and its aerodynamic an iterative fashion. The systems architect defines an
characteristics. initial architecture and a set of assumptions
(including operational conditions and failure rate
The next step is to determine the system-level budgets), then runs one of the quantitative analyses
functions and their impact on the aircraft, crew and/or (most usually Fault Tree Analysis) to have a
occupants, should this function not operate properly. preliminary estimate of the compliance with safety
The System FHA classifies system-level hazards in objectives. In many cases, safety objectives will drive
five different categories (No Safety Effect, Minor, major architectural decisions, such as the number of
Major, Hazardous, Catastrophic). For each of these redundant channels and the monitoring strategy.
categories, safety objectives are defined and flown
down to the system design. The higher the impacts of Experienced system architects develop a set of
a failure condition in the aircraft safety, the stricter heuristics based on previous designs that comply with
are these safety objectives. For example, a failure the applicable requirements, including functional
condition classified as Catastrophic in the System requirements, performance, and safety. Though
FHA must be shown to be extremely improbable useful, these heuristics are continuously challenged
(probability below 10-9 per flight hour) and must not by the evolution in the safety objectives, system
result from a single failure. Safety objectives from requirements, or technology. Moreover, as Kelly and
ARP 4761 [2] are summarized in the following table. McDermid [6] point out, this informal (ad hoc) reuse
of safety case artifacts may be a source of a number
Table 1. ARP 4761 [1] Safety Objectives summary of problems, including inappropriate reuse of safety
arguments in different contexts, loss of knowledge,
Hazard Class Safety Objectives lack of consistency, and waste of resources, just to
Catastrophic Extremely Improbable name a few.
(CAT) (Prob < 1E-9 per flight hour) Integrated Modular Avionics Systems bring
No single failure these reuse concerns to a new level. In traditional
DAL A federated systems, an aircraft-level function such as
Stall Protection would be allocated to a defined set of
Hazardous Extremely Remote
Line Replaceable Units (LRUs): Angle-Of-Attack
(HAZ) (Prob < 1E-7 per flight hour) (AOA) vanes, Stall Computers, a Stick Pusher, and
DAL B an audio device (such as a horn), as shown in Figure
Major (MAJ) Improbable 2.
(Prob < 1E-5 per flight hour)
DAL C
Minor (MIN) Probable
(Prob < 1E-3 per flight hour)
DAL D
No Safety No requirements
Effect (NSE)

Demonstration of these objectives is performed


using quantitative methods such as Fault Tree Figure 2. Example of a generic Stall Protection
Analysis, Markov Chains or Dependency Diagrams system using federated architectures
A manufacturer of a Stall Protection System Distributed IMA or Adaptive IMA systems will make
would be able to sell the same set of components to this kind of question even more difficult to address.
several aircraft manufacturers, with minimal software
adjustments (gains and thresholds, for example) for
each different aircraft type. A number of safety Safety-related Design Patterns
artifacts, including Fault Tree Analyses (FTAs) and The software industry has been a long adopter of
Failure Modes and Effects Analyses (FMEAs) would the Design Patterns concept, which had in Gamma
be used throughout the entire product line, as well as [7] one of its early promoters. Douglass, in [8] and
a large portion of the software certification [9], enhances further the concept to include the
documentation [2]. specific needs of real-time systems, including safety-
critical ones. Armoush [10] takes one step further to
In an Integrated Modular Avionics system, this
create representations of these patterns for Safety-
aircraft-level function could be deployed in a much
Critical systems.
different way. Instead of dedicated LRUs performing
specific functions, generic hardware modules provide Though there is extensive research on the
services for a range of different aircraft functions, as application of design patterns in software
shown in Figure 3. These generic hardware modules development, Safety is a system issue, as pointed by
may not even be manufactured by the same company Douglass [9], which means that the safety aspects of
that produces the Stall Protection application. For software cannot be treated separately from the other
example, this means that such an application needs to aspects of the system. This is true also in commercial
be ported across several platforms for each customer. aerospace systems.

At the time of Douglass’ writings, however, the


SysML specification was not available and the
examples of design patterns were represented in
UML, which tends to be software-centric. Other
researchers like Kelly [6], Khalil et al. [11] use the
GSN (Goal Structuring Notation) to represent these
patterns. The objective in this paper is to use the
OMG SysML to describe these patterns at the
systems level and, if applicable, UML to represent
allocations at the software level.

Pattern description structure


Figure 3. Example of a generic Stall Protection
Using the safety case pattern structure defined
system using IMA
by Gamma [7] and Kelly and McDermid [6] as a
The implications for reuse in this case are much starting point, some adjustments have been made to
more dramatic. Significant portions of the application accommodate the specific processes of the ARP 4761
may be fully reused, including requirements and [2] framework and its safety objectives. This pattern
large parts of source code, but the safety analysis at description structure is described as follows:
the system and aircraft level (Tasks 3 and 4 of DO-
297 [3]) must be done nearly from scratch to • Pattern Name
accommodate the new context and hardware The Pattern Name provides reference to the
implementation. pattern itself in a concise, clear and unambiguous
way.
Moreover, the additional flexibility provided by
IMA brings also new challenges to system architects: • System safety objectives
how can applications and functions be allocated
throughout the IMA Platform in a way that satisfies This item describes the safety objectives to be
the safety constraints at all times? Future trends like accomplished by the system using this design pattern.
These objectives are driven by the system FHA, as effects of a failure or malfunction in one or two of
shown in Table 1. A system may have one or more these channels shall be analyzed and fed back to the
FHA failure conditions allocated to it (usually much FHA.
more than one) and the combination of conflicting
aspects (availability vs. integrity, for example) may • Implementation
drive the use of one safety design pattern rather than This item provides some insight on the
the other. implementation of the pattern, including problems
that may occur in specific scenarios.
In addition, it is important that this approach
should be scalable to several layers of subsystems. A In an Integrated Modular Avionics system, the
subsystem may be allocated to be part of the overall correlation between the abstract elements of the
safety objective and another, usually simpler design design patterns and physical components installed in
pattern, may be applicable. the aircraft may not be straightforward. The examples
in this paper will address these physical allocation
• Also Known As
restrictions as part of the design process.
This field refers to other names for which the
design pattern may be known (across different • Related Patterns
domains, for example). This item provides references to other patterns
that relate to similar safety issues.
• Pattern Structure
This item presents the pattern structure in a
Relevant Safety Design patterns for aerospace
SysML (for patterns at the system level) or UML (for
patterns at the software level).
industry
A brief review of some Safety Design Patterns
• Participants / Collaborations found in literature is provided as follows:
This item provides the interactions of the system
(or subsystem) with other actors. In commercial • Protected Single Channel Pattern (PSC)
aerospace system, these actors may be the flight This lightweight safety design pattern has the
crew, passengers, maintenance, Air Traffic Control advantage of being simple and inexpensive [8].
(ATC), weather, terrain, other aircraft-level functions Though it is obviously not capable of supporting
(like flight dynamics or structural loads) and even higher-level safety objectives, it is adequate for
other aircraft. These interactions are intimately systems which loss or malfunction is not worse than
connected with the Functional Hazard Assessment Minor.
process described in ARP 4761 [2].
In this pattern, protection mechanisms are added
• Consequences to the single actuation channel. One of the protection
mechanisms is the input data validation. The SysML
This item provides the consequences of adopting
Internal Block Diagram, as shown in Figure 4,
the design pattern. Safety consequences may be, of
represents this Design Pattern.
course, the achievement (or not) of certain safety
objectives in terms of availability or integrity. In the Douglass [8] mentions two variants of this
ARP 4761 context, this may be represented by a set pattern: open-loop and closed-loop. In the closed
of Fault Tree Analysis structures specific to that loop variant, a feedback block for the actuation is
design pattern. With the fault trees come more included. The results of this feedback are provided to
assumptions such as additional requirements for crew the algorithm.
procedures or maintenance checks.

Additionally, other failure modes at the system


level may appear as a consequence, which will have
to be analyzed as well. For example, if triple channel
redundancy is used to achieve 1E-9 availability, the
In many cases, it is possible to suppress the
comparator and the switch and leave the task of
channel selection to the users. For example, in case of
altitude miscompare between pilot and copilot
instruments, both pilots compare their information
from their sensors with other data available on the
flight deck to select the source most likely to be
correct. Fly-by-wire or other systems in which the
pilot is not on the loop, on the other hand, may not be
Figure 4. Protected Single-Channel Pattern
able to rely on this strategy.
The design pattern itself does not establish
whether its elements are allocated to hardware or
software, but it is assumed in this case that they are
allocated to a single channel and that no
independence can be claimed between these
elements. Being a single channel pattern, a failure in
this single channel will cause loss of the entire
system.

• Homogeneous Duplex Redundancy Pattern


(HDR)
This design pattern [8], shown in Figure 5,
provides a classical solution to increase availability
against random hardware failures. Armoush [10]
provides a discussion on the safety improvements of
this pattern and the limitations related to the coverage Figure 5. Homogeneous Duplex Redundancy
of the comparator and the lack of tolerance to Pattern
systematic faults which may affect both channels at
the same time. • Heterogeneous Duplex Redundancy
Pattern (HeDR)
In commercial avionics, the homogeneous
redundancy pattern is widely used and even some The Heterogeneous Redundancy pattern [8] is
aviation regulations specify equipment-level very similar to the Homogeneous Redundancy
redundancy to ensure availability of some functions pattern in terms of construction. However, it differs
(for example, two communication radios in overwater from the previous one because channels have
operations – 14CFR 91.511 [12]). dissimilar designs. This dissimilarity may be
achieved by using diverse hardware and/or software
In the ARP 4761 framework, this pattern is implementations in each channel. When applied to
adequate for situations in which a loss of function is software, this pattern is commonly referred to as N-
classified as Major. However, this design pattern Version Programming (NVP). Even greater
does not provide any solution to the integrity robustness is achievable if each channel is based on
problem. If a fail-safe state does not exist (or if an different algorithms or physical phenomena.
inadvertent actuation of any channel is a hazard at the
system level), then the malfunction of the system is This improves robustness against
caused by a malfunction of any channel. This will be implementation errors, but has a significant impact
referred to as HDR-NFS (Homogeneous Duplex on development, maintenance and certification cost,
Redundancy – No Fail-Safe). Otherwise, if a fail-safe as well as on overall system complexity.
state does exist, then the output will be only ARP 4761 and ARP 4754A do not assign
hazardous if both channels malfunction. This will be quantitative probability values for design errors. Yet,
referred to as HDR-FS (Homogeneous Duplex these guidelines require qualitative analyses
Redundancy – Fail-Safe).
(Common Mode Analyses) to evaluate the • M-out-of-N Pattern (MooN)
contribution of software or hardware design errors to
the overall failure condition. In this scenario, the The M-out-of-N Pattern [6] is an extension of
Heterogeneous Duplex Redundancy pattern is useful the Triple Modular Redundancy pattern. This pattern
in showing compliance with safety objectives. implements a voter in which the output will be the
result a voting scheme of the outputs of N>3
One classic example of this pattern in avionics redundant channels, as shown in Figure 7.
applications is the use of a standby indicator that is
not the same design as primary displays.

• Triple Modular Redundancy Pattern


(TMR)
The Triple-Modular Redundancy Pattern [8] is
one extension of the Homogeneous Duplex
Redundancy Pattern for systems with high safety
objectives for both availability and integrity.

Three modules processing the same data operate


in parallel, while the outputs of each channel are
voted in a “winner-takes-it-all” manner. This pattern
is shown in Figure 6.
Figure 7. M-out-of-N Redundancy Pattern

This design pattern has a series of drawbacks for


application in commercial aircraft systems. The first
of them is that if homogeneous redundancy is used,
there is no protection against design flaws and other
common modes. Another is the enormous impact in
recurring cost, weight and power requirements. And
finally, the safety performance of this pattern will be
driven by the voting element.

However, this voting pattern may be combined


Figure 6. Triple-Modular Redundancy Pattern with other safety patterns in situations in which
several sensors are available and the actuation
As in the Homogeneous Duplex Redundancy
channel needs to choose a value.
Pattern, there is no protection for systemic faults or
design flaws in each channel. The Triple Modular • Monitor-Actuator Pattern (MA)
Redundancy Pattern may be further combined with
the Heterogeneous Redundancy pattern to provide a The Monitor-Actuator Pattern [8][10] provides a
three channel solution with dissimilarity, which can solution for the integrity problem and is particularly
be shown to be adequate to meet the highest ARP adequate for situations in which a fail-safe state does
4761 safety objectives (1E-9) for both availability exist. In this pattern, one channel is responsible for
and integrity without being exposed to Common performing the end-to-end actuation, while the
Mode Failures. monitor channel compares the output of the actuator
channel against the expected value and shuts the
actuator off, if a discrepancy is found. This pattern
assumes that loss of the actuation function is a less
critical condition.

In this type of system, the monitor channel


usually contains a reduced version of the actuation
algorithm and is driven by a separate set of sensors. • Recovery Block (RB)
The same set of sensors may be used, but this
The Recovery Block pattern [10] is a software
introduces a common mode failure into the system.
safety design pattern in which the outputs of multiple
This pattern is shown in Figure 8.
versions of the function are submitted to acceptance
tests and if the primary version fails the test, a
secondary (dissimilar) version is executed and
submitted to the acceptance test.

This design pattern has the advantage of


reducing the amount of processing needed, when
compared with NVP. However, it requires a suitable
acceptance test to be developed, which may not
always be possible in safety-critical systems.

A related pattern is the Acceptance Voting


(AV), in which N different versions of the same
requirement are executed in parallel and subject to
the acceptance testing and then voting.

As with other diversity-related patterns (such as


Figure 8. Monitor-Actuator Pattern NVP and HeDR), the benefits of these patterns are
related to the reduction of exposure to common mode
This design pattern is adequate for systems in events such as design errors.
which loss of function is a Minor failure condition,
but erroneous operation has a higher criticality. • 3-Level Safety Monitoring Pattern (3-
LSM)
One example application of this design pattern is
for autopilot systems. Autopilot systems usually have The 3-Level Safety Monitoring Pattern was
low availability requirements (pilots should always originally created in the automotive industry [13] and
be capable of flying aircraft manually), but must be is a combination of the Monitor-Actuator and
protected against malfunctions that may put the Watchdog patterns [9]. As the name implies, this
aircraft in a hazardous condition, such as control pattern consists of three levels implemented in a
surface hardovers or slowovers. single hardware channel: Actuation, Monitoring and
Control. The Actuation and Monitoring levels work
As pointed out by Armoush [10], if a failure in similarly to a Monitor-Actuator pattern, while the
the monitoring channel occurs, no result may be Control level monitors the hardware integrity. An
observed in the system until a second failure occurs external Watchdog ensures proper command
in the actuation channel. This condition is a latent sequencing.
failure and must be avoided through periodic
maintenance checks [8] and/or specific built-in-tests • Safety Executive Pattern (SE)
[10].
The Safety Executive Pattern [8] is a more
The Monitor-Actuator pattern has also some complex pattern to address more complex scenarios
lighter-weight variants, such as the Sanity Check in which a fail-safe state cannot be achieved simply
(SC) and the Watchdog (WD) patterns [8]. These by shutting off the primary actuation channel. In this
variants are less expensive to implement and are pattern, if a failure or malfunction is detected in the
often found as mitigation means for specific failure primary actuation channel, the safety executive takes
modes of hardware components (for example, a control and performs the transition to a safer
Watchdog being used to prevent a microprocessor condition, in which control can be handled to the fail-
freeze). safe processing channel, as shown in Figure 9.
Table 3. Assumptions for quantitative analysis

Event Prob.
Loss (Failure) of an electronic unit 1E-4
Malfunction of an electronic unit 1E-5
Loss of an electrical power bus 1E-5
Loss of an input sensor 1E-4
Malfunction of an input sensor 1E-5
Loss of an output actuator 1E-4
Malfunction of an output actuator 1E-5

Figure 9. Safety Executive Pattern


Conservatively, sensors and actuators were
It is very common in aircraft designs that the included as part of the channels. For simplicity, it
flight crew acts as a safety executive based on was assumed flight duration of 1 hour and that all
monitors implemented in the avionics system. When latent failures are detected by Power-up Built-In-
an abnormal situation is detected (such as a cabin Tests (PBIT) before every flight.
depressurization), the avionics system (acting as a
monitor) alerts the flight crew, which then takes the Application of Design Patterns
appropriate action (for example, descend to a safe
altitude) to avoid a hazardous scenario. As a matter For each of the Design Patterns described above,
of fact, there are examples in the industry of Fault Tree Analyses have been performed
automated systems in which the autopilot performs considering the safety objectives for Loss and
this safety executive function in case of aircraft Malfunction. The results are shown in Table 4.
depressurization without any pilot involvement [14].
Table 4. FTA results for Generic Design Patterns
Assumptions for quantitative analysis Design Pattern Avail. Integr.
During the Preliminary System Safety Protected Single 3.10E-4 3.00E-5
Assessment (PSSA) stage of ARP 4761, it is Channel (PSC)
necessary to define failure rate budgets to system Homogeneous Duplex 9.61E-8 6.00E-5
components, which are then passed to the suppliers of Redundancy – No Fail
each element as requirements. In this work, the Safe state (HDR-NFS)
greatest concern is based on the architecture of Homogeneous Duplex 9.61E-8 9.00E-10
system and the interrelationships between elements, Redundancy – Fail Safe
instead of individual failure rates. The assumption is state (HDR-FS)
that individual modules have similar failure modes
and failure rates and therefore the safety objectives of Triple Modular 2.98E-11 2.70E-9
the system are to be achieved through the Redundancy (TMR)
architectural decisions represented by the design Monitor-Actuator (MA) 3.40E-4 6.00E-9
patterns previously shown. For this analysis, generic Safety Executive (SE) 1.58E-7 3.00E-5
quantitative failure rates have been assumed to
support the Fault Tree Analysis effort, as shown in
Table 3. The Heterogeneous Duplex Redundancy
(HeDR) was not included in the Table as it
quantitatively yields the same results as the HDR.
However, it may be used in situations in which
protection against design errors is needed.
As it can be seen from Table 4, the use of a
Table 6. Design Patterns per Safety Objective
single design pattern is not capable of meeting the
safety objectives for the highest criticality functions, Availability
particularly in duplex redundancy cases without a
fail-safe state. It is necessary to provide combinations CAT HAZ MAJ MIN
of design patterns to successfully address these safety CAT TMR+1MA HDR-FS HDR-FS HDR-FS
requirements. For example, in a dual or triple
TMR+1MA HDR- MA
redundancy system, having one or more channels NFS+2MA
protected by a Monitor-Actuator scheme increases
the integrity and maintains the overall availability. HAZ TMR HDR-FS HDR-FS HDR-FS

Integrity
This combination of patterns is represented in the HDR- HDR- MA
following notation: NFS+2MA NFS+2MA
MAJ TMR HDR-FS HDR-FS HDR-FS
[MainPattern]+[number_of_instances][SubPattern]
HDR- MA MA
For example, a combination of the Triple NFS+2MA
Modular Redundancy pattern in which 2 channels are MIN TMR HDR-NFS HDR-NFS PSC
a Monitor-Actuator pattern is referred to as
SE SE
TMR+2MA. Some relevant combinations have been
calculated and are presented in Table 5.

Table 5. FTA results for Combined Design


Patterns Case Study: Generic IMA-based
System
Design Pattern Avail. Integr.
This section presents the use of Design Patterns
HDR-NFS+1MA 1.05E-7 3.00E-5 for the safety assessment of a generic avionics system
HDR-NFS+2MA 1.16E-7 1.20E-8 based on an IMA platform.
TMR+1MA 3.27E-11 9.00E-10
For this example, the environment of a fixed-
TMR+2MA 3.58E-11 6.36E-12 wing 14CFR Part 25 aircraft was chosen in which the
TMR+3MA 3.93E-11 1.08E-16 safety objectives and methods defined in ARP 4761
[2] apply. Even though this simple generic system
lacks the completeness of a real-world avionics
Table 6 presents a list of recommended patterns installation, it is a convenient means of
for each safety objective. In some cases, more than demonstrating the use of Design Patterns for system
one pattern is adequate for the objective and the safety assessment.
designer is expected to combine the generic design
pattern with the specific needs of the system being
System overview
developed.
The Generic Avionics System is a real-time
distributed computing system that is responsible for
receiving data from the aircraft, processing it and
providing indications and alerts to the flight crew.
The main functionalities of this Generic Avionics
System in this case study are described as follows:

• Provide primary flight indications to flight


crew (attitude, altitude, airspeed, and
heading);
• Provide navigation information to flight
crew (e.g. VOR navigation);
• Provide communication capability to flight Failure Condition Haz.
crew; Class
Four electronic displays are provided for display Loss of all attitude displays, including CAT
of information, as well as an additional standby standby display
indicator. Display of misleading attitude CAT
information on both primary displays
This Generic Avionics System follows the
Integrated Modular Avionics concept and is built Display of misleading attitude HAZ
around a platform composed of generic modules, information on one primary display
which are then populated with application software to Loss of all airspeed displays, including CAT
support the required functions. standby display
Specialized hardware, such as air data Display of misleading airspeed HAZ
computers, angle of attack vanes, inertial sensors, information on both primary displays
radios and data concentrators are connected to the Loss of all barometric altitude CAT
core platform and ensure proper flow of information displays, including standby display
with the outside world. The Block Definitions Display of misleading barometric CAT
Diagram of the Generic Avionics System is shown in altitude information on both primary
Figure 11. displays
Non-restorable loss of display of all CAT
navigation information coupled with a
total loss of communication functions
Loss of display of all navigation MAJ
information
Display of misleading navigation HAZ
information simultaneously to both
pilots
Loss of all communication functions MAJ

Each of the failure conditions presented in Table


6 can be understood as hazard states to be avoided.
Using the safety objectives from Table 1, this
Figure 11. Block Definitions Diagram (BDD) for provides targets for the systems architect to design a
the Generic Avionics System system that meets the overall safety objectives. The
safety objectives of availability and integrity are then
System Functional Hazard Assessment used to select a design pattern. These targets are
detailed in Table 8.
As defined by ARP 4761 [2], a Functional
Hazard Assessment is performed to this generic Table 8. Safety objectives per function
system. For simplicity, a reduced set of failure cases
were analyzed and classifications were driven from Function Avail. Integr. Pattern
existing standards, such as the AC 25-11A [15]. The Attitude CAT CAT TMR+2MA
results of the FHA are shown in Table 7. Airspeed1 HAZ CAT TMR+2MA
Table 7. FHA summary for the generic avionics Altitude1 CAT CAT TMR+2MA
system Navigation2 HDR-
MAJ HAZ
NFS+2MA
Failure Condition Haz.
Communication2 MAJ MIN HDR-FS
Class
Notes:

(1) Airspeed and Altitude indications use the


same sensors, so the actual design is driven by the
higher-criticality parameter; and

(2) The combined objective for Total Loss of


Navigation and Communication will be discussed
later in this paper.

Allocation of functions to modules using design


patterns
The following sections contain examples of how
design patterns were used in this study to allocate
functions to specific modules.

Primary Flight Information (Attitude, Altitude,


Airspeed)
The display of primary flight information to the
flight crew can be decomposed in the same stages
used in the Design Patterns representation for a
Protected Single Channel, as shown in Figure 12. Figure 12. Activity Diagram of the Primary Flight
Sensors measure physical phenomena, which are then indication parameters
processed and validated at a first stage. This data is
then transformed, using information from other In order to achieve the CAT objectives for
sources. An output processing function transforms availability and integrity, the Triple Modular
this information into a graphical format that is sent Redundancy with 2 Monitor-Actuator channels
through an actuator (a display) to the external world. (TMR+2MA) design pattern was chosen. Even
Feedback from the Display can be obtained with an though the TMR+1MA could have been chosen in
Actuation Monitoring activity. In case the display terms of safety objectives, it is convenient – due to
does not present the desired symbols (due to an human factors aspects – to have symmetric
internal malfunction), the channel may be reset processing channels for pilot and copilot.
and/or may declare a failure. As a matter of fact, provided that these
parameters are required to be shown in a specific
arrangement to the flight crew (14CFR 25.1321 [16]),
it makes sense to have a single application set up as
the output processing channel of the PFD (Primary
Flight Display).

Being a triple-redundancy system, three input


sensors were chosen, each one allocated for each
channel (pilot/copilot/standby). A monitor-actuator
pattern was applied in the PFD drawing application,
with an independent monitor (running on a separate
hardware module) checking feedback from the
actuator (which is the display itself). In this example,
it is assumed that all symbology is calculated in the
application within the IMA and sent to the displays
using a standard video bus such as ARINC 661 or
ARINC 818. This architecture is shown in the SysML using guidance from the faulty channel. This drives
Internal Block Diagram in Figure 13. the need of using the HDR-FS+2MA design pattern.
As described in the previous sections, this pattern is a
combination of the homogeneous dual-channel
redundancy with a monitor-actuator scheme in each
channel. In the IMA example presented in this paper,
the Monitor-Actuator pattern can be allocated to two
separate applications running in separate modules. In
order to detect malfunctions of NAV sensors, data
from the cross-side NAV radio is routed through the
IMA databus. This architecture is shown in Figure
14.

Figure 13. Primary Flight Information


architecture

Communication and Navigation


As mentioned above, the highest hazard
identified for this set of functions is the Non-
Restorable Loss of Navigation and Communication,
which is classified as Catastrophic. Being two
different functions, with some degree of
independence from each other, this failure condition
Figure 14. Navigation and Communication
can be addressed by a Heterogeneous Duplex
architecture
Redundancy pattern, in which one channel is
responsible for Communication and the other for
Navigation. In this specific case, it is possible to
assume that a fail-safe state does exist, as a
malfunction in Navigation channel does not affect the Conclusions
Communication channel and vice-versa. In this paper, a brief study on the applicability of
In Table 8, the Communication function was design patterns for the safety assessment of
assigned a HDR-FS pattern. This is sufficient for the commercial avionics systems was presented. It was
Communication safety objectives, provided that a shown that it is possible to combine the safety design
malfunction in a single communication channel (for patterns proposed by Douglass and Armoush with the
example, a radio) is not considered a hazard for the standard safety assessment guidelines used in the
function. The other radio remains operative and can commercial aircraft systems domain. It was also
be used if needed. In order to maintain maximum shown that some safety objectives might require
independence from the Navigation function, the more than one pattern.
Communication was allocated completely outside the
IMA Platform, with radio tuning being performed Suggestions for future work
directly from a tuning panel to the radio.
It is the authors understanding that the
For the Navigation function, on the other hand, a application of safety design patterns in the aerospace
malfunction in a single channel is considered a industry is still at its early stages. The performed
hazard for the function, provided that pilots may be analyses may be enhanced with the addition of new
patterns identified in real-world projects, especially [8] DOUGLASS, B. P. Real-Time Design Patterns:
those based in IMA platforms. Moreover, software- robust scalable architecture for Real-Time systems.
specific patterns were not addressed in this Addison-Wesley, 2003.
quantitative study, but they are relevant in situations
in which sensor redundancy is separately treated from [9] DOUGLASS, B. P. Doing Hard Time: developing
channel redundancy. real-time systems with UML, objects, frameworks
and patterns. Addison-Wesley, 1999.
An additional suggestion for future work is to
apply this process to other types of aircraft systems, [10] ARMOUSH, A. Design Patterns for Safety
including fly-by-wire, engine control, and air Critical Embedded Systems. PhD Thesis. Rheinland-
management systems, for example. Westfalen Technische Hochschule (RWTH), Aachen,
2010.

References [11] KHALIL, M., SCHÄTZ, B, VOSS, S. A


Pattern-based Approach towards Modular Safety
[1] 14CFR 25.1309 - Equipment, systems, and Analysis and Argumentation – European Real-Time
installations. Code of Federal Regulations – Title 14 Systems Conference (ERTS) 2014.
(Aeronautics and Space). Federal Aviation
Administration, 1970. [12] 14CFR 91.511 - Communication and navigation
equipment for overwater operations. Code of Federal
[2] ARP 4761 -Aerospace Recommended Practice - Regulations – Title 14 (Aeronautics and Space).
Guidelines for Safety Assessment of Commercial Federal Aviation Administration, 1989.
Aircraft Systems. Society of Automotive Engineers,
1996. [13] US Patent 5880568: Method and arrangement
for controlling the drive unit of a vehicle, March
[3] RTCA DO-297 – Integrated Modular Avionics 1999.
Development Guidance and Certification
considerations. [14] US Patent 4314341A –Aircraft Automatic Pilot
with Automatic Descent Control Apparatus. Sperry
[4] FAA AC 20-170 – Integrated Modular Avionics. Corporation, 1980.
Federal Aviation Administration, 2010.
[15] AC 25-11A - Advisory Circular: Electronic
[5] ARP 4754A -Aerospace Recommended Practice - Fight Deck Displays. Federal Aviation
Guidelines for Development of Civil Aircraft and Administration, 2007.
Systems. Society of Automotive Engineers, 2010.
[16] 14CFR 25.1321 – Arrangement and visibility.
[6] KELLY, T. P., McDERMID, J. A, Safety Case Code of Federal Regulations – Title 14 (Aeronautics
Construction and Reuse Using Patterns. and Space). Federal Aviation Administration, 1989.
SAFECOMP 1997 - The 16th International
Conference on Computer Safety, Reliability and
Security. Springer, 1997.
33rd Digital Avionics Systems Conference
[7] GAMMA, E. et al. Design Patterns – Elements of
October 6-10, 2014
Reusable Object-Oriented Software. Addison
Wesley, 1998.

View publication stats

You might also like