ESOC Darmstadt

1
EGOS Presentation
Columbus Control Centre and its Ground
Communication Infrastructure Towards a Service
Concept Challenges and Opportunities
ESOC / Darmstadt 8-10 Nov 2005
François Allard ESA/ESTEC HME-EOG 31 71 565
3250 Francois.Allard_at_esa.int
Thierry Lefort Booz Allen Hamilton 31 20 504
1962 Lefort_Thierry_at_bah.com
2
Table of Contents

• A Multi-Mission Ground Segment for European ISS
  Elements
• Rationale for a Service Concept
• Service Concept
• Issues and Challenges
• Controlled Evolution towards a Service Oriented
  Organisation

3
ESA is completing the development of the Columbus
Control Centre (COL-CC) and its Communications
Infrastructure (HME-CI)

• The COL-CC provides
• Monitoring Control for Columbus (MC),
• Support for decentralised operations of European
  Payloads in Columbus, US Lab and Russian
  Segment.
• The HME-CI provides links for service provisions
  to
• Columbus Control Centre (COL-CC)
• Autonomous Transfer Vehicle Control
  Centre(ATV-CC)
• Engineering Support Centres (ESC)
• International Partners sites
• Payload User Support Operations Centres (USOCs)
• REDU ground station for ATV up/downlink
• ATV-CC relies on NASA MCC-H White Sands or REDU
  ground station for uplink/downlink of TC/TM
• Columbus system and payload operations are
  performed via NASA MCC-H and White Sands ground
  station

Space Ground
4
COL-CC and HME Comms Infrastructure encompass
more than 20 sites. All subsystems participate to
Columbus support configuration
USOCs
Partner Sites
ARTEMIS Ground station
Source Colin Ward (SESS)
ESCs
5
While only a subset is used for the ATV support
configuration.
6
The COL-CC Architecture relies on scalable and
redundant components for critical services
Overview comms Services

• Comms architecture
• Redundant central node connecting to all sites
  remote Nodes in a hybrid topology (star from
  COL-CC direct connectivity for ATV related
  sites) via redundant ATM (sites part of the core
  network) and/or ISDN (for backup or to USOCs with
  low bandwidth requirements).
• In addition ATM point to point for ATV-CC to REDU
  and ATV-CC to MCC-H, ISDN point to point ATV-CC
  to LMX. Satellite connectivity for reduced backup
  between COL-CC and MCC-M.

• Comms Services
• ATM and ISDN PRI, BRI
• IP connectivity (ATV TM/TC)
• Comms link Protection (e.g. VPN for ATV)
• Data, Voice, Video Services
• FTP between COL-CC and remote sites
• Timing
• Domain Name Service

Operational Installation in progress Planned
(currently ISDN)
7
The Columbus Ground Segment Architecture relies
on scalable and redundant components for its
Data services. The CD-MCS provides a standard
client implementation for all USOCs.

• Data System architecture
• Redundant Kernel at COL-CC serving local or
  remote client connections
• API implementation at each remote site of Client
  Service (Path TM, processed Data distribution),
  and optionally a Server Service (commands,
  process data contribution)
• TM Distribution according to CCSDS APID
• DaSS Data Services CD-MCS client support
• CCSDS Packet Data Delivery Y
• Processed Parameter Delivery Y
• CCSDS Command Forwarding Y
• Command Echo Y
• High Rate Bitstream Data Delivery Y
• Data Modes
• Real-time (OPS, Sim, Test) Y
• Playback (from DaSS archive) Y
• External playback Y
• Direct delivery of Bitstream Y
• Deferred and rate-adjusted (bitstream) Y

• CD-MCS implementation provides
• Similar SW as in COL-CC (MCS, DaSS)
• Central configuration with one Mission Database
• Centrally maintained
• Processed Data exchange between USOCs via COL-CC

CD-MCS WS
8
The COL-CC Architecture relies on scalable and
redundant components for its Voice system and to
a lower extent for its Video system

• The voice system provides conference loops to all
  participants. It architecture is based on
• Redundant Matrices at COL-CC connecting remote
  matrices at Partner sites ATV-CC, MCC-H, HOSC,
  MCC-M, EAC.
• Dedicated Keysets at COL-CC
• Dedicated Keysets at User sites via ISDN
  connection.
• Voice Services
• Provision of Voice keysets
• Voice channels (up to 1000)
• Voice recording retrieval
• The Video System provides distribution of video
  channels across the Ground Segment.
• Video Services
• MPEG-2 over ATM
• MPEG2 over IP
• Channel Selection
• Extraction of Video From High Rate downlink
• Archiving, recording, retrieval, playback

9
Most other subsystems implement high availability
architectures

• NIS provides the Network Infrastructure for
  discriminated areas OPS, OPS SUPPORT, and OFFICE
  internal NIS Services include
• Connectivity, Traffic separation, Network
  Security
• IMS Integrated Management System, Connects to
  all subsystems Element Managers via SNMP, gather
  equipment status, some level of control of the
  Element Managers
• Ground Network overview
• Trouble Ticket System
• Data, Voice, Video sub-systems overview
• INFRA_SAN provides servers to host
  mostsubsystems, and a high availability storage
  backup
• INFRA_GEN Implements Timing, Syslogs, User Rooms
  Workstations, security LDAP architecture
  connecting to ESA PKI (Public Key Infrastructure)
  located at ESTEC/OMT
• MCS Monitoring and Control s/s provides a
  Central TM and Command server, and peripheral WS.
  CTM hosts the Mission Database (MDB) and a Result
  Database (TRDB).
• TQVS Services
• Simulation of Columbus and GS TM
• Simulation of TC response

Overview provided by the IntegratedManagement
System
Storage Architecture
10
The Ground Segment architecture scalability
supports delegation of responsibility

• The architecture provides flexibility through
  scalable systems, dynamic assignments or reserve
  capacity for critical components, e.g.
• Data system scalable number of servers
• Data system dynamically assignable processes
• MCS clients can be added to increase the number
  of console operator Workstations
• Voice system supporting a number of voice
  channels that largely exceed todays requirements
• Keysets that can be added at COL-CC or remote
  sites
• SAN having large storage capacity reserves
• Standard and customized IGS nodes. A portable
  node connecting via ISDN can be deployed to
  temporary sites
• Network ports can be added and LAN WAN
  bandwidth can be increased, ATM virtual channels
  added
• Standard remote client architecture for all USOCs
  (CD-MCS)
• Etc
• COL-CC can be configured to support several
  missions with different profiles
• The design provides flexible capabilities through
  standard, Static or Dynamic scalability that make
  it fit to absorb additional mission requirements
  without incurring redesign.
• Scalability facilitates the packaging of
  services, and delegating the responsibility for
  accommodating possible changes.

11
Table of Contents

• A Multi-Mission Ground Segment for European ISS
  Elements
• Rationale for a Service Concept
• Service Concept
• Issues and Challenges
• Controlled Evolution towards a Service Oriented
  Organisation

12
The recurrence of activities over a long
duration programme, and a necessary drive for
cost optimisation provide a Rationale for a
Service Concept

• The Stakeholders and players are
• the Customer (ESA),
• the clients (recipients of the service) which
  include also users (beneficiaries of the
  service),
• the Service provider to ESA (IOT) which integrate
  Service provision to clients and users through
  SLA with various Service Providers (incl. DLR)
  and sub systems suppliers.
• Goals of a Service Concept for the customer
  (ESA)
• Externalise recurrent services associated to
  product deliveries or pure operational services
• Ensure and control service performance
• Encourage optimisation of service provision
  across multi-mission environments and mission
  profiles
• Control costs associated to service delivery to
  users/clients
• Provide a framework to foster cost optimisation
  including internal costs over long duration
  programmes ISS and ATV operations supposed to
  last 10 years
• Recurrence of activities implies
• Recurring process oriented tasks to run the
  infrastructure
• But also concurrent adjustments and their
  validation to meet new mission requirements

13
The Service concept allows ESA to concentrate on
its programmatic objectives

• ESAs objectives with the Service Concept is to
• Concentrate on the Exploitation phase
• ESA objective is to focus on space exploitation
  and delegate the maintenance of the ground
  infrastructure. The infrastructure availability
  is perceived as a service rather than a product.
• Once the ground segment is qualified, there will
  be limited evolution driven by programmatic
  changes (Contained growth)
• Delegate to Industry
• ESA has contracted an Industrial Operator (IOT)
  to manage the multiple organizations involved in
  supporting the infrastructure (DLR, EADS,
  Subcontractors, Suppliers) and support ESA
  maintain interfaces with the International
  Partners
• Assign a role to industry
• Stream line performance delivered by Industry
• Self manage manpower to achieve performance level
• Drive Cost optimization
• Let industry deal with manpower and quality
  improvement by setting agreed performance targets
• Focus its staffing on Agency responsibilities
• To allow ESA staff to concentrate on
  implementation of programmatic requirements and
  performance management and delegate to industry
  the infrastructure operations.

14
COL-CC and HME-CI provide Multi-missions support
through the use of generic and specific
capabilities, to serve different users or
clients
Missions/Activities
Internal Users
External Users

• Missions typically relate to a spacecraft, or
  governing Authority (ESA, NASA, or RSA) and last
  from 10 days to an ISS increment.
• Activities are ground preparation related.

• Internal users are located at COL-CC

• External users are recipients of services through
  the IGS network, the internet, or PTN

TYPE

• Columbus
• ATV
• Interim Utilisation (Soyuz)
• Col SVTs
• Col End to End Tests
• ATV End to End Tests
• Col Sims
• EAC Sims

• Flight Control Team
• Ground Operations Team
• Planning Team

• USOC teams
• NASA Flight control team
• ESA Moscow team
• RSA flight control team
• ATV Flight control team
• Support teams at EAC,
• Support teams at ESC
• Ops Mgt Team (OMT)

EXAMPLE
supported by
Generic capabilities
Specific capabilitiesfor specific Missions

• Comms
• Data system
• Voice system
• Video system
• IMS
• SAN

• MCS ? Columbus systems
• TQVS ? Columbus Sims
• Trek/ISP ? Payloads in US racks/US Lab
• OST ? OST for Each mission type

15
Table of Contents

• A Multi-Mission Ground Segment for European ISS
  Elements
• Rational for a Service Concept
• Service Concept
• Issues and Challenges
• Controlled Evolution towards a Service Oriented
  Organisation

16
The Service Concept identifies Services that can
be characterised in terms of provision to users,
expected performance, agreed metrics and
performance reporting methods.
iteration
Service Definition
Periodic Review
Key Performance Indicators Definition

• End to End services
• Voice
• Video
• Processed Data
• Path TM
• Command
• Monitoring
• CM
• Comms
• OST
• Planning
• Infrastructure
• Training
• Management
• Accounting
• Change
• Interface

Service Chain Assessment

• Time to Restore Service
• Time to Restore Redundancy
• Detection Time
• Response Time
• Quality (losses, jitter, bit error rate)
• Rate (fps, kbps,)

Team Organization

• Dependencies
• Maintainability
• Necessary Internal Resources
• Necessary supplier SLA

Metrics Agreement

• Lead through QoS
• Flow down Performance objectives
• Service Engineers
• Service Managers
• SLA manager

Measurement reporting

• Iteration
• Reflect in supplier SLA

• Tools
• Reporting methods / Processes
• User measurements
• SP measurements
• Customer measurements

SLA Service Level Agreement
17
Services definition considerstechnical
interfaces, user base, and agreed implementation
supporting planned performance

• The technical definition of an end to end service
  gather
• The capabilities of the sub-Systems (e.g.
  provision of voice channels)
• The characteristics of the technical interface
  (e.g. MPEG2 over ATM or IP)
• The provision of products to users (e.g. voice
  keysets)
• The operations realized for the user (e.g.
  extraction of video from High rate channel)
• The operations realized upon request (e.g.
  archiving, retrieval)
• The capabilities provided to users (e.g.
  selection of video channels)
• The service client base include
• The recipient of the service (on both ends)
• The user or beneficiary of the service
• The customer
• Service characteristics highlight the agreed
  implementation supporting the planned performance
  of service criteria
• Automated/coordinated (whether the service is
  controlled through an operator)
• Proactive/Reactive monitoring (whether the
  service is monitored by operator or left to the
  user)
• Workaround predefined (used to restore even
  temporarily the service)
• Constraints (e.g. maximum design capacity)
• Redundancy (e.g. Hot, Cold)

• Functional Services
• Voice Services
• Video Distribution Services
• Video Conferencing Services
• On line Data Services (monitoring control)
• Off line data services
• Comms Services
• Ground Segment Monitoring Services
• Ops support services
• User Services
• mission support Services
• Simulation services
• Training Services
• Support Services
• Infrastructure services
• Maintenance Services

18
Service Control can be achievedthrough the
design of a dashboard for transparent and
effective reporting of performance data

• Service scope and ESA responsibilities
• Collecting performance data
• Sub system engineers report on performance (eg
  downtime..)
• Service performance assessment and validation
• Industrial Operator (IOT) Help desk
• In-situ Tools Periodic scans
• Annual/bi-annual ESA questionnaire to Users to
  confirm overall IOT figures
• Service evolution Use of standard templatesplus
  appendices for new/altered services
• Breach of performance
• On critical services application of escalation
  procedure
• On management services penalties
• On overall user satisfaction handled at SLA
  review

Helpdesk KPIs (Internal, Ext users)
Management Planning KPIs
Planned budgets
Configuration Management KPIs
End to End services KPIs
Change Management (PIRN, ECR) KPIs
Dashboard Data Requirements and Tools
19
For each phase of a Mission Support, for instance
ATV missions, service requirements are
established by defining e.g. 3 groups of metrics
values - Critical, High, Routine - for each
service.

• Red circles indicate stringent level of service

1
2
3
5
4
Service Phase
ATV TDRSS TM/TC
ATV ARTEMIS TM/TC
ATV/LMX TM/TC
ISSMCC-H Processed Data
ISSMCC-M Processed Data
DaSS Processed Data
ATV Processed Data
Voice
Video
OST
LEOP
C
R
R
R
R
R
R
R
H
R
Phasing
H
H
R
R
R
R
R
R

R
Rendez-vous
C
C
R
H
H
R
H
H
H
R
Attached Dormant
R
R
R
R
R
R
R
R
R
Attached Active
H
H
R
R
R
R
H
H
R
Departure Reentry
C
R
R
R
R
R
H
H
H
R
CCritical Level HHigh Level RRoutine Level
20
For each Mission Support phase and client, a
service provision is defined to form an
Operations Support Plan
Activities include -Mission critical
operations -Mission routine operations -Simulation
activities -Routine activities -Non active status
Activity 2
Activity 1
Activity 3

• Return to Service time
• Return to redundancy time
• Response time
• Ops Support coverage
• Maintenance Support coverage
• Disruptive activity Scheduling
• Configuration freeze

• 1 min
• 4 h
• 15 min
• 24x7
• 24x7
• Not Allowed
• Required

• 1 hour
• 24 h
• 1 h
• 16x5
• 8x 5
• Allowed
• Required

• 4 h
• 24 h
• 2 h
• 8x5
• 8x5
• Allowed
• Not Required

• Activities can overlap and be related to sub
  groups of users internal or external to a given
  control centre internal or external to a control
  centre (e.g. Payload operations during ATV
  docking)
• User requirements for Availability, Security,
  etc may vary (institutional/commercial user)

21
And translated into a collections of Service
Level Agreements and Maintenance Agreements part
of the Operations Maintenance Implementation
Plan
OSP
ICD
OSP
Service Definition
OMIP
GSSRD
User Services
SLA
Voice sub-system Supplier
OMIP
SLA
Functional Services
Video sub-system Supplier
SLA
SAN sub-system Supplier
Data sub-system Supplier
SLA
Support Services
sub-system Supplier
MA
Impact of Service Definition Update on Control
documents
MA
Maintenance Agreement with remote Facility User
MA Maintenance Agreement GSSRD Ground Segment
System Requirement Document OMIP Operations
Maintenance Implementation Plan SLA Service
Level Agreement, contractual agreement OSP
Operations Support Plan, agreement for
support ICD Interface Control Document
22
Table of Contents

• A Multi-Mission Ground Segment for European ISS
  Elements
• Rationale for a Service Concept
• Service Concept
• Issues and Challenges
• Controlled Evolution towards a Service Oriented
  Organisation

23
Issues and Challenges

• Defining services Determine how a service is
  handled internally by the SP (compared to a
  delivery), setup of objectives, and implications
  on the organisation, coordination across service
  teams and internal reporting.
• Defining service performance and its measurement
  the measure of down time or repair time, QoS,
  measurement point (user/client, IMS, customer)
• Dealing with risks associated to external
  dependencies the definition of external risks
  with possible impact on the ability of meeting
  the agreed metrics values, and handling of those
  risks.
• Integrate the development cycle milestones
  (Detailed Requirements, Design, Testing,
  Verification) for changes driven by programmatic
  decisions, into the Service concept
• The extent of non assignable ESA responsibilities
  are addressed by a Ground Segment Control Board
  chaired by ESA, which issues directives on
  specific processes, and handles issues with a
  larger scope IPs ICD changes, Flight Safety,
  Ground Segment Security (accreditation,
  revocation of users), Accountability vis a vis
  external Partners.
• Organizational challenges For service
  performance incentives to be effective, the
  organisation structure and task definition need
  to reflect the flow down of Service Level
  requirements
• Migration of the initial contract towards a true
  service oriented organisation.

24
The Service Concept allows addressing risks of
different nature (Programmatic, Implementation,
Operations) at different levels, with specific
mitigation responses

• Programmatic risks ? ESA
• Schedule uncertainty from an IP or ATV programme
  resulting in e.g. delayed interface tests,
  external implementations ()
• Cancellation or delay of a mission (mitigation
  cancellation fees)
• Changes in ground ICDs (ICD changes under ESA
  control)
• Shortage of funding (minimum commitment)
• Changing mission requirements (original design
  for scalability and expansion)
• Implementation risks ? Service Provider
• Delays in implementing new mission requirements
  (efficient project and risk management)
• Internal interfaces issues (early detection)
• Shortage in expertise
• Mis-performance of Service provider
• Operations Implementation risks ? Service
  Provider
• Failures in system (preventative, corrective
  measures)
• Failures in subsystems or sub-service provider
• Shortage in expertise (internal training, pool
  and streamlining of personnel deployment,
  personnel multiple qualifications)

25
Through the establishment of SLAs, ESA/HME and
Industry are learning how to reconcile sometimes
diverging interests

• The Agency seeks mission success at reasonable
  cost

Reconciliation of Diverging Interests
Service Provider Interest tactics
Agency Interest constraints

• Mission success
• Risk assessment
• Decision making in critical phases
• Costs containment and predictability
• Reach Confidence through visibility
• Involve Agency staff in key issues
• Confidentiality of information
• Programmatic constraints may drive Termination

• Provides its core service
• Seek profitability through advantageous penalty
  scheme
• Hide own arrangement behind service
• Fee structure
• Integrates all Costs
• Get rewards for financial risk it takes
• Seek Long term contract

Agency seek SLA focusing on risk / costs tradeoff
(mission success at reasonable cost)
Service Providers tend to provide SLAs focusing
on Financial Scheme and Service Availability
26
Table of Contents

• A Multi-Mission Ground Segment for European ISS
  Elements
• Rationale for a Service Concept
• Service Concept
• Issues and Challenges
• Controlled evolution towards a Service Oriented
  Organization

27
The Service concept relies on an Industrial
Operator to manage the infrastructure.
Ministerial conference
NASA
ESA
RSA
Industrial Operator
Dev Mgt contract / task Idem Until
qualification SLA Operations Sup Plan Partner
Agreement
Supplier
Supplier
COL-CC
NASA Centre
ATV-CC
User Centres (Institutional)
Russian Centre
Supplier
Supplier
Supplier
28
Controlled evolution of the Service definition
and Metrics to ensure that benefits are shared
between ESA and the Service Provider
Necessary Evolution
Action and Anticipated Effect
Current State

• Service definition mainly in ICD for nominal
  service
• One Operation Support plan (ATV)
• Availability requirements not all identified

• Nominal and degraded service provision need to be
  described for each interface
• Performance metrics to be reflect agreed targets

Evolution of Service definition

• OSP need to be established for all ICDs
• Perform bi-annual reviews of service definition

• Manpower oriented task
• Delivery oriented activities
• Cooperation mindset

• Evolution of contractor to mindset of taking
  responsibility for a service and associated risks
• Rationalise the cooperation to a service
  provision

• Users to Learn how to report on services, accept
  provision on the basis of OSP /SLA
• Train users, personnel

Gradual and active adoption of a service attitude

• Internal agreements (NIS to other service
  engineers, service managers)
• Arising issues to be addressed by a bi-lateral
  SLA team.
• May lead to off-cycle changes to the SLA and
  renegotiation

• Heterogeneous nature of the various services
  within COL-CC (e.g. NIS)

• Homogenise the service provision throughout the
  Control centre
• Turn project teams into service teams

Differentiation between Services

• The service provider must have incentives to
  reduce costs in the long run
• The service provider should identify together
  with ESA further cost reduction strategies and
  share success through incentives.

Incentives for cost reduction

• System under qualification
• First initial contract with DLR as a sub/co to
  EADS (IOT) on a 2 year basis for a firm fixed
  price

• Improvement of efficiency (personnel
  qualification, shifts, )
• Active response to price reductions (maintenance
  items, obsolescence management,)

29
BACKUP SLIDES
30
Key Performance Indicator definition

• The KPI and metrics define the expectations of
  end users and of the customer for each individual
  service
• They must be measurable and valid across
  mission/activities type and services. A subset of
  these indicators may apply to some services.
• Time to restore the service This is a max time
  to restore the service. In case of redundant
  system, this will be the time to failover. For
  non redundant services, this will be a mean time,
  and in most cases, workaround will be put in
  place.
• Time to restore the redundancy Once a failure
  occurred on a redundant system, repair is usually
  needed to restore the redundancy. A mean time is
  provided since the recipient is not affected,
  with only the chances that a second failure
  occurs before repair increase with time.
• Detection Time Time take by operator to detect
  the problem The COL-CC does not rely on service
  recipients to detect failures, especially on
  redundant system.
• Response Time organizational response upon
  failure detection, or user report e.g. start of
  troubleshooting, of first feed back to the user.
  It influences user satisfaction.
• Quality Bit error rate, image quality, jitter,
• Rate kpbs, Mbps

31
Team Organization

• The adoption of a Service culture distinguishes
  successful Service Providers
• One of the challenges for most service providers
  is to come up with a service oriented
  organization or grow into a service organization.
• The Service chain assessment provides input to
  the team organization
• E.g. SAN contributes to recording/playback voice
  services ? SAN engineers must live through the
  service expectation of voice users (as well as
  data service users, )
• SLA can be used as clear references to every
  level of the hierarchy on the performance
  expectations.
• Flow down of the performance requirement from
  Service Level Manager to Sub-system engineers
• ? Service Engineers, Service Managers, SLA
  managers

32
SLAs are generally structured into a Terms of
Agreement section and separate Functional
Appendices
Key Service Level Agreement Components
Functional Appendices
Terms of agreement

• Introduction, Scope
• Statement of Intent
• Confidentiality of information
• Capital/financing arrangements
• Duration
• Authorities involved
• Types of services
• Termination Procedure
• Approval Signatures
• Reviews and Contacts
• Escalation process

Services and costs
Service monitoring

• Service Commitments (SP signatures)
• Service Descriptions
• Metrics, KPI definition
• Pricing schedule and structure
• Cost summary
• Payment terms and cycle
• Optional services

• Performance measure-ment of service user
• Performance measure-ment of service provider
• KPI values
• Monitoring and reporting
• Accepted discrepancies and penalties
• Service level discrepancy analysis resolution
• Continuous monitoring process

One general agreement between Service Provider
and Customer, which is expected to remain in
force for several years or duration of the
programme.
Separate appendices are drawn up for each
function. These appendices may be altered
throughout the year as necessary and could be
renegotiated annually.
33
Service Level Agreements include standard
components
Service Level Agreement Components
SLA Component
Description
Executive Summary

• Short summary of the SLA

Statement of Objectives

• Defines overall terms of the contract or
  agreement between teams
• Includes term of contract, Business Units or
  teams covered

Service Menu

• Describes specific services including whats
  excluded from each service
• Details specific rates and subscription fees, or
  team operating times

Metrics

• Documents how successful execution of the
  services will be measured

Charge back / Billing

• Covers how each service will be charged e.g.,
  actual usage and how often and define incentive /
  penalty scheme

Problem Resolution

• Identifies the problem resolution processes for
  different services, with escalation procedures

SLA Review Process

• Lays out the process and frequency for SLA
  reviews over the course of the agreement and
  clauses driven by Programmatic constraints

Appendix Detailed Support Costs

• Provides detailed figures on calculating support
  costs, e.g.
• No. of items to be supported
• Number of people in case of team agreements

34
The Service-Product continuum need to be
considered when defining the services and
associated performance criteria

• Service Product continuum where most delivered
  services fall in between pureservice and pure
  product
• Pure Services have no product associated (IP
  connectivity). The setup of the service
  mayinclude product delivery (IGS Rack,
  encryptingdevices), which will have to be
  controlled andmaintained
• Pure Products do not exist since the
  servicepart essentially refers to the quality of
  the support or product delivered to the
  customer(or client / stakeholder).

• Typically the Service part requires specific set
  of processes to the Products ? Service
  Assurance versus Product Assurance

35
Abbreviations used
ALTEC ASI Logistics and Technological
Engineering Centre API Application Program
Interface ASI Italian Space Agency (Agenzia
Spaziale Italiana) ATM Asynchronous Transfer
Mode ATV Automated Transfer Vehicle ATV-CC ATV
Control Centre ATV R-AFEE Remote Artemis Front
End Equipment ATV R-TFEE Remote TDRS Front End
Equipment B/U Back-up B-USOC Belgian User
Operations Support Centre BIOTESC Biotechnology
Space Support Centre CADMOS Support Centre for
Microgravity and Space Operations Development
(Centre d'Aide au Développement de la
Microgravité et aux Opérations
Spatiales) Col-CC Columbus Control
Centre COL-ESC Columbus ESC (EADS,
Bremen) DAMEC Danish Aerospace Medical Centre of
Research DaSS Data Services Subsystem DCA DaSS
Client API Demux Demultiplexer DK DaSS
Kernel DK DaSS Kernel (for test purposes
only) DSA DaSS Service API DTI DaSS TAXI
Interface DUC Dutch Utilization
Centre EAC European Astronaut Centre EADS-LV Europ
ean Aeronautic Defence and Space Company -
Launch Vehicles ESC Engineering Support
Centre ETM Engineering Test Model HOSC Huntsville
Operations Support Center IDR/UPM Instituto
Universitario de Microgravedad de la Universidad
Politecnica de Madrid
IGS Interconnection Ground Subnetwork IGS CN IGS
Central Node IMS Integrated Management
Subsystem INFRA Infrastructure ISDN Integrated
Services Digital Network ISP Information Sharing
Protocol ISS International Space
Station KS (VoCS) Keysets LMX-ESC Les Mureaux
ESC MPEG Moving Pictures Experts
Group MARS Microgravity Advanced Research and
Support Centre MCC-H Mission Control Center
Houston MCC-M Mission Control Centre
Moscow MCS Monitoring and Control
Subsystem MOSS Multi-media Operations Support
Subsystem MUSC Microgravity User Support
Centre MVDS MPEG-2 Video Distribution
Service (MVDSVCSViDS) N-USOC Norwegian User
Operations Support Centre NIS Network
Infrastructure Subsystem OMT Operations
Management Team OST Operations Support
Tools PFM Prototype Flight Model R-AFEE Remote
Artemis Front End Equipment R-TFEE Remote TDRSS
Front End Equipment SAN Storage Area
Network TAXI Transform, Aggregate, send XML,
Interact TBD To Be Determined TDRS Tracking and
Data Relay Satellite TQVS Training, Qualification
and Validation Subsystem TReK Telescience
Resource Kit VCS Video Conferencing
Service (MVDSVCSViDS) ViDS Video Distribution
Subsystem VoCS Voice Conferencing Subsystem