Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
0% found this document useful (0 votes)
74 views

2015 STECA Tutorial

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
74 views

2015 STECA Tutorial

Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 92

Systems-Theoretic Early

Concept Analysis
(and Development)
Cody H. Fleming

23 March 2015
4th STAMP Workshop
Systems Engineering Research Lab
Motivation
Ability to impact cost and Cost of
1 2
performance design changes
Cost, Effectiveness

80% of Safety
Decisions [Frola
and Miller, 1984]

Concept Requirements Design Build Operate


H

Preliminary System & Accident


Hazard Analysis Sub-system Analysis
Hazard Analysis

©Fleming ‘15 2
General Challenges

• limited design information


• no specification
• informal documentation
• concept of operations ⌘ “ConOps”

Concept Requirements Design Build Operate


H

??? Preliminary System & Accident


Hazard Analysis Sub-system Analysis
Hazard Analysis

©Fleming ‘15 3
Goals

1. use rigorous, systematic tools for identifying hazardous scenarios and


undocumented assumptions

2. supplement existing (early) SE activities such as requirements


definition, architectural and design studies


Especially when tradespace includes: human operation, automation or
decision support tools, and the coordination of decision making agents

©Fleming ‘15 3
Table of Contents

1. Theory

2. STAMP

3. STECA

4. Case Study

Theory STAMP STECA Case Study


©Fleming ‘15
Current State of the Art

Concept Requirements Design Build Operate


H

Preliminary System & Accident


Hazard Analysis Sub-system Analysis
Hazard Analysis

Theory STAMP STECA Case Study


©Fleming ‘15 4
Current State of the Art

Preliminary Hazard Analysis


PROGRAM: DATE:
ENGINEER: PAGE:
ITEM HAZARD CAUSE EFFECTS RAC ASSESS- RECOMM-
COND MENTS ENDATIONS
Assigned List the Describe If allowed to go Hazard Probability, Recommended
number nature of what is uncorrected, Level possibility of actions to
the causing the what will be assign- occurrence: eliminate or
condition stated the effect or ment -Likelihood control the
condition effects of the -Exposure hazard
to exist hazardous -Magnitude
condition
[Vincoli, 2005]

Theory STAMP STECA Case Study


©Fleming ‘15 4
Limitations of PHA
PHA tends to identify the following hazard causes:
Causes Causes
Significance Significance
Causes Sign

atory Equipment Failure DesignANSP


High error, makes
coding Medium
Human error Med
error, insufficient
mistake during
algorithmic or software testing,
manual data load
programming softwareintooperating
GBA when
system problem
implementation strategic change

[JPDO, 2012]

This is true:
ALL accidents are caused by hardware failure, software flaws, or human error
⌥ ⌅
⌃ ⇧
But is the information coming from PHA useful for systems engineering?
Theory STAMP STECA Case Study
©Fleming ‘15 5
Emergence
Organized complexity as a hierarchy of levels, “each more complex than the
one below, a level being characterized by emergent properties which do not
exist at the lower level” [Checkland, 1999]

[Business Korea, 2014]

Theory STAMP STECA Case Study


©Fleming ‘15 6
Hierarchy
Input Level n Output
Subsystem
Intervention
Feedback
Input Level n 1 Output
Subsystem

Feedback

Intervention

Input Level 1 Output


Subsystem

[Mesarovic, 1970]

Theory STAMP STECA Case Study


©Fleming ‘15 7
Process Control
Four conditions are required for process control:
1. Goal condition: the controller must have a goal or goals

2. Action condition: the controller must be able to affect the state of the
system, typically by means of an actuator or actuators

3. Model condition: the controller must contain a model of the system

4. Observability condition: the controller must be able to ascertain the


state of the system, typically by feedback from a sensor

[Ashby, 1957]

Theory STAMP STECA Case Study


©Fleming ‘15 8
Table of Contents

1. Theory

2. STAMP

3. STECA

4. Case Study

Theory STAMP STECA Case Study


©Fleming ‘15
Safety ) Control Problem
Systems-Theoretic Accident Model and Process

• Accidents are more than a chain of events, they


involve complex dynamic processes

STAMP
• Treat accidents as a control problem, not a
failure problem

• Prevent accidents by enforcing constraints on


component behavior and interactions

Theory STAMP STECA Case Study


©Fleming ‘15 9
STAMP
• Controllers use a process model to
Controller
determine control actions
• Accidents often occur when the process Process Model
model is incorrect
• Four types of unsafe control actions: Control Feedback
1. Not providing the control action causes Actions
the hazard
2. Providing the control action causes the
hazard Controlled Process
3. The timing or sequencing of control
actions leads to the hazard
4. The duration of a continuous control
action, i.e., too short or too long, leads to
the hazard.
Better model of both software and human behavior
Explains software errors, human errors, interaction accidents,. . .
Theory STAMP STECA Case Study
©Fleming ‘15 10
STAMP
Controller
Process Model

Control Feedback
Actions

Controlled Process

Theory STAMP STECA Case Study


©Fleming ‘15 11
STAMP
Controller
Process Model

Control Feedback
Actions

Controlled Process

Theory STAMP STECA Case Study


©Fleming ‘15 11
STAMP
Controller
Process Model

Control Feedback
Actions

Controlled Process

Theory STAMP STECA Case Study


©Fleming ‘15 11
STAMP
Controller
Process Model

Control Feedback
Actions

Controlled Process

Theory STAMP STECA Case Study


©Fleming ‘15 11
Unsafe Control Actions
Table B.3: Unsafe Control Actions for ITP Flight Crew
!
Wrong
Stopped Too
Timing/Order
Control Not Providing Providing Soon/Applied
Action Causes Hazard Causes Hazard Causes Hazard Too Long
ITP executed
when not
approved
ITP executed
too soon before
ITP executed
when ITP criteria approval
Execute ITP
are not satisfied
ITP executed
ITP executed with too late
incorrect climb
rate, final altitude,
etc
FC aborts
unnecessarily
FC continues
Abnormal
with maneuver
Termination FC does not
in dangerous
of ITP follow regional
situation
procedures while
aborting

Theory STAMP STECA Case Study


©Fleming
Four inadequate control actions of the ITP flight crew are identified as potentially unsafe in ‘15 12
Control Flaws
Control input or external
information wrong or missing

Controller
Inappropriate, Inadequate Control Process Model
ineffective Algorithm inconsistent,
or missing (Flaws in creation, Process incomplete, Inadequate or
changes, Incorrect or incorrect missing feedback
control modification or adaptation)
action Feedback delays

Actuator Sensor
Inadequate Inadequate
Operation Operation

Delayed Incorrect or no
operation information
provided
Controller Conflicting
Controlled Process Measurement
Component failures inaccuracies
2 control actions
Changes over time Feedback delays
Process input Process output
Unidentified or
missing or wrong contributes to
out-of-range
hazard
disturbance
[Leveson, 2012]

Theory STAMP STECA Case Study


©Fleming ‘15 13
Table of Contents

1. Theory

2. STAMP

3. STECA

4. Case Study

Theory STAMP STECA Case Study


©Fleming ‘15
Approach

Systems-theoretic Early Concept


Analysis—STECA

Theory STAMP STECA Case Study


©Fleming ‘15 14
Approach
Concept Unspecified assumptions

Missing, inconsistent,
incomplete information
Model
Generation
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

Theory STAMP STECA Case Study


©Fleming ‘15 14
Control Elements
ConOps
Unspecified assumptions

Missing, inconsistent,
incomplete information
Model
Generation
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

Theory STAMP STECA Case Study


©Fleming ‘15 15
Control Elements
9. Control input (setpoint) 8. Feedback to higher level
or other commands controller
11. External input 10. Controller output
1. Controller
7. Control 6. Control 5. Process
Action Algorithm Model

2. Actuator 4. Sensor

12. Alternate 3. Controlled


Alt. control actions Process
13. External process 15. Process Output
input 14. Process
Disturbance

Theory STAMP STECA Case Study


©Fleming ‘15 16
Roles in Control Loop
What kinds of things can an “entity” do within a control structure, and more
particularly within a control loop?

Theory STAMP STECA Case Study


©Fleming ‘15 17
Roles in Control Loop
What kinds of things can an “entity” do within a control structure, and more
particularly within a control loop?

Controller
• Enforces safety constraints
• Creates, generates, or modifies control actions based on algorithm or
procedure and perceived model of system
• Processes inputs from sensors to form and update process model
• Processes inputs from external sources to form and update process
model
• Transmits instructions or status to other controllers

Theory STAMP STECA Case Study


©Fleming ‘15 17
Roles in Control Loop
What kinds of things can an “entity” do within a control structure, and more
particularly within a control loop?

Actuator
• Translates controller-generated action into process-specific instruction,
force, heat, etc

Theory STAMP STECA Case Study


©Fleming ‘15 18
Roles in Control Loop
What kinds of things can an “entity” do within a control structure, and more
particularly within a control loop?

Controlled Process
• Interacts with environment via forces, heat transfer, chemical reactions,
etc
• Translates higher level control actions into control actions directed at
lower level processes

Theory STAMP STECA Case Study


©Fleming ‘15 19
Roles in Control Loop
What kinds of things can an “entity” do within a control structure, and more
particularly within a control loop?

Sensor
• Transmits continuous dynamic state measurements to controller (i.e.
measures the behavior of controlled process via continuous or
semi-continuous [digital] data)
• Transmits binary or discretized state data to controller (i.e. measures
behavior of process relative to thresholds; has algorithm built-in but no
cntl authority)
• Sythesizes and integrates measurement data

Theory STAMP STECA Case Study


©Fleming ‘15 20
Individual Control Loop
9. Control input (setpoint) 8. Feedback to higher level
or other commands controller
11. External input 10. Controller output
1. Controller
7. Control 6. Control 5. Process
Action Algorithm Model

2. Actuator 4. Sensor

12. Alternate 3. Controlled


Alt. control actions Process
13. External process 15. Process Output
input 14. Process
Disturbance

Theory STAMP STECA Case Study


©Fleming ‘15 21
Control Structure

Input Output
Controller n
Control Action
Feedback
Input Output
Controller n 1

Control Action Feedback

Input Output
Controller 1

Theory STAMP STECA Case Study


©Fleming ‘15 22
Analysis
ConOps
Unspecified assumptions

Missing, inconsistent,
incomplete information
Model Gen-
eration
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

Theory STAMP STECA Case Study


©Fleming ‘15 23
Analysis

“Completeness”

“Analyzing Safety-
related Responsibilities”

“Coordination
& Consistency”

Theory STAMP STECA Case Study


©Fleming ‘15 23
Early Systems Engineering
ConOps
Unspecified assumptions

Missing, inconsistent,
incomplete information
Model Gen-
eration
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

Theory STAMP STECA Case Study


©Fleming ‘15 24
the control loop can achieve the four necessary conditions2 of process control and ade-

Early Systems Engineering quately interact with its environment, other processes, and other controllers. In other
words, these guide words are necessary to ensure that a control loop is controllable
and coordinable with other controlled processes.

Constraints 9. Control input


(setpoint) or other
8. Feedback to higher
level controller
commands
on control
11. External 10. Controller
input output
1. Controller
7. Control 6. Control 5. Process
loop behavior Action Algorithm Model

2. 4.
Actuator Sensor

Controller 12. Alternate 3. Controlled


2 control actions Process
13. External 15. Process

Model-Based
process input 14. Process output
disturbance

Analysis Figure 11: Control Loop with generic entities

The information in Figure 11 and the above lists (Controller, Actuator, Controlled
Process, Sensor) can then be used to systematically parse and query the natural lan-
guage description or Input Level n in a Output
graphical depiction concept of operations. The resulting
Subsystem
model and subsequent database are easy to interrogate and visualize. These quali-
ties help the analyst to check for internal inconsistencies and/or missing information
Constraints Feedback
that may result in unsatisfied control conditions, and also to check for inconsistencies
Input
across the system hierarchy. Level n 1 Output
Subsystem
Table 6 provides a series of prompts that an analyst can use when reading a text or
graphic in a ConOps.
In order to obtain a “complete” modelFeedback
of the ConOps, this model development
Change the approach should be applied recursively over the entire ConOps document. The key-
Constraints
words, with associated questions and comments (Tables 6 and 7), can be applied to
control 2 See page 52.
Input Level 1 Output

structure Subsystem
57

Figure 8: Basic Features of a Hierarchical System (adapted from [Mesarovic et al.,


1970])
Theory STAMP STECA Case Study
the model itself. The process is conducted according to Figure 9, where the main con-
©Fleming ‘15 24
Table of Contents

1. Theory

2. STAMP

3. STECA

4. Case Study

Theory STAMP STECA Case Study


©Fleming ‘15
Application—TBO
ConOps Unspecified assumptions

Missing, inconsistent,
incomplete information
Model Gen-
eration
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

Theory STAMP STECA Case Study


©Fleming ‘15 25
Application—TBO
Trajectory-Based Operations (TBO)
Operational Scenarios
1
2
3
4
5
6
7
8 Trajectory-Based Operations (TBO)
9 Operational Scenarios for NextGen
10 Prepared by the
11 Joint Planning and Development Office (JPDO)
12 TBO Study Team
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30 December 4, 2011
31
32

Joint Planning and Development Office


1

Theory STAMP STECA Case Study


©Fleming ‘15 25
Application—TBO Trajectory-Based Operations (TBO)
Study Team Report

[JPDO, 2011] Figure 1. Position Uncertainty

As the aircraft approaches level-off and cruise, the shape of the protected airspace morphs into more of
Theory an ellipticalSTAMP
3-D shape, where the aircraft is STECA
positioned in the narrow end of the elliptical
Case Study shape, with
the wake vortex “tail” as its aft bound and vertical, lateral, and longitudinal uncertainty defining ©Fleming
flexible airspace. No two elliptical shapes can overlap if separation is to be assured. In this case,
the ‘15 25
Application—TBO Trajectory-Based Operations (TBO)
Study Team Report

Trajectory-Based Operations (TBO)


Study Team Report

Figure 2. En Route Uncertainties Defining Conformance Boundaries

On arrival, the shape of uncertainty projects downward, based on the descent profile. RNP controls
lateral
[JPDO, 2011] displacement, and time isFigure projected forward
1. Position to points in space for metering, merging, or
Uncertainty
initiating the approach as needed for separation, sequencing, merging, and spacing. As the aircraft
movesAs closer
the aircraft approaches
to the airportlevel-off and cruise,
and landing, the the shape of theofprotected
uncertainty verticalairspace
profilemorphs into more
decreases and of
the aircraft is
Theory now an elliptical 3-D shape,
in STAMP of a where the aircraft is STECA
positioned in the narrow end oflaterally
the elliptical
Case by shape,
Study RNP with
flying
the altitude
more
restrictions
flexible airspace.
tube-shaped
forelliptical
No two the arrival.
bounded uncertainty, defined
shapes can overlap if separation is to be assured. In this case,
and vertically by
the wake vortex “tail” as its aft bound and vertical, lateral, and longitudinal uncertainty defining ©Fleming
the ‘15 25
System-Level Hazards
[H-1] Aircraft violate minimum separation (LOS or loss of separation, NMAC
or Near midair collision)
[H-2] Aircraft enters uncontrolled state
[H-3] Aircraft performs controlled maneuver into ground (CFIT, controlled
flight into terrain)

[SC-1] Aircraft must remain at least TBD nautical miles apart en route* "[H-1]
[SC-2] Aircraft position, velocity must remain within airframe manufacturer
defined flight envelope "[H-2]
[SC-3] Aircraft must maintain positive clearance with all terrain (This
constraint does not include runways and taxiways) "[H-3]

Theory STAMP STECA Case Study


©Fleming ‘15 26
Identify Control Concepts
ConOps
Unspecified assumptions

Missing, inconsistent,
Model incomplete information

Generation
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

Theory STAMP STECA Case Study


©Fleming ‘15 27
Identify Control Concepts
TBO conformance is monitored both in the aircraft and on the ground
against the agreed-upon 4DT. In the air, this monitoring (and alerting)
includes lateral deviations based on RNP..., longitudinal ..., vertical...,
and time from the FMS or other “time to go” aids. [JPDO, 2011]

Theory STAMP STECA Case Study


©Fleming ‘15 27
Identify Control Concepts
TBO conformance is monitored both in the aircraft and on the ground
against the agreed-upon 4DT. In the air, this monitoring (and alerting)
includes lateral deviations based on RNP..., longitudinal ..., vertical...,
and time from the FMS or other “time to go” aids. [JPDO, 2011]
Subject
Role
Behavior
Type

Context

Theory STAMP STECA Case Study


©Fleming ‘15 27
Identify Control Concepts
TBO conformance is monitored both in the aircraft and on the ground
against the agreed-upon 4DT. In the air, this monitoring (and alerting)
includes lateral deviations based on RNP..., longitudinal ..., vertical...,
and time from the FMS or other “time to go” aids. [JPDO, 2011]
Subject Conformance monitoring, Air automation
Role Sensor
Behavior Transmits binary or discretized state data to controller
Type (i.e. measures behavior of process relative to thresholds;
has algorithm built-in but no cntl authority)
Sythesizes and integrates measurement data
Context This is a decision support tool that contains algorithms
to synthesize information and provide alerting based on
some criteria.

Theory STAMP STECA Case Study


©Fleming ‘15 27
Identify Control Concepts
TBO conformance is monitored both in the aircraft and on the ground
against the agreed-upon 4DT. In the air, this monitoring (and alerting)
includes lateral deviations based on RNP..., longitudinal ..., vertical...,
and time from the FMS or other “time to go” aids. [JPDO, 2011]

(1.,5.) (4.)
1. Controller
- Piloting Function
5. Process Model
(3.) (xa , ya , ha , ta ,...)
4. Sensor -
Altimeter,
2. FMS, aircraft
conformance
monitor
3. Controlled Process
Alt.
-Aircraft

Theory STAMP STECA Case Study


©Fleming ‘15 28
Identify Control Concepts
TBO conformance is monitored both in the aircraft and on the ground
against the agreed-upon 4DT. In the air, this monitoring (and alerting)
includes lateral deviations based on RNP..., longitudinal ..., vertical...,
and time from the FMS or other “time to go” aids. [JPDO, 2011]
1. Controller Piloting function
2. Actuator
3 Cntl’d Process Aircraft
4. Sensor Altimeter, FMS, Aircraft conformance monitor
5. Process Model Intended latitude, longitude, altitude, time; Actual latitude,
longitude, altitude, time
6. Cntl Algorithm
7. Control Actions
8. Controller Status
9. Control Input
10. Controller Output
11. External Input
12. Alt Controller
13. Process Input
14. Proc Disturbance
15. Process Output

Theory STAMP STECA Case Study


©Fleming ‘15 28
Ground
Independent of the aircraft, the ANSP uses ADS-B position reporting
for lateral and longitudinal progress, altitude reporting for vertical, and
tools that measure the time progression for the flight track. Data link
provides aircraft intent information. Combined, this position and timing
information is then compared to a performance requirement for the
airspace and the operation. ...precision needed...will vary based on the
density of traffic and the nature of the operation. [JPDO, 2011]

Theory STAMP STECA Case Study


©Fleming ‘15 29
Ground
Independent of the aircraft, the ANSP uses ADS-B position reporting
for lateral and longitudinal progress, altitude reporting for vertical, and
tools that measure the time progression for the flight track. Data link
provides aircraft intent information. Combined, this position and timing
information is then compared to a performance requirement for the
airspace and the operation. ...precision needed...will vary based on the
density of traffic and the nature of the operation. [JPDO, 2011]
Subject
Role
Behavior
Type

Context

Theory STAMP STECA Case Study


©Fleming ‘15 29
Ground
Independent of the aircraft, the ANSP uses ADS-B position reporting
for lateral and longitudinal progress, altitude reporting for vertical, and
tools that measure the time progression for the flight track. Data link
provides aircraft intent information. Combined, this position and timing
information is then compared to a performance requirement for the
airspace and the operation. ...precision needed...will vary based on the
density of traffic and the nature of the operation. [JPDO, 2011]
Subject Conformance monitoring, Ground automation
Role Sensor
Behavior Transmits binary or discretized state data to controller
Type (i.e. measures behavior of process relative to thresholds;
has algorithm built-in but no cntl authority)
Sythesizes and integrates measurement data
Context This is a decision support tool that contains algorithms
to synthesize information and provide alerting based on
some criteria.

Theory STAMP STECA Case Study


©Fleming ‘15 29
Ground
Independent of the aircraft, the ANSP uses ADS-B position reporting
for lateral and longitudinal progress, altitude reporting for vertical, and
tools that measure the time progression for the flight track. Data link
provides aircraft intent information. Combined, this position and timing
information is then compared to a performance requirement for the
airspace and the operation. ...precision needed...will vary based on the
density of traffic and the nature of the operation. [JPDO, 2011]

(11.) (1.,5.)
(4.)
11. Datalink 1. Controller
- ANSP/Ground
(3.) 5. Process Model
(xa , ya , ha , ta ,...,⇢,⌧ )
4. Sensor -
ADS-B, Alt Rep,
2. time, grd
conformance
monitor
3. Controlled Process
Alt. -Piloting Function &
Aircraft

Theory STAMP STECA Case Study


©Fleming ‘15 30
Conf Monitoring Control Loops

“Ground”
GROUND (ANSP /
ATC) TBO Strategic
CAG PMG
Evalutation

TBO Automation
Alert parameter (G)

Data Conformance Data Altitude


Voice
Link Monitor [Gnd] Link Report

Clearancei {4DT}i
{4DT}i (Intent) {h}i
{x,y,h,t}i

AIRSPACE

GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 31
Conf Monitoring Control Loops

“Ground” “Air”
GROUND (ANSP /
ATC) TBO Strategic
CAG PMG
Evalutation AIR (Flight Crew)

TBO Automation CAA PMA


Alert parameter (G)
Alert parameter (A)
4DT
Data Conformance Data Altitude
Voice
Link Monitor [Gnd] Link Report Conformance
Manual FMS CDTI
Monitor [Air]
Clearancei {4DT}i
{4DT}i (Intent) {h}i
{x,y,h,t}i
Aircraft
{x,y,h,t}
ADS-B {x,y,h,t}all
AIRSPACE

GNSS GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 31
Hierarchical Control Structure
114 PROCEEDINGS OF THE IEEE, JANUARY 1970

A
How to Establish Hierarchy?
• Higher level of systems:
. Decision Making Priority
. Decision Complexity, "
. Time Scale between

decisions, "
Fig. 5. . Dynamics
Multilayer
of controlled
hierarchy of decision-making complexity.

system, #
I
I ORGANIZATION I
I
I I
+ PROCESS 4
I I
I ILEARNING STRATEGY1 I
I * II
I LEARNING
Fig. 7. Multilevel, organizational (multiechelon) hierarchy.
AND
I
ADAPTATION I
I I
I and, in general terms, to reduce the uncertainties. Finally,
on thefirst layer, the selection (search, implementation) layer,

’1
OPTIMIZATION the task is to determine the control to be actually applied
Theory STAMP STECA Caseof Study
I
I
SELECTION
[CONiROLl
to theprocess on thebasis
tion provided from other layers.
the instructions and informa-
©Fleming ‘15 32
Hierarchical Control Structure
Function Safety-Related Responsibilities
Route • Provide conflict-free clearances & trajectories
Planning* • Merge, sequence, space the flow of aircraft

• Navigate the aircraft


• Provide aircraft state information to rte planner
Piloting*
• Avoid conflicts with other aircraft, terrain, weather
• Ensure that trajectory is within aircraft flight envelope

• Provide lift
Aircraft • Provide propulsion (thrust)
• Orient and maintain control surfaces

Environment

Theory STAMP STECA Case Study


©Fleming ‘15 33
Hierarchical Control Structure
Function Route, Trajectory
Management
GROUND (ANSP /
ATC)
Function
Route CAG PMG

Planning* Alert parameter (G)

Data Conformance Altitude


Link Monitor [Gnd] Report

Piloting* {4DT}
(Intent)
Piloting AIR (Flight Crew)
Function
CAA PMA

Alert parameter (A)


FMS; Conformance
CDTI
Aircraft Manual Monitor [Air]

Aircraft
{x,y,h,t} {h}
ADS-B
{x,y,h,t}

Environment
GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 33
Hierarchical Control Structure
Function Route, Trajectory
Management
GROUND (ANSP /
ATC)
Function
Route CAG PMG

Planning* Alert parameter (G)

4DT; Data Conformance Altitude


Clearance Link Monitor [Gnd] Report

Piloting* {4DT}
(Intent)
Piloting AIR (Flight Crew)
Function
CAA PMA

Alert parameter (A)


FMS; Conformance
CDTI
Aircraft Manual Monitor [Air]

Aircraft
{x,y,h,t} {h}
ADS-B
{x,y,h,t}

Environment
GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 33
ConOps
Unspecified assumptions

Missing, inconsistent,
incomplete information
Model Gen-
eration
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

Theory STAMP STECA Case Study


©Fleming ‘15 34
Analysis
1. Are the control loops complete? “Completeness”
2. Are the system-level safety
responsibilities accounted for?
“Analyzing Safety-
3. Do control agent responsibilities
related
conflict with safety responsibilities?
Responsibilities”
4. Do multiple control agents have the
same safety responsibility(ies)?
5. Do multiple control agents have or
require process model(s) of the same “Coordination &
process(es)? Consistency”
6. Is a control agent responsible for
multiple processes? If so, how are
the process dynamics (de)coupled?

Theory STAMP STECA Case Study


©Fleming ‘15 34
Safety-Related Responsibilities

2. Are the system-level safety responsibilities accounted for?

3. Do control agent responsibilities conflict with safety responsibilities?

Theory STAMP STECA Case Study


©Fleming ‘15 35
Safety-Related Responsibilities

• Gaps in Responsibility (2)


• Conflicts in Responsibility (3)

(8 i 2 ⌃) (9c 2 C ) [P (c, i )] , (2)

(8Hi 2 H) (¬9c 2 C ) [P (c, Hi ) ^ P (c, G)] (3)

Theory STAMP STECA Case Study


©Fleming ‘15 35
Safety-Related Responsibilities

Potential conflict between goal condition, safety responsibilities???

[JPDO, 2011]
“The pilot must also work to close the trajectory. Pilots will
need to update waypoints leading to a closed trajectory in the
FMS, and work to follow the timing constraints by flying speed
controls.”

Theory STAMP STECA Case Study


©Fleming ‘15 36
Safety-Related Responsibilities

Theory STAMP STECA Case Study


©Fleming ‘15 37
Safety-Related Responsibilities

Theory STAMP STECA Case Study


©Fleming ‘15 37
Coordination & Consistency

4. Do multiple control agents have the same safety responsibility(ies)?

5. Do multiple control agents have or require process model(s) of the


same process(es)?

6. Is a control agent responsible for multiple processes? If so, how are the
process dynamics (de)coupled?

Theory STAMP STECA Case Study


©Fleming ‘15 38
Coordination & Consistency

• Coordination Principle (4)


• Consistency Principle (5)

(8c 2 Ci ) (8d 2 Cj ) 9 (P (c, d) _ P (d, c)) [A (c, Vp ) ^ A (d, Vp )] , (4)

( 8v 2 V, 8c 2 Ci , 8d 2 Cj | A (c, v ) ^ A (d, v ))
[⇢i (a, v ) ⌘ ⇢j (a, v ) ^ Gi ⌘ Gj ] (5)

Theory STAMP STECA Case Study


©Fleming ‘15 38
Coordination & Consistency
Route, Trajectory
GROUND (ANSP /
Management ATC)
Function
CAG PMG

Alert parameter (G)

4DT; Data Conformance Altitude


Clearance Link Monitor [Gnd] Report

{4DT}
(Intent)
Piloting AIR (Flight Crew)
Function
CAA PMA

Alert parameter (A)


FMS; Conformance
CDTI
Manual Monitor [Air]

Aircraft
{x,y,h,t} {h}
ADS-B
{x,y,h,t}

GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 39
Coordination & Consistency

Bcm := Lcm ⇥ Dcm ! Icm , (6)

• Lcm is a model of the airspace state and


• Dcm is the decision criteria regarding conformance.

Theory STAMP STECA Case Study


©Fleming ‘15 40
Coordination & Consistency

Lcm := {zint , zact , ⇢, T , Pr , W , Ecm , FD } (7)

zint := {G , C , t}int
zact := {G , C , t}act
⇢ := Traffic density
⌧ := Operation type
Pr := {RNP, RTP}
W := Wake turbulence model
Ecm := Elliptical conformance model
FD := {F , zint }

Dcm = { zact | zact 2


/ z̄ (zint , Ecm , acm )} , (8)
Theory STAMP STECA Case Study
©Fleming ‘15 41
Coordination & Consistency
Route, Trajectory
GROUND (ANSP /
Management ATC)
Function
CAG PMG

Alert parameter (G)

4DT; Data Conformance Altitude


Clearance Link Monitor [Gnd] Report

{4DT}
(Intent)
Piloting AIR (Flight Crew)
Function
CAA PMA

Alert parameter (A)


FMS; Conformance
CDTI
Manual Monitor [Air]

Aircraft
{x,y,h,t} {h}
ADS-B
{x,y,h,t}

GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 42
Coordination & Consistency
Route, Trajectory
GROUND (ANSP /
Management ATC)
Function
CAG PMG

Alert parameter (G)

4DT; Data Conformance Altitude


Clearance Link Monitor [Gnd] Report

{4DT}
(Intent)
Piloting AIR (Flight Crew)
Function
CAA PMA

Alert parameter (A)


FMS; Conformance
CDTI
Manual Monitor [Air]

Aircraft
Independent {x,y,h,t} {h}
ADS-B
“alert {x,y,h,t}
parameter”

GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 42
Coordination & Consistency
Route, Trajectory
GROUND (ANSP /
Management ATC)
Function
CAG PMG

Alert parameter (G)

4DT; Data Conformance Altitude


Clearance Link Monitor [Gnd] Report

{4DT}
(Intent)
Piloting AIR (Flight Crew)
Function
CAA PMA Independent
conformance
Alert parameter (A)
FMS; Conformance
CDTI
monitors
Manual Monitor [Air]

Aircraft
Independent {x,y,h,t} {h}
ADS-B
“alert {x,y,h,t}
parameter”

GNSS

Theory STAMP STECA Case Study


©Fleming ‘15 42
References
Ashby, W. R. (1957). An Introduction to Cybernetics. Chapman & Hall Ltd.
Business Korea (2014). Auto parts manufacturers concerned over new ordinary wage standards.
Checkland, P. (1999). Systems thinking, systems practice: includes a 30-year retrospective. John Wiley & Sons, Inc.
Frola, F. and Miller, C. (1984). System safety in aircraft management. Logistics Management Institute, Washington
DC.
JPDO (2011). JPDO Trajectory-Based Operations (TBO) study team report. Technical report, Joint Planning and
Development Office.
JPDO (2012). Capability safety assessment of trajectory based operations v1.1. Technical report, Joint Planning and
Development Office Capability Safety Assessment Team.
Leveson, N. G. (2012). Engineering a Safer World. MIT Press.
Mesarovic, M. D. (1970). Multilevel systems and concepts in process control. Proceedings of the IEEE,
58(1):111–125.
Strafaci, A. (2008). What does BIM mean for civil engineers? CE News, Tranportation.
Vincoli, J. W. (2005). Basic Guide to System Safety, Second Edition. John Wiley & Sons, Inc., Hoboken, NJ, USA.

References Early SE
©Fleming ‘15 43
Table of Contents

5. Early SE

References Early SE
©Fleming ‘15
Application of Results

Concept Requirements Design Build Operate


H

Preliminary System & Accident


Hazard Analysis Sub-system Analysis
Hazard Analysis

References Early SE
©Fleming ‘15 44
Application of Results

What does an engineer need to


develop the system??

Concept Requirements Design Build Operate


H

Preliminary System & Accident


Hazard Analysis Sub-system Analysis
Hazard Analysis

References Early SE
©Fleming ‘15 44
Application of Results
ConOps
Unspecified assumptions

Missing, inconsistent,
incomplete information
Model Gen-
eration
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

References Early SE
©Fleming ‘15 44
Deriving Requirements
Scenario 2:
ANSP issues command that results in aircraft closing (or maintaining) a
4DT, but that 4DT has a conflict.

Causal Factors:
• This scenario arises because the ANSP has been assigned the
responsibility to assure that aircraft conform to 4D trajectories as well
as to prevent loss of separation.
. A conflict in these responsibilities occurs when any 4D trajectory has a
loss of separation (LOS could be with another aircraft that is
conforming or is non-conforming). [Goal Condition]

References Early SE
©Fleming ‘15 45
Deriving Requirements
Scenario 2:
ANSP issues command that results in aircraft closing (or maintaining) a
4DT, but that 4DT has a conflict.

Causal Factors:
• Additional hazards occur when the 4DT encounters inclement weather,
exceeds aircraft flight envelope, or aircraft has emergency
• ANSP and crew have inconsistent perception of conformance due to
independent monitor, different alert parameter setting
• ...

References Early SE
©Fleming ‘15 45
Deriving Requirements
Scenario 2:
ANSP issues command that results in aircraft closing (or maintaining) a
4DT, but that 4DT has a conflict.

Requirements:
S2.1 Loss of separation takes precedence over conformance in all TBO
procedures, algorithms, and human interfaces [Goal Condition]
...
S2.3 Loss of separation alert should be displayed more prominently when
conformance alert and loss of separation alert occur simultaneously.
[Observability Condition] This requirement could be implemented in the
form of aural, visual, or other format(s).
S2.4 Flight crew must inform air traffic controller of intent to deviate from
⌥ ⌅
4DT and provide rationale [Model Condition] ...

⌃ ⇧
Human factors-related requirements

References Early SE
©Fleming ‘15 46
Deriving Requirements
Scenario 2:
ANSP issues command that results in aircraft closing (or maintaining) a
4DT, but that 4DT has a conflict.

Requirements:
S2.8 4D Trajectories must remain conflict-free, to the extent possible
...

S2.10 Conformance volume must be updated within TBD seconds of change


in separation minima
S2.11 Conformance monitoring software must be provided with separation
minima information
⌥ ⌅
⌃ ⇧
Software-related requirements

References Early SE
©Fleming ‘15 46
Deriving Requirements
Scenario 2:
ANSP issues command that results in aircraft closing (or maintaining) a
4DT, but that 4DT has a conflict.

Requirements:
S2.14 ANSP must be provided information to monitor the aircraft progress
relative to its own “Close Conformance” change of clearance
...
S3.2 ANSP must be able to generate aircraft velocity changes that close the
trajectory within TBD minutes (or TBD nmi).
Rationale: TBO ConOps is unclear about how ANSP will help the aircraft work to
close trajectory. Refined requirements will deal with providing the ANSP feedback
about the extent to which the aircraft does not conform, the direction and time,

⌥ ⌅
which can be used to calculate necessary changes.

⌃ ⇧
Component Interaction Constraints

References Early SE
©Fleming ‘15 46
Architecture Studies
ConOps
Unspecified assumptions

Missing, inconsistent,
incomplete information
Model Gen-
eration
Vulnerabilties,
risks, tradeoffs

Model-based System, software,


Analysis human requirements

Architectural and
design analysis

References Early SE
©Fleming ‘15 47
have higher performance requirements. An aircraft may be connected to network-centric operations
Architecture Studies
over multiple data links, but there will be a specified, performance-driven path for the critical
communication of 4DT information. Figure 4 is a depiction of notional communication flows.

Negotiation

[JPDO, 2011]
Figure 4. TBO Information Flows
References Early SE
©Fleming ‘15 47
TBO Negotiation
ANSP
CAA PMA

KA
F LA
F KA
F LA
F KA
F LA
F
KA
O LA
O KA
O LA
O

FOCi KA A
F LF
FOCj Flight Deck1 Flight Deckm
LA
F
CAO PMO CAO PMO KA
F CAF PMF CAF PMF
KA A
F LF
KO
F LO KA
LO
F LA
F F
KO KA
F LA
F
LO
F
F F KO
F
LO
F
KO LO KO
F LO
F KO
F
F F

Aircrafti1 Aircrafti2 Aircraftik Aircraftj1 Aircraftj2 Aircraftjl

References Early SE
©Fleming ‘15 48
Modified Structure
ANSP
CAA PMA
KA
O KA
F

LA
O LA
F
KA
O
LA
O KA
F LA
F

FOCi FOCj Flight Deck1 Flight Deckm


CAO PMO CAO PMO CAF PMF CAF PMF

KO
F

LO
F KO
F LO
F KO LO
F F
KO LO
F F KO
F LO
F KO
F LO
F

Aircrafti1 Aircrafti2 Aircraftik Aircraftj1 Aircraftj2 Aircraftjl

References Early SE
©Fleming ‘15 49
Modified Structure
ANSP
CAA PMA
KA
O KA
F

LA
O LA
F
KA
O
LA
O KA
F LA
F

FOCi FOCj Flight Deck1 Flight Deckm


CAO PMO CAO PMO CAF PMF CAF PMF

KO
F

LO
F KO
F LO
F KO LO
F F
KO LO
F F KO
F LO
F KO
F LO
F

Aircrafti1 Aircrafti2 Aircraftik Aircraftj1 Aircraftj2 Aircraftjl



Additional Requirement: KFA and KFO shall not
occur simultaneously.
References Early SE
©Fleming ‘15 49
Modified Structure
ANSP
FOCi FOCj
CAA PMA
CAO PMO CAO PMO

IFO IFO
IFO

KA
F LA
F KA
F KA
F LA
F KA
F LA
F KA
F LA
F
LA
F
Flight Deck1 Flight Deck2 Flight Deck3 Flight Deck4 Flight Deckm
CAF PMF CAF PMF CAF PMF CAF PMF CAF PMF

References Early SE
©Fleming ‘15 50
Modified Structure
ANSP
FOCi FOCj
CAA PMA
CAO PMO CAO PMO

IFO IFO
IFO

KA
F LA
F KA
F KA
F LA
F KA
F LA
F KA
F LA
F
LA
F
Flight Deck1 Flight Deck2 Flight Deck3 Flight Deck4 Flight Deckm
CAF PMF CAF PMF CAF PMF CAF PMF CAF PMF


Additional Requirement: This becomes the active control
structure within TBD minutes of gate departure.

References Early SE
©Fleming ‘15 50
Evaluation

Systems Engineering Phases

Concept Requirements Design Build Operate


H

Preliminary System & Accident


Hazard Analysis Sub-system Analysis
Hazard Analysis

Safety Activities

References Early SE
©Fleming ‘15 51
Evaluation

Systems Engineering Phases

Concept Requirements Design Build Operate


H

Preliminary System & Accident


Hazard Analysis Sub-system Analysis
“STECA” “PHA” Hazard Analysis

Safety Activities

References Early SE
©Fleming ‘15 51

You might also like