Applied System Engineering

Dr. Andreas Edom

12. System Modification Process

Agenda

1 – Configuration Management

2 – The Change Process

3 – Pre-Delivery Modifications

4 – Post-Delivery Modifications
Configuration Management
What is a baseline?
 During the progress of the development process after every design review
the system definition becomes more refined.
As early as the concept review a configuration baseline is established
that is updated from one review to the next.
 The baseline constitutes the single point of reference for all project members
involved in the design process
 A responsible person inside system engineering is needed who officially
updates and cares for the baseline the configuration manager
Without configuration management (CM) uncontrolled changes
may result in systems that -- need countless changes
-- do not meet user needs

 CM applies for all system hardware and software

regardless of whether it was developed inhouse or by a supplier
like -- components of-the-shelf (COTS)
-- customer furnished components (BFE)

3
Configuration Management
 CM tasks:
 Determine a baseline for the configuration of the system at planned points of time
during the whole system life cycle (not only during the development process!)
 Control changes to the baselined configuration
 Ensure the traceability of the configuration via control of related documentation
 Generate and release reports that communicate
the status of changes to the baseline
 Changes to a given baseline can be initiated from any one of the project stakeholders
during any phase in the system life cycle.
also known as
Such changes are prepared in the form of a Request for Change. Engineering
Change Proposal
They are classified according to their severity: (ECP)
submitted to RFC
 Class 1 (major) changes customer approval
before implementation!
affect fit, form and/or function (FFF)
Impact on system performance, reliability, safety, life-cycle cost, any other system specification requirement
 Class 2 (minor) changes
of minor importance, do not affect important system specification requirements
Examples: material substitutions, documentation clarification, drawing nomenclature, production changes

4
The Change Process
 The process is triggered by a RFC that shall include
 statement of the issue and description of proposed change
 brief description of alternatives that respond to the need for change
 analysis showing how the change will solve the problem
 RFC‘s are treated by the Change Control Board (CCB) for review and evaluation
 CCB meetings are similar to those convoked for formal design review,
but only covering development disciplines that are impacted by the change
including customer and supplier representatives,
according to the respective life cycle phase. Design Change
Review
 CCB responsibilities:
 review requested change for -- technical solutions
-- cost
-- schedule
-- contract issues
 authorise work associated with the RFC and distribute budget for cost impacts
 update project schedules, databases and budget
5
The Change Process Pre-delivery modification
Post-delivery modification

Operational Use /
 The formal technical Design and Development Serial Production
Product Support
answer to a RFC
is the Request for Change Request for Change Request for Change
(RFC) (RFC) (RFC)

Technical
Repercussion Change Control Board
Evaluation of change impact
Sheet by Repercussion Sheets
TRS
Is the change no
Discard this change
feasible?
 With the incorporation of
yes
suitable changes
Planning of change
 system configurations implementation
are updated
 a new baseline Development of Revision of supporting data
modification kits and new and documentation
is established, if installation procedures
-- the system is still
under development Incorporation of change

-- in-service problems
have occurred
no Suitability of the yes System returned
Re-design required
change verified? to life cycle

6
The Change Process
 Topics of a TRS (Source: Airbus)
 description of the request and reason for proposal
 originator of the request
 expected applicability
 classification of the change
 engineering deadline
 impacts on
-- other components
-- parts interchangeability
-- approved documentation and instructions
-- verification means
Mock-up, laboratory test equipment
-- weight
-- electrical loads
-- standard specifications
-- harnesses, circuits and panels
-- ESD and other certification items
-- rigging and tooling
-- handling and support equipment
 upcoming activities
7
The Change Process
 Additionally further repercussions are evaluated by
Production and Cost Repercussion Sheets (PRS, CRS)

Implementation of changes handled during the Development Process

 When the design change is approved by the Change Control Board
and formally included in the baseline by the Configuration Manager
a Design Change Notice (DCN) is released
together with
applicable drawings and documentation
covering areas of design that are affected by the change. DCN
The DCN becomes available to the customer and the staff in charge of the change.

 Sometimes further changes are requested during serial production or product support.
They can be devided into modifications before and after delivery of the product.
However, the change process until the approval of the change remains the same.

8
Pre-Delivery Modifications
What are possible origins for product modifications?

Customer Requests two cases

1 The customer can request a modification according to his particular needs for
-- operation
-- branding and differentiation
so-called Customisation
-- BFE
If the request is accepted,
a Specification Change Notice (SCN) is issued SCN
2 The producer may offer variable configuration items of his product
The customer selects his personal configuration from a catalogue of options
Manufacturer Requests Relaunch

 The producer himself enhances the quality or standard of his product due to
 product improvement (triggered by Customer Support and in-service feedback)
 authorities regulations
an inhouse RFC is launched.
If the request is accepted,
a Manufacturer Specification Change Notice (MSCN) is issued MSCN

9
Pre-Delivery Modifications
 In case of relaunch the MSCN must define a certain serial number as being effective
that means: -- The change will be incorporated on the production line
from serial number “X“ onwards
-- Serial numbers „X“ and following comply with an new baseline

 Request types shown with an example  Standard bicycle made of aluminum

standard specification standard specification catalogue specific request

aluminum pedals evolution premium option wood pedals
carbon pedals titanium pedals customised
configuration item,
product improvement,
needs RFC
included in next issue of standard specification,
needs RFC
10
Post-Delivery Modifications
 For products that are already in use changes are incorporated
through the installation of a modification kit
in the field at the customer‘s site.
 This activity is called Retrofit.
 At the same time the support infrastructure has to be upgraded
to be compatible with the modification.
Examples: test equipment, ground support equipment, spares, technical data

 Post-delivery modifications can be originated by four possible parties

1 The Customer who wants to upgrade a system
that is in faultless operation for quite some time,
instead of buying a new one
2 The Manufacturer having detected several occurences
3 An Authority of an unexpected in-service problem
4 A Supplier after amending or improving his equipment
 In the automotive, railway or aircraft industry the manufacturer issues
a Service Bulletin (SB) with classifications -- alert or standard
-- mandatory or optional SB
replaces the TRS immediate action required
11
 Conclusion I

 A Modification / Change can be initiated by

 the customer
 the manufacturer / producer
 a subsystem or component supplier
 a regulating authority
and can be requested throughout the whole life cycle of the system

 The change process is tightly monitored by the Configuration Manager

 It starts with the reception of the Request for Change
 It ends with issuing a Change Notice and baselining the change
Modifications that are not baselined are
 responding to a customisation request
 options given in the producer‘s configuration catalogue

12
Conclusion II

 The development of the change is done by the same system and design engineers
that are or were involved in the development of the affected system
 Some of the most experienced system engineers constitute the Change Control Board
that gets together at formal design change reviews
 to evaluate the change proposal through formal procedures
on the basis of Repercussion Sheets or Service Bulletins
 to decide -- if Exception: Changes triggered by alert or mandatory Service Bulletins
must not be refused!
-- when
-- how
the change will be incorporated

13