<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Archiving and Interchange DTD v1.0 20120330//EN" "JATS-archivearticle1.dtd">
<article xmlns:xlink="http://www.w3.org/1999/xlink">
  <front>
    <journal-meta />
    <article-meta>
      <title-group>
        <article-title>Concurrent System Engineering in Air Traffic Management: Steering the SESAR Program</article-title>
      </title-group>
      <contrib-group>
        <contrib contrib-type="author">
          <string-name>Alfredo Gomez</string-name>
          <email>alfredo.gomez@sesarju.eu</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Benoit Fonck</string-name>
          <email>benoit.fonck@sesarju.eu</email>
          <xref ref-type="aff" rid="aff1">1</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>André Ayoun</string-name>
          <email>andre.ayoun@cassidian.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <contrib contrib-type="author">
          <string-name>Gianni Inzerillo</string-name>
          <email>gianni.inzerillo@cassidian.com</email>
          <xref ref-type="aff" rid="aff0">0</xref>
        </contrib>
        <aff id="aff0">
          <label>0</label>
          <institution>EADS SESAR Industrial Support</institution>
        </aff>
        <aff id="aff1">
          <label>1</label>
          <institution>SESAR Joint Undertaking</institution>
          ,
          <country country="US">USA</country>
        </aff>
      </contrib-group>
      <pub-date>
        <year>2013</year>
      </pub-date>
      <fpage>25</fpage>
      <lpage>32</lpage>
      <abstract>
        <p>As a “System of Systems” (SoS), Air Traffic Management (ATM) in Europe will be improved by simultaneous and coordinated evolutions of its constituting systems. The SESAR Program aims at reaching an ambitious performance target (for 2020) by developing a large collection of “Operational Improvement Steps” (OIs). This development is achieved by more than 300 projects, themselves involving a number of partners working at their own site throughout Europe. To face this challenge, the SJU supported by EADS through an “industrial support” contract, has organized the management of the contributing projects on some basic principles: -­‐ The SESAR Program is Performance-driven: this principle gives priority to developments that demonstrate significant performance gains within Key Performance Areas (KPA)1. -­‐ The programs monitors the maturity progress of the constituting OIs on a maturity scale (V1, V2, V3 maturity levels introduced by the European Operational Concept Validation Methodology) and revisits their priority in accordance with their maturity status. -­‐ The achievement of each maturity level corresponds to a phase, and the transition from a maturity level to the next is assessed on the basis of maturity criteria. -­‐ Each maturity criterion shall be demonstrated though evidences, relying on validation results. -­‐ Maturity criteria reflect the confidence that the Requirements attached to OIs will be met. In particular, the confidence in meeting the performance 1 The Key Performance Areas are: Safety ; Security ; Capacity ; Cost effectiveness; Efficiency ; Environmental sustainability ; Flexibility ; Interoperability ; Participation ; Predictability; Access and Equity.</p>
      </abstract>
    </article-meta>
  </front>
  <body>
    <sec id="sec-1">
      <title>-</title>
      <p>targets (considered as a particular category of requirements) is a key
maturity criterion: therefore, the accuracy of the performance results (based on
platform measurements) supports the estimation of the confidence that the
performance target will be met. So, the maturity progress includes
derisking the level of performance.
-­‐ For each OIs, a validation strategy is defined to ensure that the proper
validation activities are planned by the relevant projects and aligned with
programme priorities.</p>
      <p>The SESAR Research and Development methodology therefore implements a
progressive de-risking / Validation approach, considering the performance gains and
confidence to support the maturity assessment. This approach permits to efficiently
drive the program on Performance, by re-allocating, when necessary, the resources to
the most significantly promising performance gains.</p>
      <p>To give an example, let us consider two key performance areas: safety
(characterized by a number of near-collisions or runway incursions) and capacity
(characterized for example by a number of flights in airspace volume or runway movements
per hour). Some performance figures, exploring several operational scenarios can be
early obtained by fast time simulations and Monte-Carlo analysis. Initial performance
results may be sufficient to support trade-offs between performance features, and to
feed cost-benefit analysis supporting a decision to proceed or not (or rather to
increase/ decrease the priority). Conversely, real flights with representative equipment
in all the systems that contribute to the considered OIs may be costly and not suited
to explore the solution performance in all relevant scenarios (e.g. nominal and
offnominal situations). So, exercises with real flights in representative operational
environment will be mostly suited to assess maturity areas remaining to be validated
(such as human factors).</p>
    </sec>
    <sec id="sec-2">
      <title>2 Introduction: the SESAR Program</title>
      <p>The SESAR program is the technological part of the Single European Sky initiative.
The current phase addresses the Research and Development (R&amp;D) activities to
define the Operational concept and technical solutions to meet the challenging
performance targets for 2020:
-­‐ 27% increase in Europe's airspace capacity,
-­‐ 40% reduction in accident risk per flight hour despite an increase in air
traffic,
-­‐ 2.8% reduction per flight in environmental impact (e.g. C02 emission),
-­‐ 6% reduction in cost per flight.</p>
      <p>The SESAR program deals with a collection of pre-identified Operational
Improvement steps (OIs) and corresponding Enablers (ENs) that need to be matured in
two ways:
-­‐
-­‐
refinement of their definition,
verification and validation (V&amp;V) aiming at increasing the confidence
in their feasibility and ability to achieve the requirements, including
allocated performance requirements.</p>
      <p>The R&amp;D activities are achieved by a high number of entities (Air National or
International Service Providers and Industrials) that have their own methods, interests,
and program of work but share the common goal to integrate the validated
improvements in their operational environment and products.</p>
      <p>SESAR Features:
-­‐
-­‐
-­‐
more than 300 projects working in parallel on around 40 Operation
Focus Areas
3 steps (2013 – 2015- 2017) planned,
200 Operational Improvement steps (OIs) already identified</p>
    </sec>
    <sec id="sec-3">
      <title>3 Methodological considerations for a R&amp;D program</title>
      <p>The classical V-cycle (waterfall) is a valid reference to conduct the proper
development and validation of the concepts and solutions. The V-cycle is used as a reference
to harmonize (or internally standardize) the development and validation activities and
documentation.</p>
      <p>Two methodological considerations, meaningful in any System of Systems R&amp;D
programme, are discussed hereafter:
-­‐ Top-down versus bottom-up design approach,
-­‐ "incremental" and "spiral" development methods.</p>
      <sec id="sec-3-1">
        <title>3.1 Top-down versus bottom-up in a R&amp;D program</title>
        <p>In the commonly accepted meaning, top-down development refers to the derivation
of high-level (user) requirements down to lower level (system / component levels). In
the SESAR case, top-down here means that the driver is the performance target.</p>
        <p>Bottom-up here reflects the fact that some Operational concepts or Operational
Improvement steps and Technological evolutions (of Technical Enablers) are defined
and developed by the experts as a result of local needs rather than by a direct
derivation of higher level requirements.</p>
        <p>In a R&amp;D program, the solutions are often proposed spontaneously by the experts and even
their refinement results from the deepening of emerging ideas rather than from a mere
problem-solution development.</p>
        <p>So this apparent contradiction can be resolved by applying a "selection" process, based on
the joint assessment of maturity and performance. If a solution, based on the validation results,
is not promising enough in terms of contribution to the global performance targets it could be
rejected in favour of a more promising improvement.</p>
      </sec>
      <sec id="sec-3-2">
        <title>3.2 Incremental versus spiral development</title>
        <p>In a classical development, resource and risk management lead to develop successive
increments. In a R&amp;D program, it is preferable to take into account the results of a
validation stage before deciding investment to further develop / mature the
considered operational improvement.</p>
        <p>
          The two approaches: incremental and evolutionary or spiral are briefly compared
hereafter (reference [
          <xref ref-type="bibr" rid="ref1">1</xref>
          ]2 can be considered for the definition of these terms).
        </p>
      </sec>
      <sec id="sec-3-3">
        <title>3.2.1 Incremental development</title>
        <p>The incremental build model is a method of development where the solution is
designed, implemented and tested incrementally. The product is defined as finished
when it satisfies all of its requirements. This allows partial utilization of product and
avoids a long development time. This incremental implementation support
stakeholders confidence, as incremental improvements progressively introduce partial
capabilities.</p>
        <p>In the SESAR program, 3 steps have been predefined with corresponding sets of
OIs . Their development and validation are planned over several years in high-level
roadmaps (release strategy and Validation roadmaps). In a sense, the SESAR
program is basically incremental, where "block builds" correspond to the pre-planned
content of the 3 steps.</p>
      </sec>
      <sec id="sec-3-4">
        <title>3.2.2 Spiral development</title>
        <p>The spiral development model process combines advantages of both top-down and
bottom-up approaches. It combines the features of the prototyping and the waterfall
model. The spiral model is suited to large, expensive and complicated systems.</p>
        <p>In practice, in the SESAR program, the full set of OIs and Enablers was not fully
and precisely defined at the beginning. Due to the R&amp;D nature of the Programme,
most of them need to be refined or modified according to the results of the ongoing
experiments and development activities, supported by prototyping.</p>
        <p>
          2 Reference [
          <xref ref-type="bibr" rid="ref1">1</xref>
          ] defines Evolutionary in the following way: "Plan, specify, and implement
an initial system capability. Gain experience with the initial system and define the next
iteration to fix problems and extend capabilities. Refine the Concept of Operations, add and change
system requirements, and revise the design as necessary. Continue with successive iterative
refinements until the system is complete. This strategy can be shown as a series of “Vs” that
are placed end to end since system operation on the right side of the “V” influences the next
iteration. …For particularly complex projects, a spiral model may be used, which is an
evolutionary approach that is driven by risk management and extensive planning in each iteration. In
the spiral model, the initial iterations include prototyping, analyses, and studies that are
intended to reduce risk prior to implementation of an operational capability. The products in each
iteration are defined to reduce risk as the system’s degree of definition and implementation is
increased incrementally."
        </p>
      </sec>
    </sec>
    <sec id="sec-4">
      <title>4 Key SESAR System Engineering Management features</title>
      <sec id="sec-4-1">
        <title>4.1 Discrete Operational Improvements steps</title>
        <p>The Operational Improvement Steps are the smallest elements of the Operational
concept. They have initially been defined during the Definition phase of SESAR and
are permanently refined during campaigns. Their implementation into the real ATM
system has been planned with Initial Operational Capability (IOC) dates set assuming
an initial maturity.</p>
        <p>These Operational improvements rely on several Enablers (ENs), including in
particular the System Enablers based on technological development.</p>
        <p>OIs having strong dependencies and contributing to the solution of the same
problem may be grouped into a “SESAR Solution” to be jointly validated. For the sake of
simplicity we consider in the sequel that SESAR solutions are OIs.</p>
        <p>At the end of the operational concept development activity, all Operational
Improvement steps are characterized by operational and performance requirements and
all related System Enablers are characterized by technical requirements. In most
cases, the performance requirements are initially set in a qualitative way and are
more precisely defined during the maturation process.</p>
      </sec>
      <sec id="sec-4-2">
        <title>4.2 Development and validation stages in SESAR</title>
        <p>With reference to the classical V-cycle, the development and validation activities
of OI steps follow the generic stream:
-­‐ Concept definition, Definition of Operational Requirements, along with
their Safety and Performance Requirements, Operational Concept
development and, simultaneously, Validation plan production,
-­‐ Development of System Requirements meeting the Operational
Requirements (for all Systems contributing to the corresponding Operational
Improvement) , and simultaneously production of the Verification plan,
-­‐ System solution development with prototypes and platform integration,
-­‐ Verification that each System satisfies its requirements,
-­‐ Validation of the operational concept and related performance.</p>
        <p>Standard SESAR documentation has been defined to ensure the consistent
development of requirements and validation objectives.</p>
      </sec>
      <sec id="sec-4-3">
        <title>4.3 The SESAR performance target</title>
        <p>The performance target addresses Key Performance Areas (KPAs), with
corresponding Key Performance Indicators (KPIs) for the overarching ATM system of
systems.</p>
        <p>The political targets are split over each of the 3 program steps.</p>
        <p>The KPIs are broken down in a number of Performance Indicators (PIs) with
associated metrics. PIs are related to KPIs via modelling techniques called Benefit
Mechanisms. PIs are measured during validation Exercises.</p>
        <p>Managing the performance targets on PIs as requirements, allow linking the
political target and project activity.</p>
        <p>So the validation activities allow risk-reduction as regards performance. Indeed,
the performance uncertainty decreases and confidence that the performance target
will be met increases (as notionally represented in the figure below).
min (10%)
most likely
max (90%)
Target
69% 69% 69% 69% 76% 86% 86% 90% 97% 99% 100%</p>
        <p>(In this case, the probability that target is met increases with time)</p>
      </sec>
      <sec id="sec-4-4">
        <title>4.4 Maturation and program steering Figure 2: SESAR within the E-OCVM lifecycle</title>
        <p>SESAR covers three phases of the E-OCVM lifecycle: V1, V2 and V3. These
three phases correspond to 3 development iterations of the development process,
ending to increasing level of maturity. The SJU has developed a set of criteria to
address the 3 transitions: V1 to V2, V2 to V3, V3 to V4.</p>
        <p>For each OIs, a validation strategy is defined to plan sequence of activities that
end to a completely V3-mature delivery at a date compatible with the planned IOC
date (generally, V3 should be completed at least 2 years before the IOC to let
sufficient time for eventual V4 industrialization and certification activities). A "top-down
Verification and Validation Roadmap" is regularly updated to refine the planning of
validation activities in accordance with the validation strategy.</p>
        <p>Every year, the V3 activities for the coming year are planned with a high level of
detail to ensure the concepts will be fully V3-validated at the end of the next year:
this "Release" approach intends to deliver each year a set of V3-validated OIs.</p>
        <p>The management of a Release lays on 3 System Engineering reviews. At the last
one, the actual maturity is assessed based on the provided evidence, including
Validation-Exercise-Reports. If most V3-to-V4 criteria are satisfied, the corresponding
OIs are "released" by the SESAR program.</p>
        <p>Monitoring the maturity supports the decision to proceed to the next phase and to
continue investing into solutions. This monitoring process takes place from initial V1
to V3 maturity level, with increased attention at the latest stages (especially in
Release monitoring). Such a continuous monitoring supports decision to stop, redirect
or reallocate resources towards the most beneficial OIs, with consideration of their
time-horizon.</p>
      </sec>
    </sec>
    <sec id="sec-5">
      <title>5 Conclusion: the SoS concurrent design challenge</title>
      <p>The SESAR program addresses concurrent engineering of a large System of
Systems. As such, the various developments of all its constituting elements need to be
coordinated, taking benefit from both top-down approach and from the use of
successive development and validation activities to improve the definition of the
Operational concept elements.</p>
      <p>Strict monitoring of maturity and steering the program based on the expected
performance benefits ensure that the parallel developments and validation activities,
achieved by 300 projects working in parallel, are properly synchronized and steered.</p>
      <p>This has been permitted, within SESAR, by defining standard levels and standard
maturity criteria and by imposing a pace with annual releases and synchronization
points. Such an approach demonstrated its efficiency, since 2013 will see the 3rd
Release of V3-validated sets of OIs, grouped into SESAR Solutions.</p>
      <p>However, consolidating results and feeding back, to properly drive the program
from the performance view, has demonstrated to be uneasy, and remains a challenge.</p>
    </sec>
  </body>
  <back>
    <ref-list>
      <ref id="ref1">
        <mixed-citation>
          <article-title>[1] System Engineering for Intelligent Transportation Systems</article-title>
          , US Dept of Transportation,
          <year>2007</year>
        </mixed-citation>
      </ref>
      <ref id="ref2">
        <mixed-citation>
          [2]
          <string-name>
            <given-names>Systems</given-names>
            <surname>Engineering</surname>
          </string-name>
          <string-name>
            <surname>Handbook</surname>
          </string-name>
          ,
          <article-title>a guide for system lifecycle processes and activities</article-title>
          ,
          <source>International Council on Systems Engineering (INCOSE), version 3.1 August</source>
          <year>2007</year>
          .
        </mixed-citation>
      </ref>
      <ref id="ref3">
        <mixed-citation>
          [3]
          <string-name>
            <surname>Baldwin</surname>
            ,
            <given-names>K.</given-names>
          </string-name>
          , June 28,
          <year>2007</year>
          ,
          <article-title>"Systems of Systems: Challenges for Systems Engineering</article-title>
          , INCOSE SoS SE Panel.
        </mixed-citation>
      </ref>
      <ref id="ref4">
        <mixed-citation>
          [5]
          <string-name>
            <surname>Maier</surname>
            ,
            <given-names>M.</given-names>
          </string-name>
          ,
          <year>1998</year>
          ,
          <article-title>"Architecting Principles for Systems-of-</article-title>
          <string-name>
            <surname>Systems</surname>
          </string-name>
          ,
          <article-title>"</article-title>
          <source>Systems Engineering</source>
          , Vol.
          <volume>1</volume>
          , No.
          <issue>4</issue>
          , pp
          <fpage>267</fpage>
          -
          <lpage>284</lpage>
          .
        </mixed-citation>
      </ref>
      <ref id="ref5">
        <mixed-citation>
          [6]
          <string-name>
            <surname>Dahmann</surname>
            ,
            <given-names>J.</given-names>
          </string-name>
          and
          <string-name>
            <given-names>K.</given-names>
            <surname>Baldwin</surname>
          </string-name>
          , April 7-
          <issue>10</issue>
          ,
          <year>2008</year>
          ,
          <article-title>"Understanding the Current State of US Defense Systems of Systems and the Implications for Systems Engineering,"</article-title>
          <source>IEEE Systems Conference</source>
          , Montreal, Canada.
        </mixed-citation>
      </ref>
      <ref id="ref6">
        <mixed-citation>
          <article-title>[7] Office of the Undersecretary of Defense for Acquisition, Technology</article-title>
          and
          <string-name>
            <surname>Logistics (OUSD AT</surname>
          </string-name>
          &amp;L),
          <year>August 2008</year>
          ,
          <source>Systems Engineering Guide for Systems of Systems</source>
          , Washington, DC.
        </mixed-citation>
      </ref>
    </ref-list>
  </back>
</article>