051650 - Odbor obrannÃ© standardizace - Ministerstvo obrany

ČOS 051650 

1. vydání 

Oprava 1 

ČESKÝ OBRANNÝ STANDARD 

POSTUPY PŘI NABÝVÁNÍ VOJENSKÉHO MATERIÁLU 

S POUŽITÍM KOMERČNĚ NAKUPOVANÝCH PRODUKTŮ 

A TECHNOLOGIÍ 

Praha


1. vydání 

Oprava 1 

(VOLNÁ STRANA)


1. vydání 

Oprava 1 

ČESKÝ OBRANNÝ STANDARD 

POSTUPY PŘI NABÝVÁNÍ VOJENSKÉHO MATERIÁLU S POUŽITÍM KOMERČNĚ 

NAKUPOVANÝCH PRODUKTŮ A TECHNOLOGIÍ 

Základem pro tvorbu tohoto standardu byly následující originály dokumentů: 

STANAG 4598, Ed. 1 GUIDANCE ON THE USE OF COMMER IAL OFF THE SHELF 

(COTS) TECHN LOGY 

Směrnice pro používání volně dostupné technologie 

(zrušen 8.3.2011) 

© Úřad pro obrannou standardizaci, katalogizaci a státní ověřování jakosti 

Praha 2008 

3


1. vydání 

Oprava 1 

Obsah 

Table of Contents 

1 Předmět standardu ............................................. 6 

2 Nahrazení standardů (norem) ............................ 6 

3 Souvisící citované dokumenty ........................... 6 

4 Zpracovatel ČOS ............................................... 7 

5 Použité zkratky, značky a definice .................... 7 

5.1 Zkratky ........................................................... 7 

5.2 Definice .......................................................... 8 

6 Záměr standardu .............................................. 28 

6.1 Dohoda ......................................................... 28 

6.2 Všeobecná ustanovení .................................. 28 

6.3 Podrobnosti standardu .................................. 33 

Přílohy 

Systémy založené na COTS – rozhodující 

charakteristiky .................................................... 35 

A.1 Systémy založené na COTS versus vlastní 

COTS produkty .................................................. 35 

A.2 Charakteristika COTS součástí .................... 36 

A.3 Otevřené standardy ...................................... 37 

A.4 Změny komerčních technologií ................... 39 

A.5 Potřeba znalostí o trhu ................................. 40 

Řízení modifikací a modernizací systému 

............................................................................ 41 

B.1 Terminologie ............................................... 41 

B.2 Řízení případů modernizace ........................ 42 

B.3 Plánování modernizace a proces řízení ........ 47 

B.4 Smluvní ujednání o modernizacích.............. 49 

B.5 Smlouvy na logistické zabezpečení prováděné 

dodavatelem ....................................................... 49 

B.6 Hlavní zabezpečení a úkolování .................. 50 

Management náhradních dílů a management 

konfigurací ......................................................... 52 

C.1 Problémy spojené s COTS ........................... 52 

C.2 Management konfigurací ............................. 52 

C.3 Management náhradních dílů ...................... 55 

6 Aim .................................................................. 28 

6.1 Agreement ..................................................... 28 

6.2 General .......................................................... 28 

6.3 Details of the agreement ............................... 33 

Annexes 

Annex A COTS-Based Systems - Critical 

Characteristics ..................................................... 35 

A.1 COTS-Based Systems v. COTS products 

............................................................................ 35 

A.2 COTS Component Characteristics ............... 36 

A.3 Open Standards ............................................ 37 

A.4 Changes in Commercial Technology ........... 39 

A.5 Need for Market Knowledge ........................ 40 

Annex B Management of System Modifications 

and Upgrades ...................................................... 41 

B.1 Terminology ................................................. 41 

B.2 Management of Upgrade Events .................. 42 

B.3 Upgrade Planning and Management Process47 

B.4 Contractual Arrangements for Upgrades ...... 49 

B.5 CLS Contracts 

............................................................................ 49 

B.6 Core Support plus Tasking ........................... 50 

Annex C Spares Management and Configuration 

Management ........................................................ 52 

C.1 COTS Related Issues .................................... 52 

C.2 Configuration Management .......................... 52 

C.3 Management of Spares ................................. 55 

4


1. vydání 

Oprava 1 

C.4 Náhradní díly a proces managementu 

konfigurací ......................................................... 56 

C.5 Licence k produktům a technická podpora .. 57 

C.6 Pořizování v průběhu životního cyklu ......... 57 

Plán řízení COTS ............................................... 60 

C.4 Spares and Configuration Management 

Process ................................................................ 56 

C.5 Product Licenses and Technical Support ..... 57 

C.6 Whole Life Buys .......................................... 57 

Annex D COTS Management Plan ..................... 60 

5


1. vydání 

Oprava 1 

1 Předmět standardu 

ČOS 051650, 1. vydání, byl zpracován na základě zdrojového dokumentu STANAG 

4598, 1. vydání (Guidance On the Use of Commercial Off the Shelf (COTS) Technology, 

Edition 1 – Směrnice pro používání volně dostupné technologie, 1. vydání), který byl zrušen 

8.3.2011. 

Standard popisuje souhrnný návod pro akvizici, integraci, podporu a údržbu hardwaru, 

který je založen na komerčně nakupovaných produktech, materiálech nebo službách. 

Poskytuje dále rámec pro vývoj, řízení a realizaci komplexních, cenově efektivních strategií 

založených na COTS nebo položkách bez vývoje. Tyto strategie vychází ze zkušeností 

získaných z průmyslu, z jiných vojenských aplikací a z nejlepších současných postupů 

v oboru. Standard není určen k podrobnému popisu jak plnit tyto úlohy, ale spíše doporučuje 

návod definující, čemu je třeba se věnovat a co vzít v úvahu, aby užití COTS nebo NDI 

produktů zajistilo potřeby úkolu nebo programu. 

Proces nabývání majetku v resortu MO má oproti ostatním členským státům jistá 

specifika. Jestliže tento standard stanoví odpovědnosti nebo pravomoci Integrovanému týmu 

pro produkt, v ČR (v rámci resortu MO) přebírá jeho pravomoci Projektový tým, jehož 

složení a kompetence jasně stanoví interní normativní akty resortu MO. 

Vzhledem k předpisu Všeob-P-4 „Hospodaření s majetkem v resortu Ministerstva 

obrany“ je v textu standardu jednotně používán pojem „pořizování majetku“ jako ekvivalent 

k pojmu „nakupování majetku“ nebo „nabývání majetku“. Pak také pojem „komerčně 

nakupovaný materiál (COTS)“, který civilní sektor zná ze systému norem ISO, EN a IEC, má 

v souvislosti s předpisem jednoznačný ekvivalent v pojmu „komerčně pořizovaný majetek“. 

Protože je tento standard určen jak pro resort MO, tak pro civilní sektor, je přípustné 

používání obou pojmů. 

V případě nejasností nebo nesrovnalostí v českém textu tohoto standardu má smluvní 

platnost příslušné ustanovení v anglickém jazyce. 

2 Nahrazení standardů (norem) 

Tento standard nenahrazuje žádnou v ČR doposud platnou normu nebo standard. 

3 Souvisící citované dokumenty 

STANAG 4597, Ed. 1 

ANEP-54, Ed. 1 

AAP-48, Ed. 1 

OBSOLESCENCE MANAGEMENT 

Proces zastarávání 

OBSOLESCENCE MANAGEMENT 

Směrnice pro vložení volně obchodovatelného výrobku 

NATO SYSTÉM LIFE CYCLE STAGES AND PROCESSES 

Etapy a procesy životního cyklu systémů v NATO 

Následující dokumenty byly vybrány z vojenských organizací NATO, USA a Velké 

Británie a definují nejlepší postupy, které jsou v současnosti v tomto oboru k dispozici. Pro 

pořizování majetku a služeb do resortu MO ČR se však jejich použití nedoporučuje. 

NAVSEAINST 9083.1 Commercial Off the Shelf Policy 

6


1. vydání 

Oprava 1 

US Navy Handbook: Naval Sea Systems Command Commercial Off-The-Shelf and Non- 

Developmental Items Handbook 

UK MOD #1 - Guidance On Off The Shelf Procurement 

UK MOD D/DCSSM/816/115/3/4/19 ISSUEE 1.0 of 16 MARCH 1999: Supporting 

Document to IPT Guide Note on Off The Shelf Procurement 

UK MOD D/DUWS/816/115/3/4/19 Issue 1.0 of 31 January 2000: Through Life Management Of 

COTS-Based Systems 

U odkazů, v nichž je uveden rok vydání standardu (nebo normy), platí tento standard 

(nebo norma) bez ohledu na to, zda existují jeho novější vydání. U odkazů na dokument bez 

uvedení data jeho vydání platí vždy poslední vydání citovaného dokumentu. Jestliže se text 

tohoto ČOS odvolává na normu ISO, je možno použít i příslušnou normu, která byla v ČR 

harmonizována, tedy např. ČSN EN, ČSN EN ISO, ČSN ISO apod. 

4 Zpracovatel ČOS 

VOP-026 Šternberk, s.p., divize VTÚO Brno, RNDr. Milan Čepera, Ph.D. 

5 Použité zkratky, značky a definice 

5.1 Zkratky 

Zkratka Český význam Anglický význam 

AMS Ve Velké Británii: Systém pro Acquisition Management System 

management akvizičního procesu 

C3I 

systems 

Systémy velení, řízení, spojení 

a zpravodajské systémy 

Command, Control, Communications 

& Intelligence systems 

CI Položka konfigurace Configuration Item 

CM Management konfigurací Configuration Management 

CLS Logistické zabezpečení prováděné Contractor Logistic Support 

dodavatelem 

COTS Komerčně nakupovaný materiál, COTS Commercial Off-The-Shelf 

komerčně pořizovaný majetek 

ČOS Český obranný standard --- 

CSCI Softwarová položka konfigurace Software Configuration Item 

DMS Systém pro řízení dat Data Management System 

EMC Elektromagnetická kompatibilita Electromagnetic Compatibility 

EMI Elektromagnetické rušení Electromagnetic Interference 

FCA Funkční audit (přezkoumání) Functional Configuration Audit 

konfigurace 

HTML Značkovací jazyk pro hypertext HyperText Markup Language 

HWCI Hardwarová položka konfigurace Hardware Configuration Item 

7


1. vydání 

Oprava 1 

ILS Integrované logistické zabezpečení Integrated Logistic Support 

IPT Integrovaný tým pro produkt Integrated Product Team 

ISD Datum uvedení do provozu In-Service Date 

IT Informační technologie Information Technology 

MOTS Materiál nakupovaný komerčně pro Military Qualified Off the Shelf 

vojenské účely 

MTBF Střední doba mezi poruchami Mean Time Between Failure 

NDI Položka bez vývoje Non-Developed Item 

PCA Fyzický audit (prověrka) konfigurace Physical Configuration Audit 

RFP Výzva k podání nabídky Request for Proposal 

SI Softwarová položka Software Item 

TCP/IP Primární transportní protokol / 

protokol síťové vrstvy 

5.2 Definice 

Transmission Control Protocol / 

Internet Protocol 

Dále uvedené definice jsou běžně užívány 

veřejností, která se zabývá akvizicí a technickou 

veřejností. Většina zde obsažených definic se 

běžně uznává, často je však velký zmatek v tom, 

co je skutečně COTS položkou. Rozsáhlé 

pojednání o definici COTS je mimo rozsah 

tohoto dokumentu. Zde obsažená definice je 

nejpřijatelnější. 

Akvizice 

Smluvní nabývání majetku nebo služeb (to 

zahrnuje i stavby) státní správou a pro potřeby 

státní správy, s patřičnými finančními prostředky, 

a to formou pořízení nebo leasingu 1 , ať 

už dodávky nebo služby existují, nebo se musí 

vytvořit, vyvinout, demonstrovat a vyhodnotit. 

Akvizice začíná v okamžiku, kdy jsou stanoveny 

potřeby organizace (orgánu) a ty obsahují popis 

požadavků, které vyhovují potřebám organizace 

(orgánu), popis získávání a volby zdrojů, přidělení 

smlouvy, financování smlouvy, provedení 

smlouvy, řízení smlouvy a popis těch technických 

a manažerských funkcí, které jsou 

v přímém vztahu s procesem smluvního naplňování 

potřeb organizace (orgánu). 

Akvizice systémů 

The following definitions are commonly used 

throughout the acquisition and engineering 

communities. Most of the definitions contained 

herein are normally accepted, however, there is 

often a great deal of confusion over what truly 

constitutes a COTS item. An extensive treatise 

on the definition of COTS is beyond the scope 

of this document. The definition contained is the 

most widely accepted. 

Acquisition 

The acquiring by contract with appropriated 

funds of supplies or services (including 

construction) by and for the use of the Federal 

Government through purchase or lease, whether 

the supplies or services are already in existence 

or must be created, developed, demonstrated, 

and evaluated. Acquisition begins at the point 

when agency needs are established and includes 

the description of requirements to satisfy agency 

needs, solicitation and selection of sources, 

award of contracts, contract financing, contract 

performance, contract administration, and those 

technical and management functions directly 

related to the process of fulfilling agency needs 

by contract. 

Systems Acquisition 

1 Tato definice je záměrně natolik obecná, aby ji bylo možno použít i pro mezinárodní akvizici majetku a služeb. 

V ČR totiž podle odst. (8) § 12 zákona č. 219/2000 Sb. o majetku České republiky a jejím vystupování 

v právních vztazích, organizační složky státu nemohou uzavírat smlouvu o poskytnutí věci, bytu nebo 

nebytového prostoru do užívání spojenou se smlouvou o následném převodu této věci do vlastnictví státu. 

8

Návrh, vývoj a výroba nového systémů. Také 

zahrnuje modifikace existujících systémů, což 

vyžaduje nový návrh systému nebo podsystémů. 

Architektura 

Organizační struktura systému nebo součásti, 

jejich vzájemné vztahy a principy a návody 

řídicí jejich návrh a rozvoj v průběhu času. 

(IEEE 610.12) 

Balení 

Proces a postupy užívané k ochraně materiálu. 

Zahrnuje čištění, sušení, konzervaci, balení, 

značení a užití. 

Balení, manipulace, skladování a doprava 

Zdroje, procesy, postupy, zřetele návrhu 

a metody k zajištění, že úplný systém, zařízení 

a položky zabezpečení jsou vhodně baleny, 

manipulovány, skladovány a dopravovány. To 

zahrnuje i ohledy na prostředí, požadavky na 

konzervaci zařízení pro krátkodobé i dlouhodobé 

skladování a dopravitelnost. Je to jeden 

z tradičních prvků logistického zabezpečení. 

Bezporuchovost 

Schopnost systému a jeho částí vykonávat svůj 

úkol bez poruchy, degradace nebo nároků na 

podpůrný systém (viz Střední doba mezi 

poruchami – MTBF). 

Černá skříňka 

Popisuje součást, jejíž chování může být zjištěno 

pouze zkoumáním vstupů a odpovídajících 

výstupů. Vnitřní konstrukční charakteristiky 

nejsou známy ani uživateli, ani osobě provádějící 

analýzu. 

Databáze LSA (LSAR) 

Datová tabulka zachycující výsledky analýzy 

zajišťování dodávek a služeb nezbytných u materiálu 

pro udržování připravenosti k provozu. 

Dodavatel 

Organizace, která vstupuje do smlouvy se 

zákazníkem za účelem dodávky systému, 

produktu nebo služby, za podmínek uvedených 

ve smlouvě. 


1. vydání 

Oprava 1 

The design, development, and production of new 

systems. It also includes modifications to 

existing systems that involve redesign of the 

system or subsystems. 

Architecture 

The organizational structure of a system or 

component, their relationships, and the 

principles and guidelines governing their design 

and evolution over time. (IEEE 610.12) 

Packaging 

The process and procedures used to protect 

material. It includes cleaning, drying, 

preserving, packaging, marking, and utilization. 

Packing, Handling, Storage, and 

Transportation 

The resources, processes, procedures, design 

considerations, and methods to ensure all 

system, equipment, and support items are 

preserved, packaged, handled, and transported 

properly. This includes environmental 

considerations, equipment preservation 

requirements for short-and long-term storage, 

and transportability. One of the traditional 

logistic support (LS) elements. 

Reliability 

The ability of a system and its parts to perform 

its mission without failure, degradation, or 

demand on the support system. (See Mean Time 

Between Failures (MTBF).) 

Black box 

Describes a component whose behavior can only 

be determined by studying its inputs and related 

outputs. The internal design characteristics are 

unknown to the user or analyst. 

Logistic Support Analysis Record (LSAR) 

A data table recording the results of the analysis 

of the provision of supplies and services 

necessary for maintaining materiel readiness. 

Supplier 

An organization that enters into a contract with 

the customer for the supply of a system, product 

or service under the terms of that contract. 

9


1. vydání 

Oprava 1 

Dokumentace softwaru 

Informace o technických datech, včetně 

počítačových výpisů a výtisků, které 

dokumentují požadavky, návrh nebo podrobnosti 

o počítačovém softwaru, vysvětlují schopnosti 

a omezení softwaru, nebo poskytují provozní 

instrukce pro používání nebo podporu softwaru 

během jeho provozního života. 

Elektromagnetické rušení (EMI) 

Elektromagnetické rušení představuje zhoršení 

užitečného elektromagnetického signálu 

způsobené elektromagnetickou poruchou. 

Elektromagnetický impulz (EMP) 

EMP je velmi krátký impulz vysoce intenzivní 

elektromagnetické energie, který je příznačný 

pro jaderný výbuch. Je charakterizován velmi 

krátkou dobou náběhu (10 ns), vysokou špičkou 

intenzity pole (50 kV/m) a krátkou dobou trvání 

(250 ns). Největší část energie se koncentruje na 

kmitočtech nižších než 10 MHz, kde převládají 

účinky magnetického pole. 

Elektronická příručka pro vojenskou 

akvizici 2 

Automatizovaný referenční nástroj podporovaný 

kanceláří náměstka ministra obrany (v USA) pro 

akvizici a technologie na pomoc při zavádění 

ministerských programů. Skládá se z www 

stránky s vývěskou, obsahuje informační 

strukturu pro hledání libovolných informací 

a odkazovou knihovnu právních a zákonných 

směrnic. Informační struktura a odkazová 

knihovna jsou dostupné z libovolného 

komerčního webového prohlížeče a pro domácí 

použití je dostupná pomocí předplaceného CD. 

Etapa akvizice 

Všechny úlohy a činnosti v průběhu etapy 

akvizice potřebné k tomu, aby přivedly program 

k dalšímu hlavnímu milníku. V etapách jsou 

poskytovány logické nástroje, které postupně 

překládají všeobecně uvedené potřeby úkolu do 

přesně stanovených, pro systém specifických 

požadavků a hlavně do provozně efektivních 

a použitelných systémů schopných přežití. 

Příkladem etapy akvizice může být definice 

programu a snižování rizik. 

Computer Software Documentation 

Technical data information, including computer 

listings and printouts, which documents the 

requirements, design, or details of computer 

software, explains the capabilities and 

limitations of the software, or provides operation 

instructions for using or supporting computer 

software during the software’s operational life. 

Electromagnetic Interference (EMI) 

EMI is an impairment of a wanted 

electromagnetic signal by an electromagnetic 

disturbance. 

Electromagnetic Pulse (EMP) 

EMP is a very short burst of highly intense 

electromagnetic energy typically produced by 

nuclear detonations. It is characterized by a very 

short (10 nsec) risetime, high peak field intensity 

(50 kV/m), and a short duration (250nsec). Most 

of the energy is concentrated at frequencies 

below 10 MHz, where magnetic field effects 

predominate. 

Defense Acquisition Deskbook 

An automated reference tool sponsored by the 

Office of the Under Secretary of Defense 

(Acquisition and Technology) (OUSD(A&T)) to 

assist program offices in implementing DoDD 

5000.1 and DoD 5000.2-R. It consists of a 

World Wide Web (www) home page with a 

bulletin board, an information structure of 

discretionary information, and a reference 

library of statutory and regulatory guidance. The 

information structure and reference library may 

be accessed through commercially available web 

browsers, and are available by CD subscription 

from the home page location. 

Acquisition Phase 

All the tasks and activities needed to bring the 

program to the next major milestone occur 

during an acquisition phase. Phases provide a 

logical means of progressively translating 

broadly stated mission needs into well-defined 

system-specific requirements and ultimately into 

operationally effective, suitable, and survivable 

systems. An example of an acquisition phase is 

Program Definition and Risk Reduction. 

2 Jedná se o dokument používaný v USA, nepoužívá se v ČR. V případě zájmu je tato příručka dostupná na: 

http://web2.deskbook.osd.mil/jsp/default.jsp 

10

Firmware 

Firmware 


1. vydání 

Oprava 1 

Kombinace hardwarového zařízení a počítačových 

instrukcí nebo dat, která jsou zavedena 

v hardwarovém zařízení jako software „pouze 

pro čtení“. Tento software nelze snadno modifikovat 

programovým řízením. 

Funkční audit konfigurace (FCA) 

Oficiální přezkoušení funkčních charakteristik 

položky konfigurace, prokázaných údaji 

o zkoušce, sloužící k ověření, že u položky bylo 

před jejím schválením dosaženo technických 

parametrů specifikovaných funkční nebo 

určenou základní úrovní konfigurace. 

Fyzický audit konfigurace (PCA) 

Oficiální přezkoušení, které ověřuje, zda 

položky konfigurace v daném vytvořeném stavu 

vyhovují technické dokumentaci, jež je definuje. 

Schválení specifikace položky v rámci produktu 

státním úřadem odpovídajícím za program a 

uspokojivé završení tohoto auditu ustanovuje 

základní úroveň produktu. Může být provedena 

na prvním vyrobeném kusu nebo na prvním výrobku 

ověřovací série (nebo zkušební výroby). 

Hardware 

Fyzická součást systému společně s příslušnými 

daty a dokumentací. 

Hlavní dodavatel 

Dodavatel s odpovědností za řízení návrhu 

a/nebo dodávání systému/zařízení jako je 

letadlo, motory, lodě, tanky, vozidla, zbraně 

a řízené střely, pozemní komunikační 

a elektronické systémy a testovací zařízení. 

Informační technologie (IT) 

Jakékoliv zařízení nebo propojený systém nebo 

podsystém zařízení, který je používán pro 

automatickou akvizici, ukládání, manipulaci, 

management, přesun, řízení, zobrazování, 

přepínání, výměnu, přenos nebo příjem dat nebo 

informací výkonným orgánem. IT zahrnuje 

počítače, pomocná zařízení, software, firmware 

a obdobné postupy, služby a odpovídající zdroje. 

Integrátor 

Integrátor, jak je míněn v tomto ČOS, odpovídá 

skupině odpovědné za integraci komerčního 

produktu do funkční vojenské jednotky. Touto 

jednotkou může být kompletní systém nebo část 

systému (podsystém). 

The combination of a hardware device and 

computer instructions or computer data that 

reside as read-only software on the hardware 

device. The software cannot be readily modified 

under program control. 

Functional Configuration Audit (FCA) 

The formal examination of the functional 

characteristics of a configuration item (CI) as 

demonstrated by test data to verify that the item 

has achieved the performance specified in its 

functional or allocated configuration prior to 

acceptance. 

Physical Configuration Audit (PCA) 

Physical examination to verify that the 

configuration item(s) (CIs) "as built" conform to 

the technical documentation which defines the 

item. Approval by the government program 

office of the CI product specification and 

satisfactory completion of this audit establishes 

the product baseline. May be conducted on first 

full production or first low rate initial production 

(LRIP) item. 

Hardware 

The physical components of a system, including 

associated data and documentation. 

Prime Contractor 

A contractor having responsibility for design 

control and/or delivery of a system/equipment 

such as aircraft, engines, ships, tanks, vehicles, 

guns and missiles, ground communications and 

electronics systems, and test equipment. 

Information Technology (IT) 

Any equipment or interconnected system or 

subsystem of equipment that is used in the 

automatic acquisition, storage, manipulation, 

management, movement, control, display, 

switching, interchange, transmission, or 

reception of data or information by an executive 

agency. IT includes computers, ancillary 

equipment, software, firmware and similar 

procedures, services and related resources. 

Integrator 

The integrator as mentioned within this 

document refers to the party responsible for 

integrating commercial products into a 

functional military unit. This unit may be a 

complete system or a subset of a system 

(subsystem). 

11


1. vydání 

Oprava 1 

Integrované logistické zabezpečení (ILS) 

Na vědecké bázi založený přístup 

k managementu, ovlivňovaný jak zákazníkem, 

tak průmyslem, jehož cílem je optimalizace 

úplných nákladů životního cyklu (WLC) zařízení. 

Zahrnuje prvky pro ovlivňování návrhu 

zařízení a určení požadavků na zabezpečení, 

pomocí nichž bude dosaženo zabezpečovatelného 

a zabezpečeného zařízení. 

Integrovaný obvod specifický pro aplikaci 

(ASIC) 

Jakýkoliv integrovaný obvod, jehož fyzický 

návrh je upravován podle přání uživatele nebo 

osoby, která jej zastupuje. Opačným pojmem je 

„standardní produkt“, který odpovídá zařízením, 

jejichž fyzický návrh je stanoven dodavatelem. 

Integrovaný tým pro produkt 

Tým složený z představitelů příslušných 

funkčních disciplin, kteří spolupracují, aby 

vytvořili úspěšné programy, identifikovali 

a řešili problémy a vytvářeli řádná a včasná 

doporučení usnadňující rozhodování. Existují tři 

druhy IPT: překlenovací IPT (OIPT) se soustředí 

na strategické vedení, posuzování programu 

a řešení problémů, IPT na pracovní úrovni 

(WIPT) identifikuje a řeší problémy programu, 

určuje stav programu a vyhledává možnosti pro 

zlepšování akvizice, a IPT na úrovni programu 

se zaměřuje na realizaci programu a může 

zahrnovat jak představitele státu, tak i představitele 

průmyslu plnící zadání zakázky. 

Interoperabilita 3 

Schopnost systémů, jednotek nebo sil 

poskytovat nebo přijímat služby od jiných 

systémů, jednotek nebo sil a takto vyměňované 

služby využívat pro vzájemný efektivní provoz. 

Jedná se podmínky dosažené mezi 

komunikačně-elektronickými systémy nebo 

položkami komunikačně-elektronických zařízení 

v případě, kdy mezi nimi a/nebo jejich uživateli 

mohou být přímo a uspokojivě vyměňovány 

informace nebo služby. 

Jednotka vyměnitelná na místě (LRU) 

Základní zabezpečovací jednotka demontovaná 

a nahrazovaná na polním stupni opravy pro 

Integrated Logistic Support (ILS) 

A disciplined management approach, affecting 

both customer and industry, aimed at optimizing 

equipment Whole Life Costs (WLC). It includes 

elements for influencing equipment design and 

determining support requirements to achieve 

supportable and supported equipment. 

Application Specific Integrated Circuit 

(ASIC) 

Any integrated circuit whose physical design is 

customized by or on behalf of the user. The 

contrasting term ‘standard product’ refers to 

devices whose physical design is fixed by the 

supplier. 

Integrated Product Team (IPT) 

Team composed of representatives from 

appropriate functional disciplines working 

together to build successful programs, identify 

and resolve issues, and make sound and timely 

recommendations to facilitate decision making. 

There are three types of IPTs: overarching IPTs 

(OIPTs) focus on strategic guidance, program 

assessment, and issue resolution; working level 

IPTs (WIPTs) identify and resolve program 

issues, determine program status, and seek 

opportunities for acquisition reform; and 

program level IPTs focus on program execution 

and may include representatives from both 

government and after contract award industry. 

Interoperability 

The ability of systems, units, or forces to provide 

services to or accept services from other 

systems, units, or forces and to use the services 

so exchanged to operate effectively together. 

The conditions achieved among 

communications-electronics systems or items of 

communications-electronics equipment when 

information or services can be exchanged 

directly and satisfactorily between them and/or 

their users. 

Line Replaceable Unit (LRU) 

An essential support item removed and replaced 

at field level to restore an end item to an 

3 Tato definice je zastaralá. V současné době (podle verze AAP-6:2007) platí tato definice: 

Interoperabilita je schopnost působit ve vzájemné podpoře při plnění stanovených úkolů. (Interoperability = 

The ability to operate in synergy in the execution of assigned tasks.) 

12

obnovení konečné položky do podmínek 

připravenosti k provozu. (Také se nazývá 

Vyměnitelná zbraňová sestava a Vyměnitelný 

modul). 

Komerčně nakupovaný materiál (Komerčně 

pořizovaný majetek) 

Komerční položka, která pro splnění potřeb 

orgánu pro pořizování nevyžaduje zvláštní 

státem řízené modifikace nebo údržbu v průběhu 

celého životního cyklu. 

Komerční položka 

Komerční položka je jakákoliv položka jiná než 

nemovitý majetek, která: 

- je obvykle používána pro účely mimo státní 

správu, a která byla prodána, pronajata nebo 

licencována pro širokou veřejnost, 

- je poskytována pro prodej, pronájem nebo 

licenci široké veřejnosti, 

- je vyvinuta díky pokroku technologie nebo 

technických parametrů a která není doposud 

na komerčním trhu dostupná, ale bude na 

trhu dostupná včas, aby uspokojila 

požadavky na dodání, které uplatnil stát. 

V této definici jsou také zahrnuty služby 

zabezpečení komerční položky, a to takového 

druhu, který je ve značném objemu nabízen 

a prodáván na komerčním trhu na základě 

zavedeného katalogu nebo na základě tržních 

cen určených pro speciální úlohy prováděné za 

standardních komerčních termínů a podmínek. 

Definice nezahrnuje služby, které jsou 

prodávány na základě hodinové sazby bez 

zavedených katalogů nebo tržních cen určených 

pro prováděné speciální úlohy. 

Kritické přezkoumání návrhu (CDR) 

Přezkoumání, které může být prováděno za 

účelem zjištění, zda podrobnosti návrhu vyhovují 

technickým a výkonnostním požadavkům, 

uvedeným ve vývojové specifikaci. Může být 

prováděno také za účelem potvrzení 

kompatibility podrobností návrhu mezi položkou 

a ostatními položkami zařízení, vybavením, 

počítačovými programy a obsluhou nebo za 

účelem posouzení vyrobitelnosti a rizikových 

oblastí, nebo také za účelem přezkoumání specifikací 

předběžné základní výrobní úrovně. 

Normálně se provádí během etapy II - technický 

a výrobní vývoj. 


1. vydání 

Oprava 1 

operationally ready condition. (Also called 

Weapon Replacement Assembly and Module 

Replaceable Unit.) 

Commercial Off-The-Shelf 

Commercial items that require no unique 

government modifications or maintenance over 

the life cycle of the product to meet the needs of 

the procuring agency. 

Commercial Item 

A commercial item is: 

- any item, other than real property, that is of 

a type customarily used for nongovernmental 

purposes and that has been 

sold, leased, or licensed to the general 

public; 

- has been offered for sale, lease, or license to 

the general public; 

- any item evolved through advances in 

technology or performance and that is not 

yet available in the commercial marketplace, 

but will be available in the commercial 

marketplace in time to satisfy the delivery 

requirements under a government 

solicitation. 

Also included in this definition are services in 

support of a commercial item, of a type offered 

and sold competitively in substantial quantities 

in the commercial marketplace based on 

established catalog or market prices for specific 

tasks performed under standard commercial 

terms and conditions; this does not include 

services that are sold based on hourly rates 

without an established catalog or market price 

for a specified service performed. 

Critical Design Review (CDR) 

A review that may be conducted to determine 

that the detailed design satisfies the performance 

and engineering requirements of the 

development specification; to establish the 

detailed design compatibility among the item 

and other items of equipment, facilities, 

computer programs, and personnel; to assess 

producibility and risk areas; and to review the 

preliminary product baseline specifications. 

Normally conducted during Phase II, 

Engineering and Manufacturing Development 

(EMD). 

13


1. vydání 

Oprava 1 

Manažer projektu 

Jedinec, jemuž byla přiřazena odpovědnost za 

veškerý management technických, časových, 

nákladových a jakostních hledisek projektu nebo 

skupiny projektů a pro něhož tyto hlediska 

znamenají motivaci. 

Materiál 4 (Výzbroj a technika) 

Všeobecný pojem zahrnující systémy, zařízení, 

zásoby, dodávky a náhradní díly včetně 

příslušné dokumentace, manuálů, softwaru 

a firmwaru. 

Mód asynchronního přenosu 

Mód asynchronního přenosu (ATM) je způsob 

rychlého přepínání paketů, který umožňuje 

datům přenos v širokém pásmu ISDN (digitální 

síť integrovaných služeb). Širokopásmová ISDN 

je mnohem rychlejší formou digitální 

komunikace než standardní ISDN. Využívá 

k dodávání služeb kabely s optickými vlákny 

s rychlostí přenosu mnohem větší než 150 Mb/s. 

Nakonec nahradí ISDN služby dodávané pomocí 

měděných vodičů. ATM přenáší informace 

v paketech, zvaných buňky, s pevnou délkou 

obsahující 48 bytů uživatelských informací a 5 

bytovou hlavičku. Mezi dvěma nebo více 

stanicemi, které přistoupí ke komunikaci, se 

sestaví virtuální obvod. Buňky ATM jsou pak 

přeneseny pomocí ATM sítě od zdroje 

k cílovému umístění. ATM může přenášet 

veškeré komunikační aplikace včetně dat, hlasu, 

obrázků a videa. Pokud se používají buňky 

s malou fixní délkou, umožňuje ATM rychlé 

přepínání paketů jako alternativu 

k asynchronnímu i synchronnímu přenosu. 

Model 

Model je prezentací skutečného systému nebo 

koncepce, který zahrnuje matematické, logické 

výrazy nebo počítačové simulace, které je 

možno použít k předpovědi, jak by mohl systém 

fungovat nebo vydržet za rozličných podmínek 

nebo v řadě nepříznivých prostředí. 

Model technického vývoje (EDM) 

Project Manager 

The individual to whom responsibility has been 

assigned for the overall management of 

technical, time, cost and quality aspects of a 

project, or group of projects, and the motivation 

of those involved. 

Materiel 

A generic term covering systems, equipment, 

stores, supplies and spares and including related 

documentation, manuals, computer software and 

firmware. 

Asynchronous Transfer Mode 

Asynchronous Transfer Mode (ATM) is a form 

of fast-packet switching that allows for data 

transmission via broadband (Integrated Services 

Digital Network) ISDN. Broadband ISDN is a 

much faster form of digital communication than 

standard ISDN. It uses fibre optic cabling to 

deliver services with transmission rates of more 

than 150 Mbps. It will eventually replace the 

ISDN service delivered via copper wiring. ATM 

carries information in fixed length packets called 

cells, each containing 48 bytes of user 

information and 5 bytes of header. The total cell 

is therefore 53 bytes. A virtual circuit is set up 

between two or more stations, which agree to 

communicate. ATM cells are then transferred 

through the ATM network from source to 

destination. ATM can transport all 

communications applications including data, 

voice, imaging, and video. In using small fixed 

length cells, ATM provides a fast-packet 

switching alternative to asynchronous 

transmission and synchronous transmission. 

Model 

A model is a representation of an actual or 

conceptual system that involves mathematics, 

logical expressions, or computer simulations that 

can be used to predict how the system might 

perform or survive under various conditions or 

in a range of hostile environments. 

Engineering Development Model (EDM) 

4 Jestliže se v tomto ČOS hovoří o materiálu, pak v prostředí ČR je tento pojem totožný s pojmem „dodávky“ ve 

shodě s terminologii zákona č. 137/2006 Sb., o veřejných zakázkách. Pojem „vojenský materiál“ je vymezen 

v zákoně č. 219/1999 Sb., o ozbrojených silách České republiky, jako souhrn vojenské výstroje, vojenské 

výzbroje, vojenské techniky a určených technických zařízení, které ozbrojené síly používají k zabezpečení 

výcviku a plnění svých úkolů. Jedná se o předpis, který je aplikovatelný pouze uvnitř armády. Jakmile je 

vojenský materiál převeden z majetku státu (Ministerstva obrany) na třetí (civilní) osobu, ztrácí status 

vojenského materiálu a řídí se jinou právní úpravou – např. zbraně přejdou do režimu zákona o zbraních. 

14

Systém představující výrobu, který může být 

používán během etapy technického a výrobního 

vývoje (EMD) pro řešení nedostatků návrhu, 

prokazování dozrávajících technických 

parametrů a rozpracování navržených výrobních 

specifikací a výkresů. Může být též použit pro 

vstupní testování a hodnocení provozu. 

Modifikovaná komerční položka 

„Modifikovaná komerční položka je jakákoliv 

položka, jejíž typová modifikace (obvykle 

dostupná na komerčním trhu) nebo jejíž menší 

typová modifikace (obvykle nedostupná na 

komerčním trhu) je vyrobena tak, že splňuje 

požadavky státu. Za menší modifikaci se 

považuje taková, kdy změna významně nemění 

funkci nebo základní fyzikální charakteristiky 

při běžném použití položky nebo součásti nebo 

nemění účel procesu.“ 

Náchylnost 

Míra otevřenosti systému, zařízení nebo 

zbraňového systému vůči účinnému útoku, 

způsobená jednou nebo více vnitřními slabými 

stránkami. Náchylnost je funkcí operační 

taktiky, protiopatření, pravděpodobnosti 

nepřátelské hrozby atd. Náchylnost se považuje 

za součást schopnosti přežití. 

Náklady jako nezávislá proměnná (CAIV) 

Metodika užívaná resortem MO k akvizici 

a provozování cenově dostupných systémů 

pomocí nastavení smělých a dosažitelných cílů 

pro náklady životního cyklu a pomocí řízení 

dosahování těchto cílů prováděním analýz 

optimalizace nákladů a přínosů a časových plánů 

podle potřeby. Cíle pro náklady dávají do 

rovnováhy potřeby úkolu s projektovanými 

zdroji financování tak, že berou v úvahu jak 

resortem, tak průmyslem předpokládané procesy 

zlepšování. CAIV staví do popředí odpovědnosti 

státu za nastavení/přizpůsobení cílů pro náklady 

životního cyklu a za vyhodnocení požadavků 

v rámci celkových požadavků na náklady. 

Náklady životního cyklu 

Celkové náklady státu na pořízení, provozování, 

zabezpečení a (je-li to třeba) vyřazení položek, 

které se pořizují. 

Návrh na technickou změnu (ECP) 

Návrh, který směřuje k odpovědnému orgánu, 

doporučující, aby se vzala v úvahu změna 


1. vydání 

Oprava 1 

A production representative system that may be 

used during the Engineering and Manufacturing 

Development (EMD) phase to resolve design 

deficiencies, demonstrate maturing performance, 

and develop proposed production specifications 

and drawings. May also be used for initial 

operational test and evaluation (IOT&E) 

Modified Commercial Item 

“A modified commercial item is any item with 

modifications of a type customarily available in 

the commercial marketplace or minor 

modifications of a type not customarily available 

in the commercial marketplace made to meet 

Federal Government requirements. Such 

modifications are considered minor if the change 

does not significantly alter the non-government 

function or essential physical characteristics of 

an item or component, or change the purpose of 

the process.” 

Susceptibility 

The degree to which a device, equipment, or 

weapon system is open to effective attack due to 

one or more inherent weaknesses. Susceptibility 

is a function of operational tactics, 

countermeasures, probability of enemy fielding a 

threat, etc. Susceptibility is considered a subset 

of survivability. 

Cost as An Independent Variable (CAIV) 

Methodologies used to acquire and operate 

affordable DoD systems by setting aggressive, 

achievable life cycle cost objectives, and 

managing achievement of these objectives by 

trading off performance and schedule, as 

necessary. Cost objectives balance mission 

needs with projected out-year resources, taking 

into account anticipated process improvements 

in both DoD and industry. CAIV has brought 

attention to the government’s responsibilities for 

setting/adjusting life-cycle cost objectives and 

for evaluating requirements in terms of overall 

cost consequences. 

Life-cycle cost 

The total cost to the Government of acquiring, 

operating, supporting, and (if applicable) 

disposing of the items being acquired. 

Engineering Change Proposal (ECP) 

A proposal to the responsible authority 

recommending that a change to an original item 

15


1. vydání 

Oprava 1 

původní položky v zařízení a aby byly návrh 

nebo technická změna včleněny do zboží 

z důvodu modifikace, přidání, odstranění nebo 

nahrazení původních součástek. 

Objektově orientovaný návrh 

Objektově orientovaný návrh je metodou jak 

vytvářet architektury softwaru založené na tom, 

jak každý systém nebo podsystém pracuje 

s objekty (spíše než funkce je míněno zajištění). 

Obecný návod pro objektově orientovaný návrh 

zahrnuje následující problémy: 

Jak popsat objekty. 

Jak popsat vztahy a společné rysy objektů. 

Jak vyhledávat objekty. 

Jak využít objekty ke strukturování programů. 

Odolnost vůči vnějšímu prostředí 

Míra zátěže prostředím, při níž může produkt 

fungovat a která se opírá o balení produktu 

a/nebo jeho vnitřní charakteristiky nebo balení, 

pokud je v uložené konfiguraci. 

Opatřování (zásob) 

Proces stanovení a získání rozsahu a množství 

náhradních dílů a součástí pro opravy a podpůrných 

a testovacích zařízení požadovaných 

k provozu a údržbě koncové položky materiálu 

v počátečním období provozování. 

Opětovné použití softwaru 

Proces implementace nebo modernizace 

softwarových systémů za použití výhod 

existujícího softwaru. 

Orgán odpovědný za návrh 

Schválené firmy, instituce nebo průmyslové 

odvětví, které jsou podle podmínek smlouvy 

nebo podle jiné oficiální dohody odpovědné za 

všechna hlediska návrhu systému, podsystému 

nebo položky v zařízení ve vazbě na schválenou 

specifikaci, a které jsou oprávněny osvědčit 

návrh nebo potvrdit výkres. 

Otevřené standardy 

Široce přijímané a podporované soubory standardů 

uznávané standardizačními organizacemi 

nebo trhy. Pomocí těchto standardů se zabezpečuje 

interoperabilita, přenositelnost a rozšiřitelnost 

a jsou rovnocenně dostupné široké 

veřejnosti bez poplatků nebo jen za mírný 

licenční poplatek. 

of equipment be considered, and the design or 

engineering change be incorporated into the 

article to modify, add to, delete, or supersede 

original parts. 

Object Oriented Design 

Object-oriented design is the method that leads 

to software architectures based on the objects 

every system or subsystem manipulates (rather 

than the function it is meant to ensure). A 

general guideline for object-oriented design 

includes the following issues: 

How to describe the objects 

How to describe the relations and commonality 

between objects 

How to find the objects 

How to use objects to structure programs 

Environmental Hardness 

The measure of environmental stress that a 

product can function under based on it’s 

packaging and/or inherent characteristics or 

packaging when in a stowed configuration. 

Provisioning 

The process of determining and acquiring the 

range and quantity (depth) of spare and repair 

parts, and support and test equipment required to 

operate and maintain an end item of materiel for 

an initial period of service. 

Software Reuse 

The process of implementing or updating 

software systems using existing software assets. 

Design Authority 

The approved firm, establishment or branch 

responsible within the terms of the contract or 

other formal agreement for all aspects of the 

design of a system, sub-system or item of 

equipment to approved specifications, and 

authorized to sign a certificate of design or to 

certify drawings. 

Open Standards 

Widely accepted and supported standards set by 

recognized standards organizations or the market 

place. These standards support interoperability, 

portability, and scalability and are equally 

available to the general public at no cost or with 

a moderate license fee. 

16

Otevřený systém 

Systém, který zavádí specifikace udržované 

pomocí otevřeného, veřejně uznávaného procesu 

pro rozhraní, služby a formy podpory, který 

umožňuje napříč širokým spektrem systémů 

využívat s minimální změnou vhodně 

zkonstruované součásti, který je v součinnosti 

s dalšími součástmi místních i vzdálených 

systémů a působí na uživatele způsobem, který 

usnadňuje přenositelnost. 

Plán managementu průběhu životního cyklu 

Tento plán spojuje dohromady tři klíčová témata 

efektivní akvizice: projektové týmy, systémové 

inženýrství a komerční postupy. Návrh TLMP je 

vytvářen v etapě koncepcí projektu a je 

udržován v průběhu všech etap životního cyklu 

produktu. Ukazuje přesně ty zdroje, které jsou 

potřebné pro splnění cílů projektu a které byly 

uznány všemi zadavateli. 

Plán řízení zastarávání 

Popis strategie pro identifikaci a snižování vlivů 

zastarávání během všech etap života zařízení. 

Plánování údržby 

Proces prováděný k vytvoření a ustanovení 

koncepcí údržby/zabezpečení a požadavků na 

životní cyklus materiálového systému. Jeden 

z tradičních prvků logistického zabezpečení. 

Počítačový software (nebo jen software) 

Kombinace sdružených počítačových instrukcí 

a definicí dat počítače požadovaných, aby 

hardware počítače prováděl výpočtové a řídicí 

funkce. 

Podsestava 

Dvě či více částí spojených dohromady, tvořící 

jednotku schopnou demontáže, která je pouze 

částí celého stroje, struktury nebo jiné části. 

Podsystém 

Kombinace dvou nebo více souvisících zařízení 

(sad) uspořádaných do funkčního balíku, 

určeného k provádění provozních funkcí nebo 

k uspokojení požadavků. 

Posouzení technologie 

Proces aktivního nalézání a řešení problémů 

pohotovosti systému za účelem udržení systému 

v provozu v průběhu jeho života během úkolu. 


1. vydání 

Oprava 1 

Open System 

A system that implements specifications 

maintained by an open, public consensus process 

for interfaces, services, and support formats, to 

enable properly engineered components to be 

utilized across a wide range of systems with 

minimal change, to interoperate with other 

components on local and remote systems, and to 

interact with users in a manner that facilitates 

portability. 

Through Life Management Plan (TLMP) 

The TLMP brings together the three key themes 

of smart acquisition: Project Teams, Systems 

Engineering and commercial practices. An 

outline TLMP is produced in the concept stage 

of a project and is maintained throughout all 

stages of a product's life cycle. It shows the full 

resources needed to meet the objectives of the 

project and is recognized by all stakeholders. 

Obsolescence Management Plan 

A description of the strategies for the 

identification and mitigation of the effects of 

obsolescence through all stages of the life of an 

equipment. 

Maintenance Planning 

The process conducted to evolve and establish 

maintenance/support concepts and requirements 

for the life cycle of a materiel system. One of the 

traditional elements of logistic support (LS). 

Computer Software (or Software) 

A combination of associated computer 

instructions and computer data definitions 

required to enable the computer hardware to 

perform computational or control functions. 

Subassembly 

Two or more parts joined together to form a unit, 

capable of disassembly, which is only a part of a 

complete machine, structure, or other article. 

Sub-system 

A combination of two or more interrelated 

equipment’s (sets) arranged in a functional 

package to perform an operational function or to 

satisfy a requirement. 

Technology Assessment 

The process of pro-actively finding and solving 

availability problems in a system in order to 

keep the system operational over the mission life 

of that system. 

17


1. vydání 

Oprava 1 

Potvrzení o vstupním testování a hodnocení 

provozu (IOT&E) 

Provozní proces, který se provádí u technického 

a řídicího vývoje (EMD), jehož výsledkem je 

prohlášení o připravenosti systému podstoupit 

IOT&E. Proces se může měnit společně 

s poskytovanou službou. 

Pracovní síla a pracovníci 

Proces identifikace a získávání vojenských 

i civilních pracovníků s dovednostmi a kvalifikací 

požadovanými k provozování a zabezpečení 

materiálového systému během jeho života 

v době míru i války. Jeden z tradičních prvků 

logistického zabezpečení. 

Práva k duševnímu vlastnictví (IPR) 

Patenty, designy (registrované i neregistrované), 

registrované obchodní značky a autorská práva 

jsou zákonem definovaná a řízená práva. 

Důvěrné technické informace (obvykle obsažené 

ve zprávách, výkresech, specifikacích nebo 

i datech) a všeobecně „know-how“ zahrnují 

ostatní práva ve smyslu obecného práva. 

Souhrnně jsou tato práva známa jako „práva 

k duševnímu vlastnictví“ (IPR). Ačkoliv jsou 

nehmotné, tvoří druh vlastnictví, mají určitou 

hodnotu a mohou být pořizována, prodávána 

nebo licencována. 

Program jakosti 

Program, který je rozvíjen, plánován a řízen za 

účelem cenově efektivní realizace veškerého 

úsilí, které ovlivňuje kvalitu materiálu a služeb, 

od etapy zkoumání a definice koncepce a přes 

etapu prokazování a validace, etapu technického 

a výrobního vývoje, etapu výroby a nasazení až 

k etapě provozu a vyřazení. 

Prostředí otevřených systémů (OSE) 

Úplný soubor rozhraní, služeb a forem zabezpečení 

včetně hledisek interoperability aplikace, 

jak je specifikován ve standardech a profilech 

pro informační technologie. OSE umožňuje vyvíjet, 

provozovat a udržovat informační systémy 

nezávisle na použití specifických technických 

řešení nebo produktů od prodejců. 

Protokol o cílech programu 5 

Výroční záznam v předepsaném formátu před- 

Certification for Initial Operational Test and 

Evaluation (IOT&E) 

A service process undertaken in the engineering 

and management development (EMD) resulting 

in the announcement of a system’s readiness to 

undergo IOT&E. The process varies with each 

Service. 

Manpower and Personnel 

The process of identifying and acquiring military 

and civilian personnel with the skills and grades 

required to operate and support a materiel 

system over its lifetime at peacetime and 

wartime rates. One of the traditional elements of 

logistic support (LS). 

Intellectual Property Rights (IPR) 

Patents, designs (whether registered or not), 

Registered Trade Marks, and Copyright, are 

rights defined and regulated by statute. 

Confidential technical information (usually in 

reports, drawings, specifications or data), and 

general “know-how”, comprise other rights 

under Common Law. Collectively, such rights 

are known as “Intellectual Property Rights” 

(IPR). Although to an extent intangible, they 

constitute a form of property, possess value and 

can be bought, sold or licensed. 

Quality Program 

A program which is developed, planned, and 

managed to carry out cost-effectively all efforts 

to effect the quality of materials and services 

from concept exploration and definition through 

demonstration and validation, engineering and 

manufacturing development, production and 

deployment, and operations and support. 

Open Systems Environment (OSE) 

A comprehensive set of interfaces, services and 

supporting formats, plus aspects of 

interoperability of application, as specified by 

information technology standards and profiles. 

An OSE enables information systems to be 

developed, operated and maintained independent 

of application specific technical solutions or 

vendor products. 

Program Objectives Memorandum (POM) 

An annual memorandum in prescribed format 

5 Tento pojem se v resortu MO v ČR nepoužívá. 

18

kládaný ministru obrany složkou resortu obrany, 

která odpovídá za řízení součástí, doporučující 

úplné požadavky na zdroje a programy resortu 

ve směrnici na fiskální rok. POM je hlavním 

dokumentem pro plánování, programování 

a financování systému a je základem pro odhady 

financování součástí systému. POM je základním 

programovým dokumentem, který uvádí 

podrobnosti o tom, jak budou navrženy součásti 

systémů, aby odpovídaly ustanovením 

v plánovací dokumentaci resortu MO a vyhovovaly 

stanoveným funkcím v obranných programech 

na příští léta. POM tedy předkládá 

programové potřeby na 5 nebo šest let 

od nynějška (tj. ve fiskálním roce 1994 se 

předkládá POM na léta 1996-2001, ve fiskálním 

roce 1995 na léta 1997-2002), a obsahuje lidské 

zdroje, úrovně sil, pořizování, prostředky 

a výzkum a vývoj (R&M). 

Průzkum produktu 

Průzkumem produktu se rozumí získávání 

informací o produktu poskytovaném prodejcem 

včetně náběhu produktu, ukončení výroby, 

ukončení zabezpečení, stanovení ceny, záruk na 

produkt a informací o profilu společnosti, které 

jsou nezbytné pro určení dat pro zabezpečení 

životního cyklu rozličných produktů. 

Průzkum trhu 

Jedna z etap výzkumu trhu prováděná jako 

odpověď na specifické materiální potřeby nebo 

potřeby služeb. 

Předběžné přezkoumání návrhu 

Přezkoumání prováděné na každé položce 

konfigurace kvůli hodnocení pokroku, technické 

přiměřenosti a rozlišení rizik zvoleného přístupu 

k návrhu, dále kvůli zjištění jeho kompatibility 

s výkonnostními a technickými požadavky 

uvedenými ve vývojové specifikaci a kvůli 

potvrzení existence a kompatibility fyzikálních 

i funkčních rozhraní mezi položkou a dalšími 

položkami zařízení, vybavení, počítačových 

programů a mezi pracovníky. Normálně se 

provádí během počáteční části etapy II: 

Technický a výrobní vývoj. 


1. vydání 

Oprava 1 

submitted to the Secretary of Defense 

(SECDEF) by the DoD component heads which 

recommends the total resource requirements and 

programs within the parameters of SECDEF’s 

fiscal guidance. A major document in the 

planning, programming, and budgeting system 

(PPBS); is POM is the basis for the component 

budget estimates. The POM is the principal 

programming document which details how a 

component proposes to respond to assignments 

in the defense planning guidance (DPG) and 

satisfy its assigned functions of the future years 

defense program (FYDP). The POM shows 

programmed needs for 5 or 6 years hence (i.e., in 

fiscal year (FY) 94, POM 1996-2001 was 

submitted; in FY 95, POM 1997-2001 was 

submitted), and includes manpower, force levels, 

procurement, facilities, and research and 

development (R&D). 

Product Survey 

A product survey is one that obtains information 

about the vendor’s product including start of 

product, end of production, end of support, 

pricing, product warranty, and company profile 

information necessary for determining life cycle 

support data on various products. 

Market Investigation 

A phase of market research conducted in 

response to a specific materiel need or need for 

services. 

Preliminary Design Review (PDR) 

A review conducted on each configuration item 

to evaluate the progress, technical adequacy, and 

risk resolution of the selected design approach; 

to determine its compatibility with performance 

and engineering requirements of the 

development specification; and to establish the 

existence and compatibility of the physical and 

functional interfaces among the item and other 

items of equipment, facilities, computer 

programs, and personnel. Normally conducted 

during the early part of Engineering and 

Manufacturing Development (EMD) Phase II. 

19


1. vydání 

Oprava 1 

Rozhraní aplikačního programu (API) 

Jazyk a formát hlášení používaný aplikačním 

programem pro komunikaci s operačním systémem 

nebo jinými systémovými programy, jako 

je systém řízení báze dat (DBMS). Rozhraní 

aplikačního programu se do programu zavádí 

pomocí psaného volání funkční procedury, které 

poskytne spojení pro vykonání určeného 

podprogramu. Proto se u API předpokládá, že 

k provedení úlohy požadované voláním funkční 

procedury jsou některé programové moduly 

nebo rutiny buď již zavedeny, nebo musí být 

připojeny. 

Rozhraní v návrhu 

Jeden z tradičním prvků logistického zabezpečení 

a jedna z funkcí logistiky. Zahrnuje vztah 

mezi parametry návrhu souvisícími s logistikou 

(jako je bezporuchovost a udržovatelnost) 

a požadavky na připravenost k provozu a na 

zdroje zabezpečení. Tyto parametry návrhu souvisící 

s logistikou jsou vyjádřeny spíše pomocí 

provozních pojmů než vlastními hodnotami 

a jsou výslovně vztaženy k cílům připravenosti 

k provozu systému a k nákladům na zabezpečení 

materiálového systému. 

Schopnost přežití 

Schopnost systému a jeho obsluhy udržet 

v průběhu úkolu v nepříznivém prostředí (ať už 

bojovém nebo mírovém) svoji způsobilost bez 

toho, že dojde k předčasnému poškození jeho 

schopnosti dokončit předem určený úkol. 

Schopnost přežití se skládá ze tří hledisek: snížení 

náchylnosti (což zahrnuje snížení demaskujících 

příznaků, obranné schopnosti zbraní 

a protiopatření), snížení zranitelnosti (což zahrnuje 

minimalizaci vlivů pod vodou nebo vzduchem 

dopravovaných konvenčních, nukleárních 

nebo jiných zbraní) a zvyšování obnovitelnosti 

(včetně řízení poškození, protipožárních činností, 

chemické, biologické a protiradiační 

ochrany a možnosti překonfigurování systémů). 

Sjednocený vývoj produktu a procesu 

(IPPD) 

Manažerský postup, který současně sjednocuje 

všechny nezbytné akviziční činnosti pomocí 

interdisciplinárních týmů, aby byly optimalizovány 

procesy návrhu, výroby a zabezpečení. 

IPPD usnadňuje dosažení cílů v nákladech 

Application Program Interface (API) 

A language and message format used by an 

application program to communicate with the 

operating system or other system program such 

as a database management system (DBMS). 

APIs are implemented by writing function calls 

in the program, which provide the linkage to a 

specific subroutine for execution. Thus, an API 

implies that some program module or routine is 

either already in place or that must be linked in 

to perform the tasks requested by the function 

call. 

Design Interface 

One of the traditional elements of logistics 

support and one of the functions of logistics. 

Involves the relationship of logistics-related 

design parameters, such as reliability and 

maintainability, to readiness and support 

resource requirements. These logistics-related 

design parameters are expressed in operational 

terms rather than inherent values and specifically 

related to system readiness objectives and 

support costs of the materiel system. 

Survivability 

The ability of a system and its crew to retain its 

mission keeping capability in a hostile 

environment, whether combat or peacetime, 

without suffering an abortive impairment of its 

ability to accomplish its designated mission. 

Survivability is composed of three aspects: 

Susceptibility reduction (which includes 

signature reduction, defensive weapons 

capability, and countermeasures), Vulnerability 

reduction (which includes minimization of the 

effects of underwater delivered or air delivered 

conventional, nuclear or other weapons), and 

Recoverability enhancement (including damage 

control, fire fighting, CBR 6 defense, and systems 

reconfigurability). 

Integrated Product and Process Development 

(IPPD) 

A management technique that simultaneously 

integrates all essential acquisition activities 

through the use of multidisciplinary teams to 

optimize the design, manufacturing and 

supportability processes. IPPD facilitates 

6 CBR defense = Chemical, Biological and Radiological defense 

20

i technických parametrech od etapy koncepce, 

přes výrobu včetně zabezpečení v poli. Jedním 

z klíčových principů IPPD je interdisciplinární 

týmová práce umožněná integrovanými týmy 

pro produkt. 

Sledování trhu 

Zahrnuje všechny činnosti, které nepřetržitě 

provádí akviziční pracovníci, aby sami drželi 

krok s technologiemi a vývojem produktu 

v oblastech jejich odborných znalostí. 

Služby po ukončení návrhu 

Služba pro další vývojové práce prováděné po 

schválení do provozu, určená k zajištění, že 

materiálová položka bude dále splňovat 

schválenou specifikaci nebo požadavek štábu. 

Smluvní dodavatel 

Entita v soukromém sektoru, která vstupuje do 

smluvních vztahů se státním sektorem za účelem 

poskytování zboží nebo služeb. 

Software 

Programy, postupy, pravidla, data a dokumentace 

spojená s programovatelnými stránkami 

hardwaru systému a infrastruktury. 

Programové zabezpečení 

Souhrn všech činností, které se uskutečňují pro 

zajištění, aby zavedený a v poli používaný 

software udržel úplné zabezpečení provoznímu 

úkolu systému. Programové zabezpečení 

zahrnuje zabezpečení i v období před nasazením 

softwaru do systému a po ukončení nasazení. 

Softwarová položka konfigurace (CSCI) 

Analogicky k hardwarové položce konfigurace, 

tedy CSCI je (obvykle) softwarový program, 

který vykonává běžnou konečnou funkci, sleduje 

vlastní vývojový cyklus a je řízena samostatně. 

Také se nazývá softwarová položka (SI). 

Specifikace 

Dokument používaný při vývoji a pořizování, 

který popisuje technické požadavky na položky, 

materiály a služby včetně postupů, kterými se 

bude zjišťovat, že požadavků bylo dosaženo. 

Specifikace mají být jedinečné ve vztahu ke 

specifickému programu (charakteristické pro 

program) nebo mohou být společné pro několik 

aplikací (v podstatě obecné). 


1. vydání 

Oprava 1 

meeting cost and performance objectives from 

product concept through production, including 

field support. One of the key IPPD tenets is 

multidisciplinary teamwork through Integrated 

Product Teams (IPTs). 

Market Surveillance 

Includes all the activities that acquisition 

personnel perform continuously to keep 

themselves abreast of technology and product 

developments in their areas of expertise. 

Post Design Services 

A service for further development work 

undertaken after acceptance into service to 

ensure that the item of materiel continues to 

meet its approved specification or staff 

requirement. 

Contractor 

An entity in private industry which enters into 

contracts with the government to provide goods 

or services. 

Software 

Programs, procedures, rules, data and 

documentation associated with programmable 

aspects of systems hardware and infrastructure. 

Software Support 

The sum of all activities that take place to ensure 

that implemented and fielded software continues 

to fully support the operational mission of the 

system. Software support includes 

predeployment software support and 

postdeployment software support (PDSS). 

Computer Software Configuration Item 

(CSCI) 

Analogous to a hardware configuration item, 

that is, a CSCI is software program (typically) 

which performs a common end-use function, 

follows its own development cycle, and is 

individually managed. It is also called a 

Software Item (SI). 

Specification 

A document used in development and 

procurement which describes the technical 

requirements for items, materials, and services 

including the procedures by which it will be 

determined that the requirements have been met. 

Specifications may be unique to a specific 

program (program-peculiar) or they may be 

common to several applications (general in 

nature). 

21


1. vydání 

Oprava 1 

Standard rozhraní 

Standard, který určuje charakteristiky 

fyzikálních nebo funkčních rozhraní systémů, 

podsystémů, zařízení, sestav, součástí, položek 

nebo součástek, umožňující vzájemnou 

zaměnitelnost, propojení, interoperabilitu, 

slučitelnost nebo komunikaci. 

Standardizace 7 

Proces, pomocí něhož resort MO dosahuje nejtěsnější 

proveditelné kooperace mezi silami; 

nejefektivnější využívání zdrojů pro výzkum, 

vývoj a výrobu; souhlas osvojit si v nejširším 

možném rozsahu používání běžných nebo kompatibilních 

provozních, administrativních 

a logistických postupů a kritérií; společných 

nebo kompatibilních technických postupů 

a kritérií; společných nebo kompatibilních nebo 

vzájemně zaměnitelných dodávek, součástí, 

zbraní nebo zařízení; společná nebo 

kompatibilní taktická doktrína s odpovídající 

organizační kompatibilitou. 

Systém 

Uspořádání hardwaru, softwaru, materiálů, 

vybavení, pracovníků, dat a služeb potřebných 

k vykonávání předem určené funkce se 

specifikovanými výsledky, jako je 

shromažďování specifikovaných dat, jejich 

zpracování a dodávání uživatelům. 

Systém kritický pro úkol 

Systém, jehož provozní efektivita a provozní 

použitelnost je základem pro úspěšné dokončení 

úkolu nebo nabytí zbytkové bojové způsobilosti. 

Pokud tento systém selže, nebude tento úkol 

pravděpodobně dokončen. Takový systém může 

být pomocným nebo podpůrným systémem 

stejně dobře jako hlavním systémem úkolu. 

Systémové inženýrství 

Komplexní, iterativní technický manažerský 

proces, který zahrnuje převod provozních 

požadavků do konfigurovaných systémů, 

integrování technických vstupů každého týmu 

pro návrh, řízení rozhraní, charakterizování 

a řízení technických rizik, přenesení technologie 

ze základní úrovně na úroveň specifickou pro 

Interface Standard 

A standard that specifies the physical or 

functional interface characteristics of systems, 

subsystems, equipment, assemblies, components, 

items or parts to permit interchangeability, 

interconnection, interoperability, compatibility, 

or communications. 

Standardization 

The process by which DoD achieves the closest 

practicable cooperation among forces; the most 

efficient use of research, development, and 

production resources; and agreement to adopt on 

the broadest possible basis the use of common or 

compatible operational, administrative, and 

logistics procedures and criteria; common or 

compatible technical procedures and criteria; 

common or compatible, or interchangeable 

supplies, components, weapons, or equipment; 

and common or compatible tactical doctrine with 

corresponding organizational compatibility. 

System 

The organization of hardware, software, 

material, facilities, personnel, data, and services 

needed to perform a designated function with 

specified results, such as the gathering of 

specified data, its processing, and delivery to 

users. 

Mission Critical System 

A system whose operational effectiveness and 

operational suitability are essential to successful 

completion or to aggregate residual combat 

capability. If this system fails, the mission likely 

will not be completed. Such a system can be an 

auxiliary or supporting system, as well as a 

primary mission system. 

Systems Engineering 

A comprehensive, iterative technical 

management process that includes translating 

operational requirements into configured 

systems, integrating the technical inputs of the 

entire design team, managing interfaces, 

characterizing and managing technical risk, 

transitioning technology from the technology 

7 Tato definice je zastaralá. V současné době (podle verze AAP-6:2007) platí tato definice: 

Standardizace je tvorba a zavádění koncepcí, doktrín, postupů a modelů k dosažení a udržení slučitelnosti, 

zaměnitelnosti a shodnosti, které jsou nezbytné k dosažení požadované úrovně interoperability nebo pro 

optimalizaci využívání zdrojů, a to v oblastech operační, výzbrojně technické a administrativní. 

22

program a ověřování, zda návrh splňuje 

provozní požadavky. Je to činnost v průběhu 

životního cyklu, která vyžaduje souběžný 

přístup jak k vývoji produktu, tak procesů. 

Technická data 

Specifikace, plány, výkresy, standardy, 

specifikace pro pořizování a další podobná data 

popisující požadavky státu při akvizici. 

Technické obnovení 

Programový, náklady a omezováním zdrojů pro 

výrobu řízený proces životního cyklu, který 

podporuje náhrady COTS/NDI založené na 

stejném tvaru, vhodnosti a funkci. Toto 

obnovování je předpovídáno na základě 

efektivity nákladů životního cyklu a neustálé 

shody s výkonností aktuálního systému a na 

základě požadavků na rozhraní a obnovování je 

normálně zřetelné koncovému uživateli. 

Testování a hodnocení při vývoji (DT&E) 

Jakýkoliv test technického typu používaný pro 

ověření stavu technického pokroku, ověření, zda 

byla snížena rizika návrhu, pro potvrzení 

dosažení technických parametrů uvedených ve 

smlouvě a potvrzení připravenosti pro vstupní 

provozní testování. Testy při vývoji obecně 

vyžadují přístrojovou techniku a měření a jsou 

prováděny v řízeném prostředí inženýry, 

techniky nebo vojenským personálem určeným 

k provozování a údržbě způsobem umožňujícím 

analýzu poruch. 

Udržovatelnost 

Schopnost položky udržet si nebo obnovit 

specifikovanou podmínku v případě, kdy se provádí 

údržba pracovníky a určenou úrovní 

dovedností, za použití předepsaných postupů 

a zdrojů na každém předepsaném stupni údržby 

a opravy. 

Úplné náklady životního cyklu 

Celkové zdroje požadované pro sestavení, vybavení, 

udržování, provozování a vyřazení specifikované 

vojenské schopnosti, podrobně uvedené 

v plánovací dokumentaci resortu MO pro odsouhlasenou 

úroveň připravenosti k provozu, 

výkonnosti a bezpečnosti. Také zahrnují náklady 

na přijetí, vycvičení a udržení vojenských 

i civilních pracovníků, stejně jako náklady na 

vyšší organizační jednotky a formace. 


1. vydání 

Oprava 1 

base into program specific efforts, and verifying 

that designs meet operational needs. It is a life 

cycle activity that demands a concurrent 

approach to both product and process 

development. 

Technical Data 

Specifications, plans, drawings, standards, 

purchase descriptions, and such other data to 

describe the Government’s requirements for 

acquisition. 

Technical Refresh 

A programmatic, Diminishing Manufacturing 

Sources and cost-driven life cycle process that 

supports the form, fit, and function replacement 

of COTS/NDI. This refreshment is predicated 

upon life cycle cost effectiveness and continued 

compliance with current system performance 

and interface requirements and is normally 

transparent to the end user. 

Developmental Test and Evaluation (DT&E) 

Any engineering-type test used to verify status 

of technical progress, verify that design risks are 

minimized, substantiate achievement of contract 

technical performance, and certify readiness for 

initial operational testing. Development tests 

generally require instrumentation and 

measurements and are accomplished by 

engineers, technicians, or soldier operatormaintainer 

test personnel in a controlled 

environment to facilitate failure analysis. 

Maintainability 

The ability of an item to be retained in, or 

restored to, a specified condition when 

maintenance is performed by personnel having 

specified skill levels, using prescribed 

procedures and resources, at each prescribed 

level of maintenance and repair. 

Whole Life Costs 

The total resource required to assemble, equip, 

sustain, operate and dispose of a specified 

military capability, as detailed in the 

Departmental Plan at agreed levels of readiness, 

performance and safety. It also includes the costs 

to recruit, train and retain military and civilian 

personnel as well as the costs of higher 

organizations and formations. 

23


1. vydání 

Oprava 1 

Uživatel 

V resortu MO jde o obecný pojem pro 

organizační celky zahrnuté do projektu včetně 

garantů zařízení, jednotek provádějících 

zkoušky, orgánů pro dodávky a údržbu, instituce 

pro výcvik a servisní jednotky. 

Vložení technologie 

Aktualizace zařízení se zděděnými vlastnostmi 

(využívající vyvíjených technologií). 

Volba zdroje 

Proces, v němž se zkoumají požadavky, fakta, 

doporučení a zásady státu vztahující se 

k rozhodnutí o přidělení smlouvy při pořizování 

systému/projektu formou veřejné soutěže 

a v němž se přijímají rozhodnutí. 

Výčet prováděných prací (SOW) 

Ta část smlouvy, která stanovuje a definuje 

veškeré nespecifické požadavky ve vztahu 

k úsilí smluvního dodavatele, a to buď přímo 

nebo pomocí specifických citovaných 

dokumentů. 

Vývoj 

Systematické využívání vědeckých a technických 

znalostí při návrhu, vývoji, zkoušení nebo 

hodnocení možného nového produktu nebo 

služby (nebo vylepšení existujícího produktu či 

služby), aby splňoval požadavky na technické 

parametry nebo cíle. Vývoj zahrnuje činnosti 

konstrukce, výroby prototypu a technického 

zkoušení. Z vývoje je vyloučeno takové technické 

úsilí smluvních subdodavatelů, které je 

u existujícího produktu pouze doplňkovým zdrojem 

vývoje. 

Výzkum trhu 

Proces shromažďování dat o charakteristikách 

produktu, způsobilosti dodavatelů a jejich 

obchodních zvyklostech, a navíc analýza těch 

dat, která vedou během akvizice k rozhodování. 

Výzkum trhu má dvě etapy: sledování trhu 

a průzkum trhu. 

Výzkum trhu 

Výzkum trhu je nepřetržitý proces shromažďování 

dat o charakteristikách produktu, způsobilosti 

dodavatelů a jejich obchodních zvyklostech, 

a navíc analýza těch dat, která vedou 

během akvizice k rozhodování. To vyžaduje 

User 

In the MOD a general term for service branches 

involved in a project inclusive of equipment 

sponsors; trials units; supply and maintenance 

agencies; training establishments and service 

Units; i.e. members of HM 8 Armed Forces. 

Technology Insertion 

Updates to legacy equipment (utilizing 

developing technologies). 

Source Selection 

The process wherein the requirements, facts, 

recommendations, and government policy 

relevant to an award decision in a competitive 

procurement of a system/project are examined 

and the decision made. 

Statement of Work (SOW) 

That portion of a contract which establishes and 

defines all non-specification requirements for 

contractors efforts either directly or with the use 

of specific cited documents. 

Development 

The systematic use of scientific and technical 

knowledge in the design, development, testing, 

or evaluation of a potential new product or 

service (or of an improvement in an existing 

product or service) to meet specific performance 

requirements or objectives. It includes the 

functions of design engineering, prototyping, 

and engineering testing; it excludes 

subcontracted technical effort that is for the sole 

purpose of developing an additional source for 

an existing product. 

Market Research 

A process for gathering data on product 

characteristics, suppliers capabilities and the 

business practices that surround them, plus the 

analysis of that data to make acquisition 

decisions. Market research has two phases: 

market surveillance and market investigation. 

Market Research 

Market research is a continuous process for 

gathering data on product characteristics, 

suppliers’ capabilities and the business practices 

that surround them - plus the analysis of that 

data to make acquisition decisions. This requires 

8 HM znamená Her Majesty´s – ozbrojené síly Jejího veličenstva – v ČR takové jednotky neexistují. 

24

někoho pro sběr dat a analyzování informací 

o trhu, které mohou být následně použity ke stanovení, 

zda potřebě může vyhovovat produkt 

nebo služba dostupná na komerčním trhu, zda 

komerční postupy týkající se upravování podle 

potřeb zákazníka, modifikování produktu nebo 

přizpůsobení služeb jsou vhodné k uspokojení 

potřeb zákazníka, jaké jsou obvyklé termíny 

a podmínky včetně záruk, financování 

kupujícího a slevy, na jejichž základě se 

uskutečňují komerční prodeje a zda jsou 

distribuční schopnosti a schopnosti logistického 

zabezpečení možného dodavatele dostatečné pro 

splnění požadavků státu. 

Výzva k podání nabídky (RFP) 

Vyžádání používané u sjednávané akvizice jímž 

se sdělují požadavky státu potenciálním 

dodavatelům a jímž se zadávají nabídky. 

Vyžádání 

Pojem používaný při uzavírání smluv, který 

znamená oslovit potenciální dodavatele a vyžádat 

jejich odpověď na nabídku. 

Zabezpečení (podpora, zajištění) 

Zdroje požadované k provozu a údržbě 

systému/zařízení v průběhu jeho života, včetně 

softwaru. 

Zabezpečení informací 9 

Operace s informacemi, které ochraňují a brání 

informace a informační systémy pomocí 

zajištění jejich pohotovosti, celistvosti, 

legalizace, stupně utajení a neodmítnutí práva 

přístupu. Toto zahrnuje činit opatření pro 

obnovení informačních systémů vkládáním 

schopností ochrany, detekce a reakce. 

Zabezpečování (ověřování) jakosti 

Plánovaný a systematický vzorec všech činností 

nutných k poskytnutí odpovídající shody, že 

byly stanoveny odpovídající technické požadavky, 

že produkty a služby vyhovují stanoveným 

technickým požadavkům a že je dosaženo 

uspokojivé úrovně technických parametrů. 

Zabezpečovatelnost 

Míra snadnosti s jakou charakteristiky návrhu 

systému a plánované logistické zdroje (včetně 

prvků logistického zabezpečení) umožňují 


1. vydání 

Oprava 1 

one to collect and analyze information about the 

market that subsequently can be used to 

determine whether the need can be met by 

products or services available in the commercial 

market; whether commercial practices regarding 

customizing, modifying products or tailoring 

services are available to meet customer needs; 

what are the customary terms and conditions, 

including warranty, buyer financing, and 

discounts under which commercial sales are 

made; and whether the distribution and logistics 

support capabilities of potential suppliers are 

sufficient to meet the needs of the government. 

Request for Proposal (RFP) 

A solicitation used in negotiated acquisition to 

communicate government requirements to 

prospective contractor and to solicit proposals. 

Solicitation 

In contracting, the term means to go out to 

prospective bidders and request their response to 

a proposal. 

Support 

The resources required to operate and maintain 

the system/ equipment through life, including 

Software. 

Information Assurance (IA) 

Information operations that protect and defend 

information and information systems by 

ensuring their availability, integrity, 

authentication, confidentiality, and nonrepudiation. 

This includes providing for the 

restoration of information systems by 

incorporating protection, detection, and reaction 

capabilities. 

Quality Assurance 

A planned and systematic pattern of all actions 

necessary to provide adequate confidence that 

adequate technical requirements are established; 

products and services conform to established 

technical requirements; and satisfactory 

performance is achieved. 

Supportability 

The degree of ease to which system design 

characteristics and planned logistics resources, 

including the logistic support (LS) elements, 

9 Viz normu ČSN ISO/IEC 17799 Informační technologie – Soubor postupů pro management bezpečnosti 

informací. 

25


1. vydání 

Oprava 1 

dosažení pohotovosti systému a požadavků na 

používání ve válce. 

Zákazník 

Pojem „zákazník“ se v tomto ČOS používá 

k identifikaci resortu MO ČR. 10 V případech, 

kdy ustanovení tohoto ČOS využívá hlavní 

smluvní dodavatel vůči svým dodavatelům, pak 

takový subdodavatel přebírá roli smluvního 

dodavatele a hlavní dodavatel je postaven do 

úlohy zákazníka. 

Zálohování u třetí osoby 

Komerční služba archivování softwaru, při níž je 

poskytováno bezpečné uchování zdrojových 

kódů softwaru a záložních dat jak pro dodavatele 

tak koncové uživatele. 

Zařízení opatřené smluvním dodavatelem 

(CFE) 

Standardní položka hardwaru, elektrického 

zařízení nebo jiný standardní výrobek nebo 

komerční položky opatřené hlavním 

dodavatelem jako součást větší sestavy. 

Zastaralost 

Komerční položku již nelze pořídit nebo byla 

zastavena její výroba. 

Zastaralý 

Hardware, které již výrobce nevyrábí. Software, 

které již není zabezpečováno. 

Zastarávání 

Hardware, jehož používání je povoleno do data 

ukončení výroby uvedeného výrobcem. 

Software, jehož používání je povoleno do data 

ukončení zabezpečení. 

Zděděné zařízení 11 

Zařízení, jehož vývoj byl završen. 

Získané zkušenosti 

Poučení z minulých chyb v odhadech, poruch 

materiálů, špatného načasování nebo jiných 

chyb vedoucí zejména ke zlepšení situace nebo 

systému. 

allows for the meeting of system availability and 

wartime utilization requirements. 

Customer 

The term customer is used throughout this 

STANAG to identify the Ministry of Defense 

(MOD). In the cases where this STANAG is 

used by a prime contractor who sub-contracts 

work, the sub-contractor takes on the role of the 

contractor and the prime contractor takes on the 

role of the customer. 

Escrow 

A commercial software archiving service which 

provides secure storage of software source code 

and back up data to both suppliers and end users. 

Contractor Furnished Equipment (CFE) 

Standard items of hardware, electrical 

equipment, and other standard production or 

commercial items furnished by a prime 

contractor as part of a larger assembly. 

Obsolescence 

Commercial items no longer available for 

purchase or has been discontinued from 

production. 

Obsolete 

Hardware: no longer in production by the 

manufacturer. Software: no longer supported. 

Obsolescent 

Hardware: subject to an announced future end of 

production date by the manufacturer. Software: 

subject to an announced future end of support 

date. 

Legacy Equipment 

Equipment whose development is complete. 

Lessons Learned 

Capitalizing on past errors in judgment, material 

failures, wrong timing, or other mistakes 

ultimately to improve a situation or system. 

10 Jestliže resort MO (zastoupený příslušnou organizační složkou) zadává veřejnou zakázku, pak je pojem 

„zákazník“ totožný s pojmem „zadavatel“ (veřejné zakázky) tak, jak je uvedeno v zákoně č. 137/2006 Sb., 

o veřejných zakázkách. 

11 Ve výpočetní technice je takovým zařízením např. počítač, který byl dlouhodobě provozován a jehož funkce 

jsou natolik významné, aby je nebylo možno zrušit modernizací nebo zabudováním do jiného systému. 

26

Zkoumání koncepce 

Začíná po schválení nultého milníku, je to 

počáteční etapa v procesu akvizice systému. 

Během této etapy se rozvíjí strategie akvizice, 

jsou navrhovány a zkoumány alternativy 

systému a je rozšiřována dokumentace 

s požadavky pro program systémů, aby mohla 

zabezpečit následné etapy. 

Životnost typu 

OEM (produkt vytvořený pro dalšího 

producenta, který jej prodává dále), jeho 

distributoři nebo dodavatelé na druhotném trhu 

mohou mít pro uspokojení potřeb zabezpečení 

zařízení v projektu dostatečné zásoby po zbytek 

jeho provozní životnosti nebo mohou ve 

specifikovaném časovém období pokračovat ve 

výrobě součástí. 


1. vydání 

Oprava 1 

Concept Exploration (CE) 

Beginning after Milestone 0 approval, the initial 

phase of the system acquisition process. During 

this phase, the acquisition strategy is developed, 

system alternatives are proposed and examined, 

and the systems program requirements document 

is expanded to support subsequent phases. 

Life of Type 

The OEM, its distributors, or after-market 

suppliers may have enough inventory to meet 

the projected demands of the supported 

equipment for the rest of its operational lifetime 

or may continue to produce the component for a 

specified amount of time. 

27


1. vydání 

Oprava 1 

6 Záměr standardu 6 Aim 

6.1 Dohoda 6.1 Agreement 

Zúčastněné členské státy souhlasí s tím, že řízení 

COTS produktů (buď integrovaných nebo samostatných) 

prováděné ve shodě s návodem a informacemi 

formulovanými v tomto ČOS, se pro 

členské státy NATO stává závazným. Dále souhlasí, 

že jakékoliv plány řízení COTS a s nimi 

spojené dokumenty programu rozpracovávané 

jako důsledek této dohody, budou dány do 

vztahu s parametry návrhu souvisícími 

s logistikou (jako je bezporuchovost a udržovatelnost) 

a s požadavky na připravenost k provozu 

a zdroje pro zabezpečení. Tyto parametry 

souvisící s logistikou jsou vyjádřeny spíše 

pomocí provozních vztahů, než pomocí 

vlastních hodnot a jsou specificky vztaženy 

k cílům připravenosti systému a nákladům na 

zabezpečení materiálového systému. 

Participating nations agree the management of 

COTS products (either integrated or standalone) 

in accordance with the guidance and information 

laid down in the STANAG, is valid for 

examination by NATO nations. Further, they 

agree that any COTS management plans and 

associated program documents developed as a 

result of this agreement will be the relationship 

of logistics-related design parameters, such as 

reliability and maintainability, to readiness and 

support resource requirements. These logisticsrelated 

design parameters are expressed in 

operational terms rather than inherent values and 

specifically related to system readiness 

objectives and support costs of the materiel 

system. 

6.2 Všeobecná ustanovení 6.2 General 

Tento ČOS posuzuje otázky managementu vyplývající 

z používání komerčně pořizovaných 

technologií ve vojenských aplikacích. 12 Je třeba 

rozlišovat mezi řešením pomocí úplného 

komerčního pořízení, u něhož je vyžadován 

omezený vývoj a řešením založeném na COTS, 

kde je takto pořízený produkt využit při vývoji 

celého systému (například spojovací a informační 

systémy (Communication and Information 

Systems – CIS), nebo bojové systémy pro 

válečné lodě). 

Řešení založené na COTS obecně nabízí snížení 

vstupních nákladů na akvizici, zkrácení doby 

akvizice, lepší zajištění bezporuchovosti 

a schopnost nezaostávat za stavem vědy a techniky. 

Z těchto důvodů se využívání COTS produktů 

při pořizování vojenského majetku stalo 

běžným rysem jako trvalá pobídka pro zvyšování 

hodnoty finančních prostředků a snižování 

úplných nákladů životního cyklu. Tento přístup 

This STANAG examines the management issues 

arising out of the use of Commercial Off The 

Shelf (COTS) technology in military 

applications. A distinction needs to be made 

between complete COTS solutions, where 

limited development is required, and COTSbased 

solutions, where COTS products are used 

in the development of a complex system (such as 

a CIS, or a warship’s combat system). 

COTS-based solutions generally offer reduced 

initial acquisition costs, shortened acquisition 

times, more assured reliability and the ability to 

remain close to the state-of-the-art. For these 

reasons the use of COTS products has become a 

common feature of many defence procurements 

in the continuing drive to improve value for 

money and reduce whole life costs. However, 

this approach is not without its drawbacks. The 

12 Při zadávání veřejných zakázek, které zahrnují pořizování informačních technologií do resortu MO formou 

popsanou v tomto ČOS, je třeba přizpůsobit a zahrnout do smlouvy požadavky následujících norem: 

1) ČSN ISO/IEC 15288 Systémové inženýrství - Procesy životního cyklu systému, 

2) ISO/IEC TR 19760 Systémové inženýrství – Návod na aplikaci ISO/IEC 15288 (Procesy životního cyklu 

systému), 

3) ČSN ISO/IEC 20000-1 Informační technologie – Management služeb – Část 1: Specifikace, 

4) ČSN ISO/IEC 20000-2:2006 Informační technologie – Management služeb – Část 2: Soubor postupů. 

28

má však také svoje nevýhody. Účelem tohoto 

ČOS je obrátit pozornost na tyto nevýhody, aby 

je bylo možno v průběhu životního cyklu řídit. 

Hlavní otázky spojené s používáním COTS 

a MOTS produktů jsou dány níže: 

a) Zastarávání. Komerční trh je hnací silou 

prudkého rozvoje technologií COTS, které 

jsou rychle včleňovány do komerčních 

produktů. Tyto COTS produkty mohou mít 

z komerčního hlediska krátkou dobu 

životnosti před tím, než jsou buď plně 

nahrazeny novou verzí, nebo úplně staženy 

z nabídky prodejců. To vede u komerčních 

produktů k rychlému zastarávání. 

b) Požadavky optimalizace nákladů a přínosů. 

Ze své podstaty budou muset být COTS 

produkty navrhovány pro komerční účely, 

které se pravděpodobně nebudou přesně 

shodovat s vojenským operačním požadavkem. 

Má-li se dosáhnout všech výhod použití 

řešení na bázi COTS, bude požadavek na 

optimalizaci nákladů a přínosů přetrvávat 

i během akvizičního procesu, protože na 

náklady a rizika bude mít dopad hlavně 

uplatnění požadavků specifických pro 

armádu. 

c) Otevřené standardy. Využívání COTS je 

těsně spjato s otevřenými standardy; pojetí 

otevřených standardů má svoje výhody i nevýhody. 

Například zde existují rizika spojená 

s používáním otevřených standardů 

mezi interoperabilními systémy a s pokračující 

podporou těchto komerčních standardů 

v komerční sféře. Těmto problémům není 

v tomto standardu jmenovitě věnován 

prostor, přestože se těsné spojení COTS 

a otevřených standardů bere na vědomí. 

d) Nedostatečné řízení produktu. Příslušenství 

nabízené prostřednictvím COTS produktů, 

jejich zabezpečení a doba jejich životnosti 

jsou řízeny vlastním komerčním trhem. 

Vojenský trh bude často představovat 

nevýznamnou část prodeje produktu a stát 

bude mít jen malý vliv na zavádění změn 

nebo na opravování chyb. 

e) Změna vztahů se smluvními dodavateli. 

Charakter integrace systému založeného na 

COTS nebo na otevřených standardech vede 

u déletrvajících vztahů se smluvním 

dodavatelem k nesnázím. To postupně vede 

k potřebě státu rozvíjet se smluvními 

dodavateli těsné dlouhotrvající vztahy. 


1. vydání 

Oprava 1 

purpose of this agreement is to draw attention to 

these drawbacks so that they can be managed 

throughout the life cycle. The essential issues 

underlying the use of COTS and MOTS 

products are given below: 

a) Obsolescence. Rapid advances in COTS 

technology are driven by the commercial 

market and are quickly incorporated into 

commercial products. This COTS products 

can have a short commercial life before 

being either superseded by a new version or 

being dropped from a vendor’s product 

range completely. This leads to the rapid 

obsolescence of commercial products. 

b) Requirements Trade-offs. By their very 

nature, COTS products will have been 

designed for a commercial purpose which is 

unlikely to match the military operational 

requirement exactly. Requirement trade-offs 

will continue throughout the acquisition 

process if the full advantages of using COTS 

solutions are to be gained, as the imposition 

of military specific requirements will 

become major cost and risk drivers. 

c) Open Standards. The use of COTS is closely 

linked to open standards; an open standards 

approach also has drawbacks as well as 

advantages. For example there are risks 

related to the use of common standards 

between interoperable systems and to the 

continued support of these commercial 

standards in the commercial domain. These 

issues are not addressed explicitly in this 

document, although the close link between 

COTS and open standards is acknowledged. 

d) Lack of Product Control. The facilities 

offered by COTS products, their support and 

their longevity are all controlled by their 

commercial market. The military market will 

often represent an insignificant proportion of 

product sales, and the government will have 

little leverage for getting changes 

incorporated or bugs fixed. 

e) A Changing Relationship with Contractors. 

The nature of system integration in a 

COTS/open standards based systems leads 

to pressure for a longer term relationship 

with the contractor. This, in turn, leads to the 

need for the government to develop a close 

long-term relationship with contractors. 

29


1. vydání 

Oprava 1 

f) Flexibilita systému. Flexibilita poskytovaná 

systémy založenými na COTS nabízí 

schopnost udržovat systém blízko úrovně 

současného stavu techniky a tím reagovat na 

hrozby a provozní scénáře. Takováto flexibilita 

však vyžaduje pečlivý management. 

g) Rozhraní. Pokud je pořizováno úplné COTS 

řešení, vždy je zde potřeba rozhraní mezi 

existujícím systémem a postupy pro 

zabezpečení. Financování potřebné k vývoji 

vhodných rozhraní nesmí být podceněno. 

Aby COTS aplikace fungovala, musí se 

dohromady spojit více potřeb, včetně zavedení 

významných změn do způsobu, jakým je 

prováděna akvizice a zabezpečení systému. Pro 

systém využívající COTS se musí vzít v úvahu 

následující: 

a) Požadavky (hardwarové i softwarové) se 

mají definovat ve specifikacích výkonnosti 

nebo funkčnosti, které vyhovují potřebám 

úkolu a tam, kde je to použitelné, umožňují 

a podporují použití COTS. 

b) Aby bylo dosaženo výhod představovaných 

komerčním trhem, ani integrátor ani stát 

nemají vkládat omezení nebo požadavky 

mimo rozsah norem běžných pro komerční 

trh, pokud ještě splňují požadavky úkolu. 

c) Základem úspěšné COTS aplikace je návrh 

architektury hardwaru a softwaru, která 

z jakéhokoliv důvodu snese vložení nové 

technologie bez ovlivnění jejího užití 

v systému. To vyžaduje používat architekturu 

otevřeného systému spojenou s přesným 

dodržováním stabilního komerčního standardu 

pro rozhraní jak u hardwaru, tak 

u softwaru. 

d) Kromě armádou financovaného vývoje 

produktu má být v procesu systémového 

inženýrství položen zvláštní důraz na výběr 

nové technologie prostřednictvím výzkumu 

trhu. 

e) Testování se má zaměřit na požadavky na 

výkonnost systému, na provozní účinnost, na 

provozní vhodnost pro aplikace a na 

integraci komerčních a vyvíjených položek. 

Podmínky testování mají být založeny na 

skutečných provozních podmínkách. Rozsah 

komerčního testování má být co možná 

největší. 

f) System Flexibility. The flexibility offered by 

COTS-based systems offers the ability to 

keep systems close to state-of-the-art and 

hence react to changing threats and 

operational scenarios. This flexibility, 

however, requires careful management. 

g) Interfaces. Even when procuring a complete 

COTS solution, there will be a need to 

interface to existing systems and support 

procedures. The funding required for the 

development of suitable interfaces should 

not be underestimated. 

Many things must come together to make the 

application of COTS work; including 

implementation of significant changes in the 

way systems are acquired and supported. The 

following considerations must be addressed for 

systems using COTS: 

a) Requirements should be defined (both 

hardware and software) in 

performance/functional specifications that 

meet mission needs, and enable and 

encourage the use of COTS where feasible. 

b) To gain the advantages presented by the 

commercial marketplace, neither the 

integrator nor the government should impose 

restrictions or requirements outside the norm 

of the commercial marketplace, while still 

meeting mission requirements. 

c) The foundation of a successful COTS 

application is to design hardware and 

software architectures that will withstand 

insertion of new technology, for whatever 

reason, without impacting their use in the 

system. This requires the use of Open 

System Architecture, with strict adherence to 

stable, commercial interface standards for 

hardware and software. 

d) Significant emphasis in the systems 

engineering process should be on the 

selection of new technology through market 

research in addition to defence sponsored 

product development. 

e) Testing should be focused on system 

performance requirements, operational 

effectiveness, operational suitability for the 

application, and integration of commercial 

and development items. Test conditions 

should be based on actual operating 

conditions. Leverage commercial testing to 

the greatest extent possible. 

30

f) Kdykoli jsou produkty pořizovány a instalovány 

k již zavedenému systému bez toho, že 

byly důkladně testovány v plánované konfiguraci 

systému, existuje rostoucí riziko 

souvisící s již nasazenými systémy. Předtím, 

než je komerční položka nasazena, má 

integrátor přijmout opatření vztahující se 

k odpovídajícím testovacím prostředkům. 

g) Kdykoli je to možné, má být dodavatelům, 

kteří poskytují zabezpečení COTS produktům, 

umožněno beze změny využít jejich 

existující strukturu zabezpečení a existující 

data. Modifikace takových struktur zabezpečení 

jsou nákladné a mají se provádět pouze 

tehdy, pokud pro to zřetelně existuje 

přesvědčivá potřeba. 

h) Novátorské využívání pobídek dodavatelům 

může ovlivnit cenu. Jestliže se uvede 

příslušná pobídka, budou komerční 

dodavatelé nebo integrátor vyhledávat 

způsoby, jak snížit ceny. 

Koncepce akvizice a zabezpečení životního 

cyklu se zaobírá inteligentní volbou a dodáváním 

COTS produktů proto, aby se zajistila 

dlouhodobá podpora a to, že technologie 

systému zůstane aktuální. Tato koncepce 

akvizice sestává z komplexního programu 

akvizice, včetně: 

a) Výzkumu trhu, který zahrnuje sledování 

nastupujících technologií, průzkum slibných 

komerčních produktů a posuzování trendů 

v technologiích. 

b) Posouzení zabezpečovatelnosti u prioritních 

COTS produktů. 


1. vydání 

Oprava 1 

f) There is increased risk to the deployed 

system whenever products are acquired and 

installed in a fielded system without 

thoroughly testing them in the planned 

system configuration. Provision should be 

made for adequate test facilities at an 

integrator before a commercial item is 

deployed. 

g) Contractors supplying COTS products 

should be allowed to use their existing 

support structure and existing data without 

change whenever possible. The 

modifications of these support structures are 

costly and should only be done when there 

clearly exists an overwhelming need. 

h) The innovative use of contractor incentives 

can affect cost. The commercial supplier or 

integrator will seek ways to reduce costs 

when presented with the appropriate 

incentive. 

The acquisition and life cycle support concept 

revolves around intelligent selection and 

procurement of COTS products to ensure long 

term support and that the system technology is 

up to date. This acquisition concept consists of a 

comprehensive implementation program 

including: 

a) Market research, including surveillance of 

leading edge technologies, investigation of 

promising commercial products, and the 

assessment of technology trends. 

b) Supportability assessment of the preferred 

COTS products. 

c) Pořizování zvolených produktů. c) Procurement of the selected products. 

d) Integrace a testování systému s COTS/NDI 

položkami. 

e) Plánování obnovení technologie a vložení 

technologie. 

d) Integration and system testing of the 

COTS/NDI items. 

e) Planning for technology refresh and 

technology insertion. 

31


1. vydání 

Oprava 1 

Obrázek 1: Proces systémového inženýrství pro COTS/položky bez vývoje 

Figure 1: COTS/NDI Systems Engineering Process 

Obrázek 1 objasňuje nejen iterativní a integrované 

použití procesů systémového inženýrství 

zahrnutých do akvizice s COTS/NDI, ale také 

vnitřní závislosti. Dobře fungující systém pro 

řízení dat (DMS systém) pomůže zajistit, že tyto 

procesy jsou efektivně napojeny a integrovány. 

Figure 1 illustrates not only the iterative and 

integrated application of the systems engineering 

processes involved in COTS/NDI acquisition 

and insertion, but also the inherent 

interdependencies. An efficient Data 

Management System will help ensure that these 

processes are effectively linked and integrated. 

32

Uvedené koncepce se využívá k zajištění, aby 

používané komerční produkty setrvaly na co 

nejširším trhu a tudíž si udržely nejúčinnější 

možnosti pro pořizování a zabezpečení. Způsob, 

jak dosáhnout tohoto cíle, zajistí plánovaná 

modernizace systému. Další podrobnosti 

o těchto koncepcích jsou obsaženy 

v následujících kapitolách tohoto standardu. 


1. vydání 

Oprava 1 

This concept is used to ensure that the 

commercial products employed remain within 

the broadest market possible and thus possess 

the most efficient leveraging opportunities for 

procurement and support. Planned system 

upgrades provide a means to achieve this 

objective. Further amplification of these 

concepts is contained in the later sections of this 

document. 

6.3 Podrobnosti standardu 6.3 Details of the agreement 

Každá členská země bude odpovědná za 

vyhodnocení strategie managementu pro COTS 

prováděné ve shodě s tímto návodem (který je 

formulován na základě ustanovení STANAG 

4598) 13 . Členská země provádějící vyhodnocení 

strategie managementu pro COTS musí souhlasit 

s tím, že zpřístupní výsledky svého hodnocení 

jiným členským státům, které mají v úmyslu 

pořídit danou komoditu, nebo převzít jakékoliv 

zařízení, systém nebo program, pro něž byla 

taková strategie použita. 

Tento standard je rozčleněn do čtyř příloh 14 . 

Přílohy jsou určeny, aby čtenáře nejprve 

seznámily se základní koncepcí, která činí 

systémy založené na COTS jedinečnými. Druhá 

příloha diskutuje rozdílné úrovně managementu 

a technických rozhodování a procesy, které 

ovlivnilo použití COTS. Třetí příloha pojednává 

o kritických hlediscích zabezpečení včetně 

managementu konfigurací, které se díky použití 

COTS mění. Čtvrtá příloha představuje seznam 

výstupů, kterým je zapotřebí se věnovat v plánu 

managementu pro COTS. 

Each nation will be responsible for evaluating 

COTS management strategy carried out in 

accordance with the guidance laid down in this 

STANAG. The nation carrying out the 

evaluation of the COTS management strategy 

shall agree to make the results of their evaluation 

available to other NATO nations intending to 

purchase, or take over any equipment, system or 

programme to which such a strategy has been 

applied. 

This document is divided into five annexes. 

These annexes are intended to introduce the 

reader first to the basic concepts of what makes 

COTS based systems unique. The second annex 

discusses the various high level management and 

technical decisions and processes that have been 

impacted by using COTS. The third annex deals 

with critical aspects of support including 

configuration management that are changed 

when using COTS products. The forth annex is a 

list of issues that should be addressed in a COTS 

Management Plan and the fifth annex is a list of 

definitions that are commonly used in the 

acquisition and engineering communities. 

13 Rezort MO nebude vyhodnocování strategie managementu pro COTS provádět. Tato část ČOS (včetně 

souvisejících příloh) je informativní a slouží jako návod pro subjekty obranného průmyslu v případech, kdy se 

budou zapojovat do mezinárodních projektů nebo nabízet své produkty a služby v rámci mezinárodního trhu. 

Jedná se situace, kdy budou muset prokazovat způsobilost nebo předkládat dokumenty související s 

managementem konfigurací, managementem bezpečnosti informací, managementem služeb, se zajištěním 

spolehlivosti pomocí procesů životního cyklu, prezentací dat o bezporuchovosti součástek apod. (tedy v 

souladu s mezinárodními normami a s prokazováním shody dle těchto specifikací). 

14 Vzhledem k předepsané struktuře ČOS je příloha E ke STANAG 4598 uvedena jako součást kapitoly 5 

Použité zkratky, značky a definice. 

33


1. vydání 

Oprava 1 

(PŘÍLOHY) 

34

Systémy založené na COTS – 

rozhodující charakteristiky 

Tato část dává přehled o nejdůležitějších 

charakteristikách COTS produktů a systémů 

založených na COTS a rozdílech mezi nimi. 

A.1 Systémy založené na COTS versus vlastní 

COTS produkty 

Existuje značný rozdíl mezi nakupováním 

úplného COTS systému, který bude stát využívat 

v daném stavu nebo konfiguraci, a vývojem 

systému, který je založen na COTS součástech 

(tento standard se na takové systémy odvolává 

jako na „systémy založené na COTS“). Je-li 

pořizován kompletní COTS systém, prodejce již 

zrealizoval návrh systému a jeho komplexnost je 

pořizovateli (COTS produktu) skryta. Náklady 

na návrh se budou amortizovat až díky velkému 

počtu pořizovatelů. 

Naopak typické vojenské systémy založené na 

COTS obsahují velké množství COTS součástí 

nebo produktů, z nichž každý bude u prodejce 

pořízen samostatně a pak integrován, aby tvořil 

novou konfiguraci systému, která doposud 

nebyla vyvíjena a je ve vztahu ke svému použití 

jedinečná. Tato integrace bude zahrnovat 

konfiguraci jednotlivých produktů, aby byly 

přizpůsobeny prostředí a je typické, že vyžaduje 

vývoj zákaznického kódu poskytujícího funkční 

rozhraní a plnícího specifické požadavky 

systému. Jedinečná konfigurace umisťuje 

jednotlivé součásti do nového prostředí, které 

předtím nebylo vyzkoušeno, což může 

pracovníkům vývoje nebo prodejcům COTS 

odhalit předtím neznámé rozpory. U vojenských 

systémů je situace často složitější díky potřebě, 

aby zákaznické aplikace splňovaly specifické 

vojenské požadavky, díky potřebě začlenění 

zděděných aplikací a díky skutečnosti, že 

systémy mohou být územně rozptýleny. 

Důsledkem této složitosti je to, že systémy založené 

na COTS vyžadují přinejmenším takové 

úsilí při návrhu systému, jako systémy založené 

na součástech dodaných zákazníkem. 

Taková kombinace specifického návrhu, využití 

velkého množství neměnitelných součástí 

v novém prostředí a směsice na zakázku 

vyvinutých a COTS prvků znamená, v rozporu 

se široce uznávaným názorem, že velké systémy 

založené na COTS jsou složité již ze své 

podstaty. Vývoj velkých systémů založených na 

COTS se neobejde bez rizik. 


1. vydání 

Oprava 1 

Příloha A 

Annex A COTS-Based Systems - 

Critical Characteristics 

This section outlines the principal characteristics 

of, and differences between, COTS products and 

COTS-based systems. 

A.1 COTS-Based Systems v. COTS products 

There is a considerable difference between 

buying a complete COTS system, sold commercially 

in the form or configuration that the 

government will use, and developing a system 

based on COTS components (this report refers to 

such systems as "COTS-based systems"). When 

a complete COTS system is purchased, the 

vendor has already carried out the system design 

and its complexity is hidden from the purchaser 

(COTS products). Design cost will have been 

amortized over a large number of purchasers. 

By contrast, a typical military COTS-based 

system will contain a large number of COTS 

components or products, each of which will be 

purchased separately from the vendor and then 

integrated to form a new system configuration, 

never previously developed and unique to this 

application. This integration will involve the 

configuration of individual products to match 

their environment and typically require the 

development of custom code to provide interfacing 

functionality and to meet the specific 

system requirements. The unique configuration 

will also place the individual components in a 

new environment, not tried before, and this may 

well expose incompatibilities previously 

unknown to either the developers or the COTS 

vendors. The situation is often further 

complicated in military systems by the need for 

custom applications to meet specific military 

requirements, by the need to incorporate legacy 

applications and by the fact that systems may be 

geographically dispersed. A consequence of this 

complexity is that COTS-based systems require 

at least as much effort in system design as a 

system based on custom components. 

This combination of a unique design, the use of 

a large number of inflexible components in a 

new environment and a mix of custom and 

COTS elements, means that, contrary to widely 

held opinion, large COTS-based systems are 

inherently complex. Consequently the 

development of large COTS-based systems is far 

from risk free. 

35


1. vydání 

Oprava 1 

Příloha A 

I když je vstupní návrh zakončen, úsilí směřující 

k návrhu se nezastavuje. Tím, jak jsou (jak 

určitě budou) základní COTS součásti 

nahrazovány jinými, bude třeba při zavádění 

systému provádět revize, věnující se 

charakteristikám a funkčnosti nových součástí. 

Některé změny budou malé, například 

modernizace součástí na nové verze nebo jejich 

náhrada plně nebo částečně ekvivalentní 

součástí. Tyto změny na nízké úrovni neovlivní 

návrh celého systému, ale budou vyžadovat jisté 

úsilí a testování pro zajištění, zda nebyla 

nepříznivě ovlivněna celkové výkonnost 

systému. Ostatní změny budou mnohem 

závažnější, jejich příčinou by například mohlo 

být zrušení zabezpečení provozovaného systému 

nebo nahrazení veškeré technologie. Tyto změny 

mohou mít závažný dopad na návrh architektury 

systému. To znamená, že systémy založené na 

COTS nikdy nedospějí na konec etapy návrhu, 

pokud budou při zavádění nebo návrhu rychle 

nahrazeny něčím jiným. 

Bylo naznačeno, že obtíže, které jsou vlastní 

systémům založeným na COTS, jsou důvodem, 

proč bychom se měli COTS vyhnout a soustředit 

se na vývoj systémů na zakázku, nad nimiž 

máme určitou kontrolu. V dohledné budoucnosti 

budou všechny nové systémy určité významné 

velikosti obsahovat významný počet COTS. To 

platí zejména u IT systémů, kde neexistuje 

reálná alternativa pro používání komerčně 

pořizovaných procesorů, operačních systémů, 

programové vybavení infrastruktury a podpůrný 

hardware. 

Design effort will not cease when the initial 

design is completed. As the underlying COTS 

components are replaced by others (as they 

surely will be), the systém implementation will 

need revisiting to address the characteristics and 

functionality of the new components. Some of 

the changes will be minor, for instance the 

upgrade of a component to a new version or its 

replacement with a fully or nearly equivalent 

component. These lower level changes will not 

impact on overall systems design, but will 

require effort and testing to ensure that the 

overall system performance is not adversely 

affected. Other changes will be more substantial, 

caused for instance by the withdrawal of support 

for an operating system or the supersession of an 

entire technology. These changes could have a 

major impact on system architecture design. It 

could be said that this means that a COTS-based 

system never leaves the design stage, with each 

implementation or design being rapidly 

superseded by another. 

It has been suggested that the difficulties 

inherent in the through life support of COTSbased 

systems are such that we should avoid 

COTS and concentrate on custom systems, over 

which we have some control. For the foreseeable 

future all new systems of any reasonable size 

will contain a significant amount of COTS. This 

is particularly true in IT systems, where there is 

no realistic alternative to using COTS 

processors, operating systems, infrastructure 

software and support hardware. 

A.2 Charakteristika COTS součástí A.2 COTS Component Characteristics 

Rychlé výhody technologie COTS jsou řízeny 

komerčním trhem a jsou rychle začleňovány do 

komerčních produktů. Předtím, než je COTS 

produkt buď nahrazen novou verzí, nebo než 

úplně zmizí z nabídky prodejců, může mít 

z komerčního hlediska krátkou dobu životnosti. 

Přestože jeho podpora bude určitou dobu pokračovat, 

upustí se od ní v případě, kdy náklady na 

podporu překročí finanční návratnost. To povede 

k prudkému zastarání komerčních produktů. 

Produkty, jimiž byla náhrada uskutečněna, 

budou často lepší než jejich předchůdci, ale začleňování 

nových verzí nebo produktů bude 

nicméně vyžadovat úsilí a náklady. 

Prostředky nabízené pomocí COTS produktů, 

jejich zabezpečení a jejich dlouhověkost (nebo 

Rapid advances in COTS technology are driven 

by the commercial market and are quickly 

incorporated into commercial products. Thus 

COTS products can have a short commercial life 

before either being superseded by a new version 

or being dropped from a vendor’s product range 

completely. Although support will continue for a 

finite period, it will be dropped when the cost of 

support exceeds the financial return. This leads 

to the rapid obsolescence of commercial 

products. Replacement products will often be 

better than their predecessors, but incorporating 

the new version or product will still require 

effort and cost. 

The facilities offered by COTS products, their 

support, and their longevity (or lack of it) are all 

36

její absence) jsou řízeny vlastním komerčním 

trhem. Vojenský trh bude často představovat 

nevýznamnou část prodeje produktu a stát bude 

mít malý vliv na zavádění změn nebo na 

opravování chyb nebo na délku trvání 

rozšířeného zabezpečení. V některých případech 

může být zabezpečení zastaveno poměrně 

krátkým sdělením, a bude vyžadovat pružnou, 

dynamickou odpověď od návrhářů systému. 

COTS produkty jsou všeobecně prodávány bez 

jakýchkoliv informací o jejich návrhu nebo 

vnitřních charakteristikách (jako je zdrojový kód 

u softwarových produktů 15 ). Dostupnost dat 

z návrhu a ochota prodejce je poskytovat mají 

být významným faktorem v procesu výběru. Je 

příznačné, že si pro používání produktu uživatel 

pořídí licenci, ale ne informace o návrhu. Mezi 

následky této skutečnosti patří: 

a) neschopnost modifikovat produkt tak, aby 

odpovídal specifikovaným požadavkům, 

b) neschopnost provést posouzení vedoucí ke 

schvalování bezpečnostního certifikátu, 

s výjimkou testování černé skříňky. 

Stát tradičně trvá na shodě s mnoha specifickými 

standardy vztahujícími se k takovým problémům, 

jako je odolnost proti rázům, elektromagnetická 

kompatibilita (EMC), toxicita a použití 

v nepříznivém prostředí. COTS produkty nejsou 

tvořeny tak, aby odpovídaly těmto specifickým 

standardům. Zkoušky posuzující shodu, nebo 

případně modifikace, které shody dosáhnou, 

budou vždy zvyšovat náklady na produkt. 

Získání záruk od dodavatele, aby budoucí dodávky 

byly ve shodě, může také zvyšovat 

náklady. V některých případech mohou být 

budoucí dodávky postaveny na stejných nebo 

podobných standardech – přijatelnost takových 

dodávek musí být pak testována. 


1. vydání 

Oprava 1 

Příloha A 

controlled by their commercial market. The 

military market will often represent an 

insignificant proportion of product sales, and the 

government will have little leverage for getting 

changes incorporated, bugs fixed or the duration 

of support extended. In some cases support can 

be withdrawn at relatively short notice, requiring 

a flexible, dynamic response from system 

designers. 

COTS products are generally sold without any 

information on their design or internal 

characteristics (such as source code for software 

products 15 ). The availability of design data and 

the vendor’s willingness to provide same should 

be significant factor during the selection process. 

Typically a user purchases a license to use a 

product, not the design information. 

Consequences of this include: 

a) Inability to modify the product to match 

specific requirements. 

b) Inability to carry out assessments for safety 

or security accreditation, except by Black 

Box testing. 

The government has traditionally insisted on 

compliance with a number of specific standards 

relating to such issues as shock resistance, 

Electro-Magnetic Compatibility (EMC), toxicity 

and use in hostile environments. COTS products 

will not have been built to meet these specific 

standards. Tests to assess, and where required 

modifications to achieve, compliance will 

invariably increase the cost of the product. 

Gaining guarantees from manufacturers that 

future deliveries will be compliant may also 

increase costs. In some cases, future deliveries 

may have been built to equivalent or similar 

standards; the acceptability of these will have to 

be tested. 

A.3 Otevřené standardy A.3 Open Standards 

Používání COTS je pevně spojeno s otevřenými 

standardy a přístup využívající otevřené sys- 

The use of COTS is closely linked to open 

standards, and the use of an open systems 16 /open 

15 Cestou k řešení tohoto problému je co nejširší používání „Open source“ softwaru, jehož pravděpodobně 

nejmarkantnějším příkladem v současnosti je LINUX. Ovšem používání „Open source“ softwaru může být 

hodně rozvětvené a ukazuje se, že to pro vojenské systémy není užitečná cesta. 

The more widespread use of "Open Source" software, of which LINUX is probably the most prominent 

current example, is a move towards resolving this problem. However, the use of Open Source software has 

many ramifications, and may not prove to be a useful route for military systems. 

37


1. vydání 

Oprava 1 

Příloha A 

témy 16 /otevřené standardy je důležitým nástrojem 

vývoje flexibilních, způsobilých a zabezpečovatelných 

systémů využívajících COTS produkty. 

Volba vhodných standardů je klíčovým 

rozhodnutím pro návrh a úzce souvisí s výběrem 

hlavních součástí a standardů, používaných 

jinými, v součinnosti pracujícími systémy. 

Přístup využívání otevřených standardů však 

není všelékem a neřeší všechny problémy 

s modernizací. Účelem tohoto ČOS není 

podrobně o těchto problémech diskutovat, ale 

nabízejí se následující poznámky: 

a) Dostupnost součástí, které přísně splňují 

standardy – mnoho hardwarových 

i softwarových součástí bude splňovat velký, 

ale neúplný podsoubor standardů (např. ani 

Netscape 4 ani Internet Explorer 5 nejsou 

plně kompatibilní se standardem pro webové 

stránky (HTML)). Nahrazení jedné 

všeobecně vyhovující součásti jinou může 

přivodit kritické problémy s kompatibilitou, 

které budou vyžadovat minimálně nový 

návrh kódu nebo nové aplikace na zakázku. 

b) Použití vlastnicky chráněných rozšíření ke 

standardům – aby výrobce zajistil další 

funkce nebo technické parametry, spoléhá 

v mnoha případech na základní standard. To 

staví jeho produkt před ostatní rivaly, ale 

omezuje pružnost návrhu budoucího 

systému a volbu dalších součástí. Těmto 

postupům je třeba se vyhnout. 

c) Nepřetržitá podpora standardů v komerčním 

prostředí – dostupnost součástí 

podporujících specifické standardy bude 

záviset na tom, jak budou tyto standardy 

pro komerční prostředí potřebné. Během 

doby životnosti běžného vojenského 

systému budou mnohé standardy 

v komerčním světě opuštěny a nebudou 

podporovány žádnými COTS součástmi. 

Bedlivé monitorování komerčních standardů 

a dialog s orgány, které je řídí, je 

nezbytností. 

standards approach is an important tool in 

developing flexible, capable and supportable 

systems using COTS products. The selection of 

appropriate standards is a key design decision, 

and will be closely related to the selection of 

major components and the standards used by 

other, interoperating, systems. 

However, an open standards approach will not 

be a panacea, and such an approach will not 

resolve all upgrade problems. It is not the 

purpose of this paper to discuss these issues in 

detail, but the following comments are offered: 

a) Availability of components that rigidly 

comply with standards – Many hardware and 

software components will comply to a large 

but incomplete subset of a standard. (For 

example, neither Netscape 4 nor Internet 

Explorer 5 is fully compliant with the 

standard for web pages (HTML)). The 

replacement of one broadly compliant 

component with another may bring crucial 

incompatibility problems, requiring at the 

least a redesign of custom code or 

applications. 

b) The use of proprietary extensions to 

standards - In many cases, a manufacturer 

will build on a base standard to provide 

additional functionality or performance. This 

gives his product an edge over its rivals, but 

limits the flexibility of future system design, 

and of selection of other components. This 

practice should be avoided. 

c) The continued support of standards in the 

commercial domain – The availability of 

components supporting specific standards 

will be dependent on the need for those 

standards in the commercial domain. During 

the lifetime of a typical military system, 

many standards will be dropped by the 

commercial world, and will not remain 

supported by COTS components. Close 

monitoring of commercial standards and 

dialog with their governing bodies is a 

necessity. 

16 Definice „otevřeného systému“ je stále zdrojem mnoha debat. V kontextu tohoto ČOS je tím míněno 

používání definovaných a široce podporovaných standardů při definování rozhraní systému. 

The definition of "Open Systems" remains the source of much debate. In this context it is intended to mean 

the use of defined and widely supported standards in the definition of system interfaces. 

38


1. vydání 

Oprava 1 

Příloha A 

A.4 Změny komerčních technologií A.4 Changes in Commercial Technology 

Technologie, na nichž jsou COTS produkty 

založeny, se během doby životnosti běžného 

vojenského systému mění. Tyto změny budou 

mít výhody i nevýhody. Pomocí vhodně 

navržených systémů založených na COTS může 

být rozvoj technologií využit ke zdokonalení 

systému a rozšíření jeho funkcí. 

Je však snadné podcenit rozsah změn, které 

pravděpodobně uvidíme v průběhu příštích 25 

let (na jejichž konci bude ještě v provozu mnoho 

systémů, které jsou nyní v etapě koncepcí). 

Jestliže se vrátíme zpět o 25 let, tedy do roku 

1974, můžeme vidět, jak daleko se komerční 

technologie dostaly. V roce 1974 ještě 

neexistovaly stolní počítače, žádný Internet (v té 

podobě, v jaké ho známe dnes) a žádné mobilní 

telefony. Objektově orientované programování 

bylo neznámým postupem a existovala rozhraní 

na bázi textů. Mikroprocesor prožíval dětská léta 

(v roce 1974 byly uvedeny do provozu 

procesory 6 MhZ 8080 a 6.4 Mhz 6800). 

Uživatelské rozhraní Windows, myši, LCD 

monitory, světová síť, TCP/IP a HTML byly 

dosud na mnoho let v nedohlednu. Krátce, 

můžeme vidět, že komerční technologie se 

změnily nade všechno poznání a je třeba obecně 

vzít v úvahu, že rychlost změn technologií se 

v tomto období zvyšovala. Nové koncepce a myšlenky 

jsou dnes zaváděny stále rychleji. 

Některé změny během tohoto období budou 

předvídatelné. Energetická náročnost provozu se 

bude neustále snižovat, šířka frekvenčního 

pásma pro komerční uživatele se bude rozšiřovat 

a náklady na paměť (energeticky závislou nebo 

nezávislou) se budou snižovat. Jak nám však 

ukázalo posledních deset nebo dvanáct let, je 

nemožné předpovědět, jakým způsobem bude 

tento vývoj využíván komerčním prostředím. 

V příštích dvaceti letech můžeme pozorovat 

změny, jako jsou osvojení prakticky neomezených 

pásem (vedoucí k revoluci v architektuře 

systému), zánik webově založeného přístupu 

a nahrazení klávesnic a monitorů zařízeními 

orientovanými na přirozenou řeč a na pohyb. 

V komerčním prostředí se může používání 

softwaru z „otevřených zdrojů“ a využívání 

poskytovatelů služeb (kteří podle potřeby pronajímají 

využívání svých služeb) stát normou. 

The technology on which COTS products are 

based will change during the lifetime of a typical 

military system. These changes will lead to 

advantages as well as disadvantages. With a 

suitably designed COTS-based system, 

developments in technology can be harnessed to 

enhance the system and extend its functionality. 

It is easy, however, to underestimate the 

magnitude of the changes we are likely to see in 

the next twenty five years (at the end of which 

many systems currently in the Concept Stage 

will still be in service). If we look back twentyfive 

years, to 1974, we can see how far 

commercial technology has moved. In 1974, 

there were no desktop computers, no Internet (in 

the form we would recognize today) and no 

mobile phones. Object oriented programming 

was an obscure specialist technique and 

interfaces were text based. The microprocessor 

was in its infancy (the 6 MHz 8080 and 6.4 MHz 

6800 were both launched in 1974). Windowed 

user interfaces, mice, LCD screens, the world 

wide web, TCP/IP and HTML were still all 

years in the future. In short, we can see that 

commercial technology has changed beyond all 

recognition, and it is generally considered that 

the rate of change of technology has been 

increasing over this period. Today, new concepts 

and ideas are being introduced at a high rate. 

Some changes during this time will be 

predictable. The cost of processing power will 

continue to fall, bandwidth available to 

commercial users will expand, and the cost of 

storage (volatile and non-volatile) will reduce. 

However, as the last ten or twenty years has 

shown us, the way in which these developments 

will be exploited in the commercial world is 

impossible to predict. In the next twenty years 

we may see changes such as the adoption of 

effectively unlimited bandwidth (leading to 

revolutions in system architecture), the demise 

of a web based approach and the replacement of 

keyboards and screens by natural language and 

gesture devices. In the commercial world, the 

use of open source software, and application 

service providers (who lease the use of their 

products as required) may become the norm. 

39


1. vydání 

Oprava 1 

Příloha A 

A.5 Potřeba znalostí o trhu A.5 Need for Market Knowledge 

Jestliže mají být využity příležitosti k vývoji 

s novými technologiemi a mají se vyloučit 

zastaralé technologie, integrované týmy pro 

produkt budou mít potřebu aktuálních znalostí 

o vývoji technologií. Tato znalost bude muset 

pokrývat různá časová měřítka: 

a) Nejbližší budoucnost – např. doby 

zabezpečení u produktů, které jsou právě 

v systému. 

b) Střednědobé termíny – např. pravděpodobné 

schopnosti budoucích verzí produktů nebo 

tříd produktů. 

c) Dlouhodobé termíny – např. předvídané 

doby životnosti technologií, nové budoucí 

technologie. 

Tato znalost by mohla být zajišťována z mnoha 

zdrojů, jako jsou partneři z průmyslu, státní 

zaměstnanci – členové integrovaných týmů pro 

produkt nebo díky nezávislé třetí straně. 

Vyskytly se argumenty, že vojenské systémy 

založené na COTS se neliší od systémů založených 

na COTS v komerčním prostředí a že 

bychom měli být schopni řešit naše problémy 

s využitím zkušeností z civilního sektoru. Ačkoli 

je toto tvrzení částečně pravdivé, vojenské 

systémy mají obecně delší dobu životnosti, 

mnohem přísnější bezpečnostní požadavky, více 

procent kódů vyrobených na zakázku, delší doby 

v úkolu bez zabezpečení nebo při nedostupnosti 

prostředků zabezpečení, pokud systém selže. 

(Ve všech těchto oblastech existují výjimky, ale 

obecně lze brát tato kriteria jako oprávněná). 

Navzdory těmto rozdílům existují i skutečné 

podobnosti a z civilních a komerčních postupů 

lze čerpat poučení. To však není všelékem pro 

řešení problémů s vojenským COTS. 

Civilní/komerční prostředí má také problémy se 

systémy založenými na COTS a přiznává 

množství problémů popsaných v tomto ČOS. 

If opportunities for new technological 

developments are to be harnessed, and the 

problems of outdated technology are to be 

avoided, IPTs will need to have up to date 

knowledge of technological developments. The 

knowledge will have to cover a range of 

timescales: 

a) Immediate Future - e.g. support lifetimes for 

products currently in the system. 

b) Medium Term - e.g. likely capabilities of 

future versions of products and product 

families. 

c) Long Term - e.g. predicted lifetimes of 

technologies, new future technologies. 

This knowledge could be provided from a 

number of sources such as the industry partner, 

by the government members of the IPT or by an 

independent third party. 

It has been argued that military COTS-based 

systems are no different from COTS-based 

systems developed in the commercial world, and 

we should be able to use the experience from 

civil industry to solve our problems. While there 

is some truth in this assertion, military systems 

generally have a longer lifetime, more stringent 

security requirements, greater percentage of 

custom application code, longer unsupported 

mission times and inaccessibility of support 

facilities when a system fails. (It is appreciated 

that there are exceptions in all these areas, but 

the these criteria are generally true.) 

Despite these differences, there are genuine 

similarities, and lessons can be drawn from civil 

and commercial practice. This does not, 

however, provide a panacea to solve the military 

COTS problems. The civil/commercial world 

also has problems with COTS-based systems 

and suffers many of the difficulties outlined in 

this paper. 

40

Řízení modifikací a modernizací 

systému 

Jakákoliv významná modernizace systému založeného 

na COTS, zejména staršího systému, je 

pravděpodobně komplexní a kombinuje množství 

změn, z nichž každá se provádí z různého 

důvodu a s rozdílnou odpovědností. Modifikace 

často zahrnují kombinaci změn působících proti 

zastarávání a zlepšujících funkčnost, technické 

parametry nebo interoperabilitu. Odpovědnosti 

za financování a specifikování těchto změn se 

mění, ale existuje potřeba rozhodnout o jediném 

cenově efektivním balíku modifikací, který 

může být navržen a zaveden. Tento oddíl 

diskutuje možné procesy pro řízení modernizací. 


1. vydání 

Oprava 1 

Příloha B 

Annex B Management of System 

Modifications and Upgrades 

Any significant upgrade to a COTS-based 

system, particularly in a mature system, is likely 

to be complex, and to combine a number of 

changes, each being done for a different reason 

and with different responsibilities. Modifications 

will often include a combination of changes to 

obsolescence and to improve functionality, 

performance or interoperability. The 

responsibilities for funding and specifying these 

changes will vary, but there is a need to decide 

on a single cost-effective package of 

modifications that can be designed and 

implemented. This section discusses possible 

processes for the management of upgrades. 

B.1 Terminologie B.1 Terminology 

Terminologie souvisící s modernizací systému je 

komplexní a různorodá. Mnoho pojmů se běžně 

používá, včetně vkládání technologie, obnovení 

technologie, modernizace zastaralého systému, 

přírůstkový sběr dat, balík pro opravu softwaru, 

servisní verze a modernizace schopností. Každý 

z těchto pojmů má obecně uznávanou definici, 

která se však může v různých státech lišit 

a jejich použití může přispět ke zmatkům 

a nejasným diskusím. 

Tento dokument příliš nezdůrazňuje argumenty 

týkající se významu a používání těchto pojmů, 

ale je důležité rozlišovat minimálně mezi dvěma 

rozdílnými situacemi: 

a) Změny systému, které jsou motivovány 

zastaráváním součástí. V tomto ČOS je toto 

nazýváno „obnovením technologie“ nebo 

„obnovením“. 

b) Změny systému rozšiřující funkčnost. 

V tomto ČOS je toto nazýváno „vkládáním 

technologie“. (Může zahrnovat změny 

vyžadující splnění nových požadavků, nebo 

takové, které, aby zaručily interoperabilitu, 

přinesly změny jiných systémů.) 

Důležitým rysem systémů založených na COTS 

je, že jakákoliv významná modernizační událost 

bude obsahovat prvky minimálně dvou, ale spíše 

tří tříd systémových změn, uvedených 

v následujícím odstavci. 

Organizace s odpovědností za činnost se pro 

každou z těchto různých tříd systémových změn 

liší: 

The terminology relating to system upgrades is 

complex and diverse. Many terms are in 

common use, including Technology Insertion, 

Technology Refresh, Obsolescence Upgrade, 

Incremental Acquisition, Service Pack, Service 

Release and Capability Upgrade. These terms 

each have commonly accepted definitions that 

may differ from country to country, and their use 

can add to confusion and cloud discussions. 

There is little value in this paper adding to the 

arguments regarding the meaning and use of 

these terms, but it is important to distinguish 

between at least two different situations: 

a) Changes to a system that are driven by the 

obsolescence of a component. In this paper, 

these will be termed "technology refresh" or 

"refresh". 

b) Changes to a system to add functionality. In 

this paper these will be termed "technology 

insertion". (These may include changes 

required to meet new requirements, or those 

brought about by changes to other systems 

to guarantee interoperability.) 

An important feature of COTS-based systems is 

that any significant upgrade event will include 

elements of at least two and possibly all three of 

the classes of system changes listed below. 

The organization with responsibility for the 

activity varies for each of these different classes 

of system change: 

41


1. vydání 

Oprava 1 

Příloha B 

a) Za obnovení technologie je obecně 

odpovědná ta součást, která odpovídá za 

zabezpečení životního cyklu. Organizační 

jednotky pro zabezpečení životního cyklu 

rozhodují, kdy je třeba provést takovéto 

změny a bude potřebovat dostatečný přístup 

k systému, aby provedla nezbytné změny. 

b) Vkládání technologií se zásadně schvaluje 

na počátku programu, ale podrobný návrh, 

časový harmonogram a náklady nesmí být 

v této etapě dohodnuty. (Opravdu, u systémů 

založených na COTS by se pokus odsouhlasit 

tyto podrobnosti stal kontraproduktivním, 

vzhledem k tomu, že technologie se může 

ještě před zavedením modernizace významně 

změnit.) Je nepravděpodobné, že 

hlavní dodavatel bude mít stanovenu pevnou 

cenu, která by pokryla i vkládání technologie, 

jež nebylo jednoznačně definováno. 

Takto tedy asi bude v souvislosti s vkládáním 

technologií existovat určitá společná 

odpovědnost státu a hlavního dodavatele. 

c) Modernizace schopností, které se do 

původního zařízení zavádí navíc, bude 

vyžadovat schválení a financování státem 

v případě, pokud bude přesahovat rámec 

původní dohody, nebo smlouvy s hlavním 

dodavatelem. 

Pro uskutečnění takovýchto změn budou 

existovat pouze omezené možnosti, takže 

cenově výhodnější je začlenit řadu požadavků na 

změny do jediné změnové události. Pro 

překonání zastarávání je zbytečné zavádět novou 

součást a hned poté provést modernizaci 

schopností tím, že se tato součást vymění. 

Podobně je nerozumné zavádět novou funkci 

tak, že se použije zastaralá součást, kterou bude 

zapotřebí vyměnit krátce poté. 

Rozhodnutí týkající se toho, co představuje 

jakákoliv modernizační událost, je ovlivněno 

přáními jak státu, tak průmyslu. Struktura 

integrovaného týmu pro produkt (IPT) má 

umožnit toto pečlivě zvážit a řídit 

koordinovaným způsobem. Následující část 

standardu bere v úvahu různé faktory, na které 

má při plánování modernizací brát společně 

ohled stát i průmysl. 

a) Technology refresh will generally be the 

responsibility of the entity responsible for 

Life Cycle Support. The Life Cycle Support 

activity will decide when these changes need 

to be made, and will need reasonable access 

to the system to carry out the necessary 

changes. 

b) Technology insertions will have been agreed 

in principle at program inception, but the 

detailed design, timescale and cost may not 

have been agreed at that stage. (Indeed with 

a COTS-based system, trying to agree such 

details may be counter-productive, as 

technology may change significantly before 

the upgrade is implemented.) It is unlikely 

that the Prime Contractor will have given a 

firm price to cover Technology insertions 

that have not been clearly defined. Hence 

there is likely to be some shared 

responsibility between the government and 

the Prime Contractor with respect to 

Technology insertions. 

c) Capability upgrades, introduced in addition 

to the original requirement will need to be 

endorsed and funded by the government, as 

they will be beyond the scope of the original 

agreement or contract with the Prime 

Contractor. 

There will generally only be limited 

opportunities to carry out these changes, so it is 

cost effective to sweep up a range of change 

requirements in a single change event. It would 

be inefficient to introduce new components to 

overcome obsolescence, and then immediately 

follow that with a capability upgrade that 

replaced those components. Similarly it would 

be unwise to introduce new functionality using 

obsolescent components which would need to be 

changed shortly afterwards. 

The decision regarding what is included in any 

upgrade event is influenced by the desires of 

both the government and industry. The IPT 

structure should allow these to be carefully 

balanced and managed in a coordinated fashion. 

The following section considers the various 

factors to be considered jointly by the 

government and industry when planning 

upgrades. 

B.2 Řízení případů modernizace B.2 Management of Upgrade Events 

Při plánování a provádění programů určených ke In planning and conducting a program to meet 

42

splnění požadavků na obnovení technologie, 

vkládání technologie a modernizace schopnosti 

je třeba vzít v úvahu mnoho úzce propojených 

procesů a rozhodnutí. Zatímco obecné snahy 

o rozvoj schopností mohou být stanoveny na 

několik let dopředu, o přesných plánech pro 

jednotlivý případ modernizace (včetně změn 

funkce a technických parametrů) nemůže být 

rozumně rozhodnuto (nebo stanoveny náklady), 

pokud nebude vlastní modernizace blíže známa. 

Skutečný obsah modernizace bude podroben 

optimalizaci nákladů a přínosů v rozsahu 

schopností, nákladů a časových měřítek. 

Vzájemné vztahy a zpětná vazba mezi různými 

obsaženými problémy naznačují, že pro nalezení 

vhodného řešení bude zapotřebí iterativního 

procesu, kterému budou rozumět všechny strany, 

jichž se problém týká. Aby bylo takového 

rozhodnutí dosaženo, bude třeba zapojit řadu 

institucí, včetně IPT, hlavního dodavatele 

a koncového uživatele. 

Klíčovými prvky, o nichž musí být u každého 

případu modernizace rozhodnuto, jsou: 

a) jaké platformy/instalace budou modernizovány, 


1. vydání 

Oprava 1 

Příloha B 

the demands of technology refresh, Technology 

insertions, and capability upgrades, a number of 

tightly interlinked processes and decisions need 

to be considered. While general aspirations for 

capability evolution can be laid down some 

years in advance, the specific plans for a 

particular upgrade event (including the 

functionality and performance changes) can not 

sensibly be decided (or costed) until closer to the 

event itself. The exact content of an upgrade will 

be the subject of trade-off between capability, 

cost, and timescales. The interlinking and 

feedback between the various issues involved 

implies that an iterative process is likely to be 

required to find an optimum solution, with clear 

understanding by all parties of the issues 

concerned. Reaching these decisions will need 

the involvement of a range of authorities, 

including IPT, Prime Contractor, and end user. 

The key elements to be decided for any upgrade 

event are: 

a) Which platforms/installations will be 

upgraded, 

b) co bude do modernizace zahrnuto, b) What will be included in the upgrade, 

c) kdy modernizace začne a jak dlouho bude 

trvat její dokončení, 

c) When the upgrade will start and how long it 

will take to complete. 

d) jak bude modernizace financována. d) How the upgrade will be funded. 

Dosáhnout rozhodnutí, které bude obsahovat 

všechny uvedené aspekty, není jednoduchý 

proces. Některá vzájemná působení jsou 

diskutována níže. 

Jako klíčové pobídky pro rozhodnutí provést 

případ modernizace byly identifikovány 

obnovení technologie a vkládání technologie. 

Má-li se najít pro obsah modernizace cenově 

nejúčelnější volba, je třeba tyto pobídky 

jednotně vzít v úvahu. Tam, kde je to možné, je 

třeba využít možnosti provést jedinou 

modernizační událost, souvisící současně 

s oběma pobídkami. 

Volbu toho, co má být modernizováno, je třeba 

posoudit na základě mnoha dalších faktorů. 

Mezi tyto faktory náleží: 

a) Náklady – je pravděpodobné, že mnoho 

modernizací bude cenově omezeno. V případě 

modernizace bojového zastarání nebo 

dříve odsouhlaseného zlepšení, které je na 

Reaching a decision on all these aspects is not a 

simple process. Some of the interactions are 

discussed below. 

The key drivers in deciding to undertake an 

upgrade event have been identified as 

technology refresh and Technology insertion. 

These drivers will have to be considered in 

unison, if the most cost-effective choice of the 

content of the upgrade is to be found. The 

opportunity will be taken, wherever possible, to 

carry out a single upgrade event that will deal 

with both concurrently. 

The choice of what is undertaken in an upgrade 

will be tempered by a number of other factors. 

These will include: 

a) Cost - It is likely that many upgrades will be 

cost constrained. In the event of upgrades to 

combat obsolescence or previously agreed 

improvements that are the responsibility of 

43


1. vydání 

Oprava 1 

Příloha B 

základě dohody o pevné ceně v pravomoci 

hlavního dodavatele, bude cena omezena 

přáním hlavního dodavatele maximalizovat 

zisk (krátkodobý nebo dlouhodobý). V případě 

nových požadavků bude manažer pro 

CM v programu usilovat u IPT o minimální 

cenu a IPT bude poté usilovat o minimální 

cenu pro hlavního dodavatele. Tam, kde je 

vyžadován určitý druh sdílení nákladů nebo 

schéma podílu na trhu, bude v zájmu jak 

IPT, tak průmyslu, držet náklady na 

modernizace na minimální úrovni. Kromě 

nákladů průmyslu budou existovat i náklady 

spojené s přijetím modifikovaného systému. 

b) Doba trvání zavedení – období, po které 

bude omezena operační (příp. provozní) 

platforma nebo instalace určená pro 

modernizaci. Bude samozřejmě nezbytné 

zvolit modernizaci, která bude úspěšně 

provedena v dostupné době. Doba trvání 

musí zahrnovat nejen samotnou dobu na 

provedení změny, ale také dobu potřebnou 

pro testování a přijetí modernizovaného 

systému a jakýkoliv s tím spojený výcvik 

a dobu zabezpečení. Bude také omezena 

provozními zprávami platformy (např. doba, 

kterou platforma nebo instalace potřebují 

k tomu, aby byly schopné návratu do 

provozního stavu, pokud se vyskytne 

naléhavý požadavek). To bude vyžadovat 

odhad doby, potřebné i v nejhorší alternativě 

k zastavení modernizace a návratu zařízení 

do jeho původního stavu. V této době bude 

též zapotřebí umožnit, aby v případě selhání 

události, která zavádí modernizaci, byla tato 

modernizace zastavena. 

c) Doba přípravy – každá modernizace 

vyžaduje dobu pro návrh a odzkoušení před 

tím, než je připravena k zavedení do 

provozní platformy. Na ukončení návrhu 

a testování v době mezi zahájením návrhu 

modernizace a zavedením návrhu je 

samozřejmě zapotřebí dostatek času. Během 

této doby se musí věnovat pozornost mnoha 

činnostem zabezpečení, včetně veškerého 

nezbytného výcviku, změnám dokumentace, 

zavedení nových náhradních dílů a změn 

a doplňování prostředků pro zabezpečení. 

Důležitým faktorem, který bude diktovat 

dobu požadovanou pro výcvik, doplňování 

příruček atd., bude dopad na uživatele 

systému. (K posouzení těchto požadavků 

budou sloužit činnosti ILS.) 

the Prime Contractor under a firm price 

agreement, the cost will be constrained by 

the Prime’s desire to maximise profit (either 

short or long term). In the case of new 

requirements, the program manager CM will 

seek a minimum price with the IPT, who 

will in turn seek a minimum price from the 

Prime Contractor. Where some sort of cost 

sharing or gainshare scheme is involved, it 

will be in the interests of both the IPT and 

industry to keep upgrade costs to a 

minimum. In addition to Industry costs, 

there will be costs associated with 

acceptance of the modified system. 

b) Implementation Duration - The period for 

which an operational platform or installation 

is available for upgrade will be limited. 

Clearly it will be necessary to select an upgrade 

that can be successfully carried out 

within the available time. This duration must 

include not just the time to make the change 

itself, but also the time required for testing 

and acceptance of the upgraded system, and 

any associated training and support periods. 

It will also be constrained by the operational 

notice of the platform (i.e. the time within 

which the platform or installation needs to 

be capable of being returned to an operational 

state, should an urgent requirement 

occur). This will require an estimate of the 

worst case period needed to "roll back" an 

uncompleted upgrade, to return the equipment 

to its original state. This period will 

also need to allow for the event that the 

upgrade is implemented, but fails, and has to 

be rolled back. 

c) Preparation Period - Any upgrade will 

require time for its design and proving 

before it is ready to be implemented on an 

operational platform. Clearly there needs to 

be adequate time to complete design and 

testing between initiating an upgrade design 

and implementing it. In addition, many 

support activities must be addressed during 

this period, including any necessary training, 

changes to documentation, introduction of 

new spares and changes and additions to 

support facilities. The impact on system 

users will be an important factor, which will 

dictate the time required for training, 

handbook amendments etc. (ILS activities 

will assist with assessing these 

requirements.) 

44

d) Riziko – během provádění modernizace je 

žádoucí minimalizovat rizika. To zahrnuje: 

(1) časová měřítka (ve vztahu jak 

k přípravnému období, tak k samotné 

době trvání zavedení modernizace), 


1. vydání 

Oprava 1 

Příloha B 

d) Risk - It is desirable to minimise the risks in 

carrying out an upgrade. These include: 

(1) Timescale (relating to both the 

preparation period and the duration of 

implementing the upgrade itself), 

(2) náklady, (2) Costs, 

(3) dostupnost součástí, (3) The availability of components, 

(4) dostupnost cílové platformy. (4) The availability of the target platform. 

e) Dostupnost vhodných součástí – jestliže 

nejsou dostupné vhodné součásti, modernizaci 

není možné naplánovat. Součástmi jsou 

myšleny buď komerční produkty, nebo 

speciálně navržené hardwarové nebo softwarové 

součásti. Úvaha o tomto aspektu plánování 

modernizace bude kriticky závislá na 

dobré znalosti trhu. 

f) Četnost příležitostí – doba do příští příležitosti 

modernizovat jednotlivou platformu/ 

instalaci bude důležitým rysem při rozhodování 

o možnosti modernizace. Jestliže jsou 

příležitosti omezeny, pak může být důležité 

modernizaci provést, i kdyby bylo zapotřebí 

zkrátit rozsah, ale s ohledem na to, aby se 

náklady a riziko pohybovaly v přijatelných 

mezích. Na druhé straně, jestliže existuje pro 

modernizaci mnoho příležitostí, potom může 

být rozumné modernizaci posunout, aby se 

zajistilo, že jsou dostupné všechny součásti 

a že je zváženo riziko. 

g) Provozní potřeby specifické pro platformu – 

navíc k obecným požadavkům na zabezpečování 

informací nebo schopnosti modernizace 

existují často provozní okolnosti vztahující 

se ke specifickým platformám, které 

je třeba brát v úvahu. Například budoucí 

stanovení úkolů pro válečnou loď nebo 

letadlo může zdůrazňovat konkrétní schopnost 

a to stanoví priority při rozhodování, co 

bude zahrnuto do modernizace. 

h) Spojitost s jinými programy – aby stát 

vytěžil z jakékoliv investice maximum, je 

nezbytné, aby se v úvahu vzaly spojitosti 

s jinými programy. To je zejména oprávněné 

v oblasti C3I systémů 17 . Úvahy zahrnují 

údržbu rozhraní mezi systémy a používání 

společných součástí a procesů zabezpečení. 

V této oblasti bude hrát významnou úlohu 

e) Availability of Suitable Components - No 

planned upgrade will be possible if suitable 

components are not available. This will 

either be commercial products, or specially 

design hardware or software components. 

The consideration of this aspect in the 

planning of upgrades will be critically 

dependent on good market knowledge. 

f) Frequency of Opportunity - The time until 

the next opportunity to upgrade a particular 

platform/installation will be an important 

feature in deciding the scope of an upgrade 

event. If the opportunities are limited, then it 

may be important to carry out the upgrade, 

even if the scope needs to be curtailed to 

bring cost and risk within acceptable limits. 

On the other hand, if there are many 

opportunities for upgrade, then it may be 

sensible to postpone an upgrade in order to 

ensure that all components are available and 

that risk is contained. 

g) Platform Specific Operational Needs - In 

addition to the general requirement for an IA 

or capability upgrade, there will often be 

operational circumstances relating to 

specific platforms that should be taken into 

account. For example the future tasking for a 

warship or aircraft may emphasise the need 

for particular capabilities, and this will set 

priorities for deciding what is included in an 

upgrade. 

h) Relationship with Other Programmes - For 

the government to gain maximum value 

from any investments, it is essential that the 

relationships with other programmes are 

taken into account. This is particularly true 

in the field of C3I systems. Considerations 

include the maintenance of inter-system 

interfaces and the use of common 

17 C3I systems = Command, Control, Communications & Intelligence systems, tj. systémy velení, řízení, spojení 

a zpravodajské systémy. 

45


1. vydání 

Oprava 1 

Příloha B 

nadřízený orgán, který má dohled nad 

integrací systému nebo nad jeho 

interoperabilitou. 

components and support processes. A higher 

authority which oversees system to system 

integration or interoperability will have a 

significant role to play in this area. 

Obrázek 2 – Vzájemné vztahy mezi problémy modernizace 

Všechna tato hlediska mohou být porovnávána 

vzájemně mezi sebou, jak ukazuje obrázek 2. 

Například riziko by se mělo snižovat 

prodloužením doby návrhu, zvětšením velikosti 

týmu pro návrh (a z tohoto důvodu i nákladů na 

projekt) nebo odložením provedení 

modernizace, které umožní použití nového 

produktu. Podobně mohou být krácena časová 

měřítka modernizace díky zmenšení rozsahu 

modernizace nebo se uskuteční větší příprava 

(čímž se prodlouží doba návrhu a náklady). 

Nebo důležitější může být větší počet malých 

modernizací, než jediná rozsáhlá modernizace. 

Počet v jednom okamžiku rozpracovaných 

modernizací závisí na množství a typu 

zdrojových platforem nebo instalací. Kde je 

malý počet velkých jednotek (například řekněme 

skupina dvanácti válečných lodí) s omezenou 

příležitostí velkých modernizací (řekněme 

každých 5 let), existují pravděpodobně různé 

These aspects can all be traded off against each 

other, as shown in Figure 2. For example, risk 

could be reduced by lengthening the design 

period, increasing the size of the design team 

(and hence the project cost) or delaying the 

implementation of the upgrade to allow a new 

product to be used. Similarly, the upgrade 

timescale can be shortened by reducing the 

scope of the upgrade or by carrying out more 

preparation (and hence increasing the design 

period, and cost). Alternatively, there may be 

value in a number of small upgrades over a 

single large upgrade. 

The number of upgrades in process at any one 

time will depend on the number and type of 

target platforms or installations. Where there are 

a small number of large units (for instance a 

class of say twelve warships) with limited 

opportunities for major upgrades (say every 5 

years), there are likely to be different plans for 

46

plány pro každou jednotlivou platformu. 

Specifikovaný obsah modernizace bude 

schválen na počátku modernizace. Kde je velký 

počet platforem (jako např. skupina 100 letadel), 

pak se musí platformy rozdělit do skupin a jedna 

modernizace se provádí na více platformách. 


1. vydání 

Oprava 1 

Příloha B 

each individual platform. The specific contents 

of upgrades will be agreed close to the start of 

the upgrade. Where there are a large number of 

platforms (such as a fleet of 100 aircraft), then 

platforms may be batched, with a single upgrade 

being carried out to many platforms. 

Figure 2 - Interrelationship Between Upgrade Issues 

B.3 Plánování modernizace a proces řízení B.3 Upgrade Planning and Management 

Process 

Plánování a dodávání modernizací je ústřední 

činností IPT při poskytování a udržování 

schopnosti ve vztahu ke svým zákazníkům 

během etapy provozu. Je nezbytné, aby se vzaly 

v úvahu různé výše diskutované aspekty 

a optimalizovaly se nejvýhodnějším způsobem. 

Tento proces zahrne širokou řadu zadavatelů, 

včetně IPT, manažera programu, koncového 

uživatele a zprostředkovatele integrace. 

Každý IPT musí vyvinout proces pro plánování 

a řízení modernizací. Tento proces musí 

umožnit, aby při vývoji cenově nejefektivnějšího 

programu modernizace systému byly vzaty 

v úvahu i pohledy zadavatelů. 

The planning and delivery of upgrades will be 

the central activity of the IPT in providing and 

sustaining capability to its customers during the 

in-service phase. It is essential that the various 

aspects discussed above are considered and 

traded off in the most advantageous manner. 

This process will involve a wide range of 

stakeholders, including the IPT, Program 

Manager, End user, and Integration Agent. 

Each IPT will have to develop a process for 

planning and managing upgrades. This process 

will have to allow the views of all stakeholders 

to be taken into account in the development of 

the most cost-effective upgrade program for the 

system. 

47


1. vydání 

Oprava 1 

Příloha B 

Minimálně se to týká představitelů: Those involved will include (at least) 

representatives from the following: 

a) IPT (včetně programového manažera 

projektu, manažera pro zabezpečení, 

manažera požadavků, manažera komerčního 

pořizování a stejně tak i představitelů 

průmyslu), 

a) IPT (including Project Programme Manager, 

Support Manager, Requirements Manager, 

Commercial Manager, as well as the 

Industry representatives) 

b) koncového uživatele, b) End user 

c) zprostředkovatele integrace. c) Integration Authority 

V některých případech může být vhodné začlenit 

představitele dalších IPT a přitáhnout odborníky 

z oblastí zabezpečení služeb (např. publikace, 

přeprava, bezpečnost), vědecký a výzkumný 

personál. 

Během plánování modernizace musí IPT 

vytvořit plán pro průběh životního cyklu, 

v němž vezme v úvahu: 

In some cases it may be appropriate to include 

representatives from other IPTs, and to draw 

specialists from service support areas (e.g. 

publications, transport, safety), scientific and 

research staff. 

In planning upgrades, the IPT will have to 

develop through life plans for the system, taking 

into consideration: 

a) současné požadavky na schopnosti, a) Current capability requirements, 

b) plánované zvýšení schopností, b) Planned increments in capability, 

c) předpověď budoucích schopností a úsilí, c) Future capability predictions and aspirations, 

d) dlouhodobé financování, d) Long term funding, 

e) vývoje u paralelních systémů, e) Developments in parallel systems, 

f) vývoje komerčních technologií (na základě 

rad od vědeckého personálu a průmyslu). 

Pro modernizace v blízkém plánovaném 

časovém horizontu bude mít IPT potřebu stále 

brát v úvahu dlouhodobější hlediska (viz výše), 

ale bude zvažovat podrobněji: 

f) Developments in commercial technology 

(taking advice from scientific staff and 

industry). 

For upgrades within a closer planning horizon, 

the IPT will still need to take into account the 

longer term aspects (as above), but consider in 

more detail: 

a) možnosti platformy, a) Platform opportunities, 

b) předpovězené problémy se zastaráváním, b) Predicted obsolescence problems, 

c) dostupnost vhodné technologie pro vkládání 

schopnosti a technologie, 

c) Availability of suitable technology for 

capability and Technology insertions 

d) současné programy modernizace, d) Current upgrade programmes, 

e) financování, e) Funding, 

f) specifické požadavky schopností platformy, f) Specific platform capability requirements, 

g) časová měřítka programu modernizace. g) Upgrade programme timescales. 

Tato nerovnováha umožňuje vedoucímu IPT 

přijímat rozhodnutí týkající se plánů 

modernizace, včetně: 

These deliberations will allow the IPTL to make 

decisions regarding upgrade plans, including: 

a) rozsah modernizace, a) Scope of upgrade, 

b) časového harmonogramu modernizace, b) Upgrade timescales, 

c) možností cílové platformy/instalace c) Target platform(s)/installation(s) and 

48


1. vydání 

Oprava 1 

Příloha B 

a možností instalace 

installation opportunities, 

d) smluvních/komerčních důsledků. d) Contractual/commercial implications. 

B.4 Smluvní ujednání o modernizacích B.4 Contractual Arrangements for Upgrades 

Protože přístup IPT může podporovat otevřené 

a na důvěře založené vztahy mezi státem 

a průmyslem, je třeba jej uzavřít do smluvní 

podoby. Optimální komerční vztah mezi státem 

a průmyslem pro řízení modernizací není ihned 

zřejmý. Musí: 

While the IPT approach can foster an open and 

trusted relationship between the government and 

industry, it needs to be encapsulated in 

contractual form. The optimum commercial 

relationship between the government and 

industry for managing upgrades is not 

immediately obvious. It must: 

a) nabídnout důvěru oběma partnerům, a) Offer confidence to both parties, 

b) být dostatečně flexibilní, aby si poradil 

s neočekávanými požadavky, 

c) poskytovat podněty pro osvojení přístupu, 

který se týká průběhu životního cyklu, 

d) poskytnout vedoucímu IPT práva, která 

potřebuje k efektivnímu řízení programu, 

b) Be flexible enough to cope with unexpected 

requirements, 

c) Give incentives for adopting a through life 

approach, 

d) Provide the IPT leader with the control he 

needs to manage the programme effectively. 

e) zajistit průmyslu odpovídající zisk. e) Ensure adequate profit for industry. 

Klíčovým požadavkem je takové uspořádání, 

které umožňuje úsporu nákladů, které si mezi 

sebe dělí stát a hlavní dodavatel, společně se 

snižováním nákladů státu na zabezpečení 

a zlepšováním návratnosti investic hlavnímu 

dodavateli. Bylo by pak v zájmu hlavního 

dodavatele ušetřit na nákladech v průběhu 

životnosti systému a pro další léta určit roční 

úspory, které splní cíle pro úspory. Některé 

přijatelné modely jsou diskutovány níže. 

A key requirement is an arrangement that allows 

cost savings to be shared between the 

government and the Prime Contractor, with the 

government getting lower support costs, and the 

Prime Contractor getting an improved return on 

investment. It would then be in the interests of 

the Prime Contractor to save costs throughout 

the life of the system, and to identify further year 

on year savings to meet savings targets. Some 

possible models are discussed below. 

B.5 Smlouvy na logistické zabezpečení 

prováděné dodavatelem 

Standardní řešení, jak má stát snižovat rizika 

a dosáhnout cenově efektivního zabezpečení 

systému je často spatřováno ve smlouvách na 

logistické zabezpečení prováděné dodavatelem 

(CLS). CLS má zajisté mnoho výhod včetně 

snížení finančního rizika státu a jednoznačnosti 

odpovědností. U systémů založených na COTS, 

kromě těch, které jsou zabezpečovány jinými 

stimulujícími schématy, však existuje nebezpečí, 

že tradiční smlouva na CLS může přispívat ke 

zvyšování zastarávání a zvýšení nákladů na 

průběh životního cyklu. 

Systémy založené na COTS trpí rychlým 

zastaráváním, které vede k potřebě neustálého 

obnovování technologií, pokud mají systémy 

zůstat zabezpečovatelné. Pokud hlavní dodavatel 

B.5 CLS Contracts 

Contractor Logistic Support (CLS) contracts are 

often seen as a standard solution for reducing 

risk on the government and gaining cost 

effective support for a system. CLS certainly has 

many advantages, including reduction of the 

government’s financial risk and clarity of 

responsibility. However, for COTS-based 

systems, there is a danger that, unless supported 

by other incentive schemes, the traditional CLS 

contract can contribute to increased 

obsolescence and higher through life costs. 

COTS-based systems suffer from rapid 

obsolescence, leading to the need for continuous 

technology refresh if they are to remain 

supportable. If a Prime Contractor accepts a firm 

49


1. vydání 

Oprava 1 

Příloha B 

schválí pevnou cenu smlouvy na CLS řekněme 

na pět let po schválení do provozu, pak bude mít 

závazek zabezpečovat systém a bude v jeho 

zájmu nenechat v tomto období na systém 

působit problémy se zastaráváním. Nebude si 

však přát utratit více peněz, než je nezbytné pro 

splnění smluvních závazků. Jak se bude 

přibližovat konec období CLS, nebude systém 

vyžadovat další obnovování technologií, aby si 

udržel po zbytek období výkonnost. Tento bod 

nastane někdy okolo tří let před koncem tohoto 

období. Hlavní dodavatel nemá žádné zřetelné 

pobídky, aby podnikal jakoukoliv činnost 

zaměřenou na snižování budoucího zastarávání 

během těchto tří let. Výsledkem bude, že na 

konci období CLS nebude možné systém 

zabezpečovat. 

Aby se tomu zabránilo, existuje potřeba 

poskytnout hlavnímu dodavateli pobídky 

k tomu, aby se náklady na zastarávání v průběhu 

životního cyklu udržely na nízké úrovni. Jedině 

pevné období pro CLS bez dalších závazků nebo 

vazeb představuje pobídku, která udrží náklady 

na zastarávání během smluvního období na 

nízké úrovni. Jestliže je toto dáno, bude skutečně 

obtížné změnit hlavního dodavatele a cynikové 

by mohli namítat, že bylo skutečně v zájmu 

hlavního dodavatele dodat za pevnou cenu na 

konci smlouvy na CLS v podstatě zastaralý 

systém. To proto, že by hlavní dodavatel věděl, 

že smlouvu na uvedení systému zpět do 

přijatelného stavu by pravděpodobně dostal on. 

Tyto problémy lze vhodně vylepšit tak, že se do 

smlouvy na CLS vloží ustanovení, které bude 

požadovat, aby hlavní dodavatel dodal systém, 

který není na konci období zabezpečování 

zastaralý. Takové ustanovení však může být 

obtížné definovat nebo prosadit. Chtělo by to 

vzbudit pozornost dodatkovou prémii za rizika, 

vloženou do ceny nabízené hlavnímu dodavateli 

ve smlouvě na CLS. 

price CLS contract for, say, the five years 

following ISD then he will be under an 

obligation to support the system, and hence it 

will be in his interests to keep the system free 

from obsolescence problems during this period. 

However, he will not wish to spend more money 

than is necessary to meet his contractual 

commitments. As the end of the CLS period 

approaches, the system will require no further 

technology refresh to maintain its performance 

for the remainder of the period. This point will 

probably be some three years before the end of 

the period. The Prime Contractor has no obvious 

incentive to undertake any work to mitigate 

against future obsolescence during these three 

years. The result will be that at the end of the 

CLS period, the system will be about to become 

unsupportable. 

To avoid this, there is a need to provide the 

Prime Contractor with the incentive to keep the 

through life cost of obsolescence low. A fixed 

period CLS period, with no further obligation or 

commitment, will only provide an incentive to 

keep the obsolescence cost low during the 

contracted period. In fact, given that it will be 

difficult to change the Prime Contractor, cynics 

might argue that it was actually in the Prime 

Contractor’s interests to deliver a near 

obsolescent system at the end of a firm price 

CLS contract. This is because the Prime 

Contractor would know that the contract for 

bringing the system back into an acceptable state 

would probably fall to him. 

It may be possible to ameliorate these problems 

by including a clause in the CLS contract 

requiring the Prime Contractor to deliver a 

system that is free from obsolescence at the end 

of the period. Such a clause may, however, 

prove difficult to either define or enforce. It 

would also attract an additional risk premium in 

the price the Prime Contractor offered for the 

CLS contract. 

B.6 Hlavní zabezpečení a úkolování B.6 Core Support plus Tasking 

Alternativou ke standardnímu modelu CLS je 

vztah založený dlouhodobě na hlavním úkolu 

zabezpečení s doplňkovými, samostatně 

financovanými úkoly, pokrývajícími specifické 

činnosti. 

Hlavní úloha by mohla stanovit činnosti pro 

základní spolupráci mezi hlavním dodavatelem 

An alternative to the standard CLS model is a 

relationship based on a long-term core support 

task, with additional, separately costed tasks to 

cover specific activities. 

The core task would provide for the basic liaison 

activities between the Prime Contractor and the 

50

a zbývající částí IPT. Mohla by také nabídnout 

průmyslu zaměření na životní cyklus a na určité 

dlouhodobé zajišťování jeho role při 

zabezpečení systému. 

Specifické úkoly by měly zahrnovat: 

a) řízení a provádění činností zabezpečení 

(jako je řízení konfigurace, dodávání 

a management náhradních dílů, údržba 

prováděná na základně/v opravně), 

b) návrh a dodání modernizace systému, který 

je založen na specifikacích a odpovědnostech 

odsouhlasených IPT, 

c) úkoly teoretického návrhu a výzkumu, 

u nichž je nežádoucí, aby je mohl průmysl 

provádět sám, ale které by mohly být 

komerčně životaschopné, pokud jejich rizika 

(a možný profit) budou sdílena se státem, 


1. vydání 

Oprava 1 

Příloha B 

rest of the IPT. It would also offer a through life 

focus for industry, and some long-term 

assurance of their role in supporting the system. 

Specific tasks could cover: 

a) Management and conduct of support 

activities (such as configuration control, 

spares supply and management, base/factory 

maintenance) 

b) Design and delivery of system upgrades, 

based on specifications and responsibilities 

agreed with the IPT. 

c) Speculative design and research tasks that 

industry would be unwilling to conduct 

alone, but which would be commercially 

viable if the risk (and potential gains) were 

shared with the government. 

d) dodání dalších instalací systémů. d) Delivery of additional system installations. 

Mechanismus financování úloh má být 

odsouhlasen mezi vedoucím IPT a jeho partnery 

z průmyslu. V některých případech by měl být 

povolen režim fixních/pevných cen, ale zde má 

existovat dostatek příležitostí pro přijetí 

inovačních opatření, které připouštějí rozdělení 

zisku a vzájemný prospěch. 

The funding mechanism for the tasks should be 

agreed between the IPTL and his industry 

partners. In some cases a fixed/firm price regime 

would be appropriate, but there should be ample 

scope for adopting innovative arrangements to 

allow for gain share and mutual benefit. 

51


1. vydání 

Oprava 1 

Příloha C 

Management náhradních dílů 

a management konfigurací 

Využití COTS produktů jako základ systému 

představuje množství problémů, které souvisí 

s dodáváním a managementem náhradních dílů 

hardwaru a které jsou úzce spjaty s managementem 

konfigurací systému. Tento oddíl posuzuje 

některé z těchto problémů a doporučuje brát 

v úvahu některé faktory a některá možná řešení. 

Annex C Spares Management and 

Configuration Management 

The use of COTS products as the basis of a system 

introduces a number of issues relating to the 

supply and management of hardware spares, and 

the closely related issue of system configuration 

management. This section explores some of 

these issues and suggests some factors for 

consideration and some possible solutions. 

C.1 Problémy spojené s COTS C.1 COTS Related Issues 

Charakteristiky COTS spojené s náhradními díly 

a managementem konfigurací jsou: 

a) COTS produkty obecně jsou relativně 

krátkodobě dostupné a mají krátkou dobu 

provozní životnosti, po níž budou nahrazeny 

novým produktem a původní verze nebude 

již dále dostupná. Komerční tlaky obecně 

diktují některá opatření pro zachování 

zpětné kompatibility s předchozí verzí, ale 

také diktují, že nová verze bude mít odlišnou 

funkci a/nebo technické parametry. 

b) Mnoho hardwarových COTS produktů bude 

pracovat pouze s příslušným softwarovým 

řídicím programem. Pokud je produkt 

nainstalován, bude třeba tyto programy 

zpřístupnit. 

c) Součásti systémů založených na COTS jsou 

často těsně vzájemně závislé na dalších 

součástech, což znamená, že změna u jedné 

části může způsobit změny dalších. 

d) Široce kompatibilní COTS produkty 

s běžnými funkcemi jsou často dostupné 

z velkého počtu zdrojů, ale nejsou nutně vyrobeny 

podle stejných konstrukčních 

standardů. 

COTS characteristics related to spares and 

configuration management include: 

a) COTS products generally have a relatively 

short availability and in-service life period, 

after which they will be replaced by a new 

product, and the original version will no 

longer be available. Commercial pressures 

generally dictate some measure of backward 

compatibility with the previous version, but 

they also dictate that the new version will 

have different functionality and/or 

performance. 

b) Many COTS hardware products will only 

work with appropriate software drivers. 

These drivers will need to be available when 

the product is installed. 

c) Components in COTS-based systems often 

have close interdependencies with other 

components, meaning that changing one part 

can force the changing of others. 

d) Broadly compatible COTS products for 

common functions are often available from a 

range of sources, but not necessarily to the 

same build standards. 

C.2 Management konfigurací 18 C.2 Configuration Management 

Základní principy managementu konfigurací 

jsou stejně důležité jak pro systémy založené na 

COTS, tak pro jakoukoliv jinou akvizici. 

Používání COTS však představuje některé další 

problémy. 

Požadavky a návod pro management konfigurací 

The basic principles of Configuration 

Management are as important for COTS-based 

systems as they are for any other acquisition. 

However, the use of COTS introduces some 

additional issues. 

Requirements and guidance for configuration 

18 Pro management konfigurací platí v ČR ČOS 051605 až 051611. 

52

jsou obsaženy v mnoha dokumentech 19 (tyto 

zahrnují: 

- Doplňující informace AMS – Management 

konfigurace, verze 1.0, duben 1999, 

- Def-Stan 05-57 – Management konfigurace 

vojenského materiálu, vydání 5, 

17.6.2003, 

- MIL-HDBK-61A – Návod k managementu 

konfigurací, 7. 2. 2001 (zejména 

příloha C: Návod k managementu 

konfigurace při integraci často 

používaných komerčně nakupovaných 

produktů). 

Systém pro řízení akvizicí v resortu MO vyžaduje, 

aby vznikl systém pro management 

konfigurací, poskytující záznamy změn během 

technického života systémů a ukazující 

závislosti mezi produkty a jejich podsystémy 

nebo součástmi. 

Specifické problémy managementu konfigurací 

souvisící s COTS zahrnují: 

a) Zdokonalené systémy založené na COTS 

jsou podrobovány častým změnám návrhu, 

buď aby snížily vlivy zastarávání, nebo 

včlenily novou funkci. 

b) Hardwarové COTS položky jsou často 

vyráběny po krátkou dobu. Jakmile se 

jednou ukončí pořizování náhradních dílů, 

bude při budoucím pořizování 20 obecně 

nemožné zakoupit identické náhradní díly. 

c) Uspořádání pro management konfigurací, 

jak je provozováno prodejci COTS, není tak 

přísné, jako v případě použití tradičními 

vojenskými dodavateli. Pro hlavního 

dodavatele nemusí být obvyklé, aby se 

během pořizování měnila verze produktu. 

d) Informace poskytované o COTS položce 

jsou obecně omezené, běžně na instrukce 

pro provoz a instalaci, základní instrukce pro 

údržbu (pokud jsou potřeba) a popis 


1. vydání 

Oprava 1 

Příloha C 

management are contained in a number of 

documents (including: 

- AMS Additional Information - 

Configuration Management, v1.0 dated 

April 1999, 

- Def-Stan 05-57, Defense Standard 05-57 

"Configuration Management", Issue 3, 30 

July 1993. (Issue 4 is currently in 

preparation) 

- Mil-HDBK-61, US Department of Defense 

Military Handbook 61 "Configuration 

Management Guidance", 30 

September 1997, (particularly Appendix 

C "CM Guidance for integration of High 

Intensity Commercial-Off-The-Shelf 

Products"). 

The AMS requires that a Configuration 

Management system is produced, providing a 

record of changes throughout the life of the 

systems and showing any dependencies between 

products and their sub-systems or components. 

Specific configuration management issues 

relating to COTS include: 

a) A mature COTS-based system is subject to 

frequent design changes, either to mitigate 

the effects of obsolescence or to incorporate 

new functionality. 

b) COTS hardware items often have a short 

production lifetime. Once a buy of spares is 

complete, it will generally be impossible to 

buy identical spares in a future buy 20 . 

c) The configuration management scheme 

operated by the COTS vendor is unlikely to 

be as rigorous as that operated by a 

traditional military supplier. It may not be 

obvious to the Prime Contractor that a 

product version has changed between buys. 

d) The information provided with a COTS item 

is generally limited, typically to operating 

and installation instructions, basic maintenance 

instructions (where appropriate) and a 

19 V ČR jsou pro zavedení postupů managementu konfigurací určeny ČOS 051605 až ČOS 051611. 

20 Bylo navrženo, že tento problém lze překonat nákupem náhradních dílů pro „celý život“ nebo „dobu 

životnosti“. Tento přístup není všelékem, jak je uvedeno v článku C.6 Nakupování v průběhu životního cyklu. 

It has been suggested that this problem can be overcome by a "whole life" or "lifetime" buy of spare parts. 

This approach is not a panacea, as discussed in paragraph C.6. 

53


1. vydání 

Oprava 1 

Příloha C 

součástí, které lze nahradit, aniž by to 

ovlivnilo záruky. Získat další informace 

bývá drahé a v případě, že se položka změní, 

je zapotřebí je udržovat a aktualizovat. 

e) Hardwarové COTS položky často závisí na 

vyhrazených softwarových ovladačích. Pro 

management konfigurací, dodávky náhradních 

dílů a systém údržby musí být 

rozeznatelný vzájemný vztah mezi 

hardwarem a jeho ovladači. 

f) Pokud se rychlost změn zkombinuje 

s velkým počtem COTS součástí a omezenými 

možnostmi pro modernizaci systému, 

povede to k rozmanitosti jednotlivých 

instalací (nebo podsystémů v těchto instalacích). 

To u velkého souboru různých položek 

znamená potřebu provádět podrobné 

monitorování konfigurací až na úroveň 

významných podrobností. 

g) Vzájemné vztahy mezi COTS produkty jsou 

složité a pokud se zkouší určitá konfigurace 

při vývoji nebo v provozním prostředí, jejich 

závislosti nejsou někdy odhaleny. Systém 

managementu konfigurací musí zaznamenat 

a řídit mnoho složitých vzájemných vztahů. 

h) COTS software, zejména nová verze, má 

často chyby nebo vykazuje neočekávané 

chování, které zůstává skryto, dokud není 

software včleněn do systému. Obvykle se 

většina těchto problémů vyřeší dialogem 

s dodavatelem softwaru, který se může vyskytovat 

kdekoli na světě nebo tak, že budou 

poskytnuty některé doplňkové kódy. Tyto 

malé změny v návrhu systému se budou měnit 

od konfigurace ke konfiguraci, ale budou 

kritické ve vztahu k určité konfiguraci, která 

pracuje správně. Jestliže má být zachována 

úplná znalost o konfiguraci, bude zapotřebí 

zahrnout všechny tyto změny do systému 

managementu konfigurací. 

i) Krátká životnost většiny komerčních produktů 

znamená, že data o bezporuchovosti, 

jako je střední doba mezi poruchami 

(MTBF), jsou často nedostupná. Tento problém 

je zhoršován skutečností, že komerční 

součásti jsou obecně používány v prostředí, 

které se liší od možných drsných podmínek, 

ve kterých, jak se očekává, vydrží vojenský 

systém. 

description of parts that can be replaced 

without invalidating the warranty. Further 

information will be expensive to gather, and 

will need to be maintained and updated 

whenever the item is changed. 

e) COTS hardware items often rely on 

dedicated driver software. The configuration 

management, spares supply and maintenance 

system must recognise the interrelationship 

between the hardware and its driver. 

f) The pace of change, when combined with 

the large number of COTS components and 

the limited opportunities for system 

upgrades, will tend to increase the diversity 

of individual installations (or of sub systems 

within those installations). This implies a 

need to carry out detailed configuration 

monitoring, to considerable detail, for a 

large population of different items. 

g) The interrelationships between COTS 

products are complex and dependencies are 

sometimes only uncovered when a particular 

configuration is tried in the development or 

operational environment. The configuration 

management system will have to record and 

manage many complex relationships. 

h) COTS software, especially a new issue, 

often has bugs or exhibits unexpected 

behaviour that is not uncovered until the 

software is incorporated into a system. 

Typically, many of these problems are 

solved by dialogue with the software 

supplier(s), who may offer a workaround or 

provide some additional code. These minor 

system design changes will vary from configuration 

to configuration, but will be 

crucial to a particular configuration operating 

correctly. All such changes will need to 

be incorporated into the configuration 

management system if full knowledge of the 

configuration is to be maintained. 

i) The short life of most commercial products 

means that reliability data, such as mean 

time between failure (MTBF), is often 

unavailable. This problem is exacerbated by 

the fact that commercial components are 

generally used in an environment which is 

different from the potentially harsh 

conditions that a military system may expect 

to meet. 

54

C.3 Management náhradních dílů C.3 Management of Spares 

Typický systém založený na COTS bude 

obsahovat velké množství hardwarových COTS 

položek. V mnoha případech bude mít jednotlivá 

položka pouze omezenou výrobní životnost, po 

jejímž uplynutí prodejce začne s výrobou nové 

verze. Je jasné, že COTS produkt nebude od 

výrobce dostupný po celou dobu životnosti 

systému. 

Při pořizování nahrazující položky se vzácně 

stane, že je identická s původní položkou. 

Hlavní dodavatel po poradě s koncovým 

uživatelem bude potřebovat posoudit, zda může 

být nová položka použita pro přímou náhradu. 

Toto rozhodnutí bude často vyžadovat testování 

v existujícím systému, aby se posoudila 

kompatibilita. 

Když je zaváděna nahrazující položka, může 

vyjít najevo, že poskytuje charakteristiky 

identické s originálem a tak existuje snaha 

pokládat tyto dvě verze za zaměnitelné. Změny 

jiných součástí v systému však mohou odhalit 

důležité rozpory v chování těchto dvou verzí. To 

znamená, že pokud se objeví nová verze, která 

se jeví jako zcela zaměnitelná, musí se různé 

verze sledovat systémem managementu 

konfigurací jako ochrana před budoucí 

nekompatibilitou. (Pro ilustraci uvažujme 

následující příklad. Dodavatelem COTS je 

zavedena nová grafická karta. Při testování na 

všech konfiguracích systému vykazuje přesně 

stejnou funkci a výkon jako původní a je fyzicky 

zaměnitelná. Učiní se rozhodnutí, že se na tyto 

dvě verze bude pohlížet jako na výkonově 

zaměnitelné, se stejným tvarem, vhodností 

a funkcí. Někdy později je však zaveden nový 

operační systém a odhalí se, že tento pracuje 

správně s novou grafickou kartou, ale ne se 

starou verzí. Protože byly tyto dvě verze 

považovány za zaměnitelné, již nikdy se 

nerozliší, která pracovní stanice obsahuje kterou 

verzi a tudíž která může hostit nový operační 

systém.) 

Podle toho, jak se rozvíjí návrh/zavedení 

systému, který má buď co do činění se 

zastaralými součástmi, nebo přidává novou 

funkci, bude existovat potřeba posoudit 

přijatelnost nových verzí návrhu s aktuálně 

drženými náhradními díly. Toto posouzení musí 

zahrnovat hardwarové položky, technické 


1. vydání 

Oprava 1 

Příloha C 

A typical COTS-based system will contain a 

large number and variety of COTS hardware 

items. In many cases the individual items will 

only have a limited production life, after which 

the vendor will shift production to a new 

version. It is clear that the COTS product will 

not be available from the manufacturer for the 

whole life of the system. 

When a replacement item is purchased, it will 

rarely be identical to the original item. The 

Prime Contractor in consultation with the end 

user will need to assess whether the new item 

can be used as a direct replacement. This 

decision will often require testing against 

existing systems to assess compatibility. 

When a replacement item is introduced it may 

appear to offer identical characteristics to the 

original, and there will be the temptation to treat 

the two versions as interchangeable. However, 

changes to other components in a system may 

reveal important differences in behavior between 

the two versions. This implies that even if a new 

version appears to be completely 

interchangeable, the different versions will have 

to be tracked by the configuration system, to 

guard against future incompatibility. (To 

illustrate this, consider the following example. A 

new graphics card is introduced by the COTS 

supplier. When tested against all system 

configurations it exhibits exactly the same 

functionality and performance as the original, 

and is physically interchangeable. The decision 

is taken to regard the two versions as effectively 

interchangeable, with the same "form, fit and 

function". Some time later, however, a new 

operating system is introduced, and it is 

discovered that this operates correctly with the 

new graphics card, but not with the old version. 

Since the two versions were considered 

interchangeable, it is no longer possible to know 

which workstations have which version, and 

hence which can host the new operating system.) 

As the design/implementation of the system 

develops, either to deal with obsolescent 

components or to add new functionality, there 

will be a need to assess the acceptability of the 

new design versions with currently held spares. 

This assessment must include hardware items, 

infrastructure hardware and software, 

55


1. vydání 

Oprava 1 

Příloha C 

vybavení infrastruktury a software, aplikace 

a rozhraní. 

Musí být udržována kompatibilita různých 

konfigurací, aby: 

a) byla poskytnuta informace pracovníkům 

v „první linii“ údržby o tom: 

applications and interfaces. 

The compatibility of different configurations 

will have to be maintained in order to: 

a) Provide information to front line maintainers 

on: 

(1) jak konfigurovat systémy, (1) How to configure systems, 

(2) jaké náhradní díly jsou pro kterou 

konfiguraci vhodné, 

(3) Jaké programové zabezpečení (ve 

formě ovladačů) je zapotřebí pro 

různé součásti. 

b) bylo stanoveno, které vhodné náhradní díly 

různého druhu jsou k dispozici a kde je 

skladováno příliš mnoho náhradních dílů, 

nebo kde nejsou dále zapotřebí, 

c) byla poskytnuta informace týkající se toho, 

ve kterém systému může běžet která verze, 

aby mohly být řízeny provozní následky, 

d) byla plánována modernizace existujících 

implementací. 

(2) What spares are suitable for what 

configurations, 

(3) What software support (in the form of 

drivers) is needed for different 

components. 

b) Identify whether sufficient spares of 

different types are held, and where spare 

parts are overstocked or no longer required, 

c) Provide information as to what software 

versions can be run on which systems, in 

order that the operational implications can 

be managed, 

d) Plan upgrades of existing implementations. 

C.4 Náhradní díly a proces managementu 

konfigurací 

Máme-li se zabývat problémy diskutovanými 

v kapitolách C.1 a C.2, je nutné přijmout takový 

přístup, který minimalizuje úsilí (a tím náklady) 

pokud se udržuje příslušné řízení konfigurace 

a dostupnost náhradních dílů. 

Tak, jak je rozvíjen návrh dodávání systému 

založeného na COTS, je definována konfigurace 

hardwaru a softwaru. Jednotlivá konfigurace 

může být svázána s konkrétní instalací, nebo 

s reprezentantem skupiny stejných instalací. 

Jakmile je jednou systém provozován, 

konfigurace jeho hardwaru se bude vyvíjet podle 

toho, jak se budou měnit součásti, buď díky 

náhradám po defektu nebo díky modernizaci 

součástí, působící proti zastarávání. Změny 

konfigurace musí být dokumentovány z důvodu 

efektivního řízení zabezpečení náhradními díly, 

údržby a rozvoje systému. 

Různorodost konfigurací systému, který se 

vyvíjí, zavádí do procesu managementu 

konfigurací významnou složitost, a z hlediska 

nákladů může být efektivní omezit počet 

C.4 Spares and Configuration Management 

Process 

In order to address the issues discussed in 

paragraphs C.1 to C.2, it will be necessary to 

adopt an approach that minimizes effort (and 

hence cost) while maintaining appropriate 

configuration control and spares availability. 

As the design for a delivery of a COTS-based 

system is developed, the hardware and software 

configuration is defined. A particular 

configuration may be related to a particular 

installation, or representative of a batch of 

identical installations. 

Once the system is in service, its hardware 

configuration will develop as components are 

changed either due to defect replacement or as 

components are upgraded to counter 

obsolescence. The configuration changes will 

have to be documented in order to manage 

spares support, maintenance and system 

development effectively. 

The diversity of system configurations that 

develop will introduce significant complexity 

into the process of configuration management, 

and it may be cost effective to limit the number 

56

existujících konfigurací. To by mohlo být 

provedeno výměnou součástí při modernizaci, 

a to dokonce i tam, kde byla existující součást 

účinná a jinak by nepotřebovala výměnu. 

Omezení nákladů by muselo být u takovéhoto 

přístupu předmětem podrobného rozboru. 

C.5 Licence k produktům a technická 

podpora 

Softwarové COTS produkty jsou řízeny 

licencemi, buď pro konečného uživatele (často 

jsou nazývány licence pro provozování) nebo 

pro vývoj (licence na vývoj). Ta druhá je těsně 

spjata s dohodou o podpoře vývoje, na jejímž 

základě poskytuje prodejce softwaru vývojáři 

technickou podporu, menší modernizace 

a opravy chyb. Tato služba podpory je buď 

zahrnuta v licenci na vývoj, nebo se platí 

odděleně. 

Dodržování příslušných podmínek licence je 

kritické ve vztahu k úspěšnému vývoji 

a polnímu použití systémů založených na COTS. 

Pokud se týče uživatelských licencí, existuje 

množství nástrah, do kterých by se mohl 

neopatrný vedoucí IPT chytit. Mohou zahrnovat 

následující: 

a) Licence má umožnit použití jak pro 

vývojáře, tak pro uživatele. 

b) Většina licencí obsahuje podmínku jako 

například: „Prodejce neposkytuje žádné 

záruky, že software neobsahuje chyby“. 

c) Stát se má pojistit proti problémům, které 

vznikají ze sporů o vlastnická práva na 

software. 

d) Stát nebo jeho smluvní dodavatelé mohou 

mít přání týkající se modifikací softwaru 

(ačkoliv se to z mnoha důvodů 

nedoporučuje). 

e) Jestliže by chtěl prodejce softwaru ukončit 

obchodování, stát by měl chtít získat práva 

na zdrojové kódy a podpůrnou dokumentaci 

tak, aby mohl pokračovat v užívání a údržbě 

softwaru. 


1. vydání 

Oprava 1 

Příloha C 

of extant configurations. This could be done by 

replacing components at upgrade, even where 

the existing component was effective and would 

not otherwise need to be changed. The cost 

effectiveness of this approach would have to be 

subject to detailed study. 

C.5 Product Licenses and Technical Support 

COTS Software products are governed by 

licenses, both for end users (often termed "runtime" 

licenses) and for development 

(development licenses). The latter are closely 

related to development support agreements, 

under which a software vendor will provide 

technical support, minor upgrades and bug fixes 

to a developer. These support services are either 

included with development licenses or sold 

separately. 

Achieving appropriate license terms is crucial to 

the successful development and fielding of 

COTS-based systems. 

With respect to user licenses, there are a number 

of pitfalls that could trap the unwary IPT. These 

include the following: 

a) The licence should allow use by both 

developers and end users. 

b) Many licences include terms such as: "The 

vendor disclaims any warranty that the 

software will be error free." 

c) The government should indemnify itself 

against problems arising from disputes 

regarding the intellectual property rights of 

the software. 

d) The government or its contractors may wish 

to modify the software (although this is not 

recommended for a number of reasons). 

e) Should the software vendor go out of 

business, the government would wish to 

have the right to the source code and 

supporting documentation so that the 

software could continue to be used and 

maintained. 

C.6 Pořizování v průběhu životního cyklu C.6 Whole Life Buys 

Jako strategie týkající se zastarávání hardwaru je 

často navrhováno pořizování v průběhu 

Whole life buys (or "Through life buys" or 

"Lifetime buys") are often proposed as a strategy 

57


1. vydání 

Oprava 1 

Příloha C 

životního cyklu (pořizování během životnosti). 

Zkušenosti bohužel ukazují, že toto řešení je 

zřídka reálné. Důvody lze rozdělit do několika 

kategorií, které jsou popsány níže. 

Systémy založené na COTS často vykazují 

silnou vzájemnou závislost mezi svými 

součástmi a obzvlášť mezi softwarem (jak 

infrastrukturou, tak aplikacemi) a hardwarem, na 

němž běží. V komerčním světě je samozřejmostí 

modernizace nového procesoru a konfigurují se 

nové operační systémy, aby pracovaly na 

novějším hardwaru, to vše s využitím nižšího 

poměru výkon/cena, který se díky technologiím 

dodává již více než 20 let. Tímto způsobem 

zastavuje užívání novějšího softwaru 

zabezpečení staršího, méně běžného hardwaru, 

neboť tento již není komerčním případem, pro 

nějž by se na takovém malém trhu mělo 

vynakládat úsilí. Logickým důsledkem je, že 

jestliže se tedy hardware nemodernizuje 

v krátkém časovém měřítku, nemůže být dále 

modernizován software a celý systém začíná 

zaostávat za stavem techniky. To má 

samozřejmě přímý vliv na schopnost systému 

reagovat na moderní hrozby a útočníky, kteří 

mohou využít moderního vývoje k získání 

výhod. 

Jestliže se zastaví vývoj hardwarového 

a softwarového vybavení, pak se snižuje 

schopnost modifikovat systém pomocí rozšíření 

jeho funkčnosti. Softwarové balíky, které by 

uživatel rád začlenil do systému nebudou 

použitelné, neboť moderní komerční balíky 

budou předpokládat a vyžadovat aktuální nebo 

poslední verze operačního systému, procesorů, 

periférií atd. 

Rozhodnutí o omezení systému na zastaralé 

technologie ovlivní z dlouhodobého hlediska jak 

vývojové prostředí, tak i vlastní systém. 

Například tím, jak se vyvíjí nové softwarové 

jazyky, jejich kompilátory jsou psány pouze pro 

novější procesory a operační systémy. To také 

omezuje schopnost modernizace systému. 

I kdyby všechna výše uvedená hlediska byla 

brána jako přijatelná, zůstává zde problém, jak 

předpovědět množství požadovaných náhradních 

dílů. Pro COTS produkty je těžké shromažďovat 

nebo získávat schéma MTBF, buď že data 

nebyla shromažďována, nebo proto, že měla 

relativně krátkou životnost, nebo že produkt 

for dealing with hardware obsolescence. 

Unfortunately, experience has shown that these 

are rarely a realistic solution. The reasons for 

this fall into a number of categories, which are 

discussed below. 

COTS-based systems often exhibit a strong 

interdependence between their components, and 

particularly between the software (both 

infrastructure and application) and the hardware 

on which it runs. In the commercial world, new 

processor upgrades are commonplace, and new 

operating systems are being configured to run on 

the newer hardware, taking advantage of the 

lower power/cost ratio that technology has 

consistently delivered over the past 20 years. As 

this happens, the newer software drops support 

for older, less common, hardware, as there is no 

commercial case for expending effort on this 

small market. The consequence of this is that if 

hardware is not upgraded then in a short 

timescale, software cannot be upgraded further, 

and the whole system starts to lag behind the 

state of the art. This, of course, has a direct 

effect on the capability of the system to react to 

modern threats and aggressors, who may be 

capitalizing on modern developments. 

If the infrastructure hardware and software 

becomes frozen, then the capacity to modify the 

system to add new functionality is reduced. 

Software packages that the users may like 

incorporated into the system will not be 

available, because a modern commercial 

package will expect and require up to date or 

recent versions of the operating system, 

processors, peripherals etc. 

In the longer term the decision to limit the 

system to obsolete technology will affect the 

development environment as well as the system 

itself. For example, as new software languages 

are developed, compilers will only be written for 

newer processors and operating systems. This 

will further limit the ability to upgrade the 

system. 

Even if all the above aspects are considered 

acceptable, there remains a problem of 

predicting the number of spare items required. It 

is difficult to gather or obtain MTBF figures for 

COTS products, either because the data has not 

been gathered, or because they have relatively 

short life histories, or because they have not 

58

nebyl provozován v reprezentativním prostředí. 

Tento nedostatek dat kombinovaný s možností, 

že náhradní díly se stanou nepoužitelnými díky 

jiným změnám systému, představuje hlavní 

riziko ve financování a provádění pořizování 

náhradních dílů v průběhu životního cyklu. 


1. vydání 

Oprava 1 

Příloha C 

been used in representative environments. This 

lack of data, combined with the possibility of the 

spares being rendered unsuitable by other 

changes in the system, represents a major risk in 

costing and undertaking whole life buys of 

spares. 

59


1. vydání 

Oprava 1 

Příloha D 

Plán řízení COTS 

V dalším textu je uveden seznam problémů, 

kterým se má věnovat plán řízení COTS. Nejsou 

zde zahrnuty všechny problémy a reprezentují 

minimum problémů, které je třeba u COTS 

produktů postihnout. 

a) Rozpočtování. Produkty COTS vyžadují 

financování i po období daném rozpočtem 

vyvolané eventuálními změnami 

v technologii. Jak bude pro takový případ 

zabezpečeno financování v průběhu 

životního cyklu 

b) Obnovování technologií. COTS produkty se 

mění podle rozmarů komerčního trhu. Jak 

budete monitorovat a aktivně zacházet 

s těmito změnami Jak se budete věnovat 

povýrobnímu zabezpečení 

c) Analýza trhu. K porozumění, kde se nachází 

komerční trh dnes a jaký je jeho budoucí 

směr je třeba rozsáhlého úsilí. Jak toho 

dosáhnete 

d) Systémové inženýrství. Jak se budete 

věnovat změnám v COTS hardwaru 

a softwaru v průběhu životního cyklu 

a dopadům změn na: 

Annex D COTS Management Plan 

Below is a list of issues that should be addressed 

in a COTS Management Plan. These are not all 

inclusive and are merely representative of the 

minimum issues that need to be addressed for 

COTS products. 

a) Budgeting. COTS products require out-year 

funding to address the eventual turnover of 

technology. How will funding be supplied 

throughout the life cycle for this 

b) Technology Refresh. COTS products change 

at the whim of the commercial marketplace. 

How will you monitor and proactively deal 

with these changes How will you address 

post-production support 

c) Market Analysis. Extensive efforts are required 

to understand where the commercial 

marketplace is today and its future direction. 

How will this be accomplished 

d) System Engineering. How will you address 

changes to COTS hardware and software 

throughout the life cycle and its impact to: 

(1) základní úrovně systému, (1) System Baselines 

(2) certifikaci a kvalifikaci, (2) Certification and Qualification 

(3) testování a hodnocení, (3) Test and Evaluation 

(4) technické parametry systému, (4) System Performance 

(5) interoperabilitu, (5) Intra and Interoperability 

(6) bezpečnost informací, (6) Information Security 

(7) vytváření a identifikování standardů 

pro otevřené systémy, 

(7) Developing or Identifying Standards 

for Open Systems 

(8) vyhledání/izolaci poruchového stavu, (8) Fault Detection/Isolation 

(9) požadavky, (9) Requirements 

(10) bezpečnost systému, (10) System Safety 

(11) podmínky prostředí (schopnosti (11) Environmental Conditions (e.g. 

přežití, zátěže), 

survivability, shock) 

(12) hluk, vibrace, ECM/EMI, oheň, kouř, (12) Noise, vibration, EMC/EMI, 

jedy, 

fire/smoke/toxicity, 

(13) dispergované vodní částice, vlhkost, (13) Water spray, humidity, 

(14) nebezpečné materiály, prevenci (14) Hazardous materials, pollution 

znečištění. 

prevention, 

e) Technické parametry COTS. COTS 

produkty mohou a nemusí být vhodné pro 

použití do lodí. Jak máte v úmyslu to 

vyhodnotit a pokud je to nutné, modifikovat 

COTS nebo jeho instalaci pro prostředí 

námořního boje nebo pro mírové prostředí 

e) COTS Performance. COTS products may or 

may not be suitable for shipboard 

applications. How do you intend to evaluate 

this and if necessary modify COTS, or its 

installation, for shipboard combat and 

peacetime environments 

60

f) Práva na technická data. Technická data 

položek COTS jsou obecně nedosažitelná 

nebo jejich pořízení je velmi nákladné. Jaká 

přijmete opatření zabývající se dostupností 

technických dat dosažitelných pro položky 

COTS 

g) Management konfigurací. Tradiční přístupy 

managementu konfigurací pro produkty 

COTS nefungují. Jak se budete věnovat 

funkčním požadavkům, abyste věděli, jaké 

položky jsou třeba pro výrobu, zabezpečení, 

plánování technických změn, strategii řízení 

COTS atd. Jak zajistíte zaměnitelnost tvaru, 

vhodnosti a funkce v průběhu životního 

cyklu 

h) Integrované logistické zabezpečení. Pro produkty 

COTS je často stanovena filosofie 

komerčního zabezpečení. Jak tuto filozofii 

vpravíte a budete integrovat do pozic 

úplného integrovaného zabezpečení Jak 

bude maximalizována účinnost stávajících 

technických a obchodních procesů 

a transparentnost koncového uživatele Jaká 

opatření z těch, která jsou uvedena níže, 

učiníte pro vaše COTS položky 


1. vydání 

Oprava 1 

Příloha D 

f) Rights in Technical Data. Technical data for 

COTS items is generally unavailable or very 

expensive to procure. What workarounds 

have you put in place to address the limited 

technical data available for COTS items 

g) Configuration Management (CM). 

Traditional CM paradigms do not work for 

COTS products. How will you address the 

functional requirement to know what items 

are needed for production, support, 

Engineering Change (EC) planning, COTS 

Management Strategies etc. How will you 

insure form, fit and function 

interchangeability throughout the life cycle 

h) ILS. COTS products often have established 

commercial support philosophies. How will 

you leverage and integrate these into a total 

integrated support posture How will 

existing technical and business processes be 

maximized for efficiencies and end user 

transparency How will you provide the 

following for your COTS items 

(1) zabezpečení dodávek, (1) Supply Support 

(2) balení, manipulace, skladování 

a doprava, 

(2) Packaging, Handling, Storage & 

Transportation 

(3) plánování údržby, (3) Maintenance Planning 

(4) pracovní síla a pracovníci, (4) Manpower and Personnel 

(5) vybavení pro zabezpečení, (5) Support Equipment 

(6) technická data, (6) Technical Data 

(7) výcvik a zabezpečení výcviku, (7) Training and Training Support 

(8) podpora počítačových zdrojů, (8) Computer Resources Support 

(9) příslušenství, (9) Facilities 

(10) rozhraní v návrhu, (10) Design Interface 

(11) bezporuchovost, udržovatelnost 

a pohotovost, 

(11) Reliability, Maintainability and 

Availability 

(12) licence na software, (12) Software Licenses 

(13) řízení záruk. (13) Warranty Management 

Bezporuchovost, udržovatelnost a zabezpečování 

jakosti. Produkty COTS jsou navrhovány 

a vyráběny podle různých standardů pro 

bezporuchovost, udržovatelnost a zabezpečování 

jakosti. Jak vyhodnotíte stávající produkt a 

zaručíte, že eventuální náhrady nezpůsobí 

zhoršení v této ani žádné další kritické oblasti 

Reliability, Maintainability and Quality 

Assurance. COTS products are designed and 

fabricated to varying standards of reliability, 

maintainability and quality. How will you 

evaluate current products and insure eventual 

replacements do not degrade in these and all 

other critical areas 

61


1. vydání 

Oprava 1 

Účinnost českého obranného standardu od: 7.4.2008 

Opravy: 

Oprava 

Účinnost od 

číslo 

Opravu zapracoval 

1. 28. 4. 2011 Odbor obranné standardizace 

Ing. Vladimír Čoček 

Datum 

zapracování 

28.4. 2011 

Poznámka 

U p o z o r n ě n í: 

Oznámení o českých obranných standardech jsou uveřejňována měsíčně 

ve Věstníku Úřadu pro technickou normalizaci, metrologii a státní 

zkušebnictví v oddíle „Ostatní oznámení“ a Věstníku MO. 

Vydal Úřad pro obrannou standardizaci, katalogizaci a státní ověřování jakosti 

Rok vydání: 2011, obsahuje 31listů 

Tisk: Ministerstvo obrany ČR 

Distribuce: Odbor obranné standardizace Úř OSK SOJ, nám. Svobody 471, 160 01 Praha 6 

www.oos.army.cz 

NEPRODEJNÉ 

62

051650 - Odbor obrannÃ© standardizace - Ministerstvo obrany

Create successful ePaper yourself

Delete template?

Save as template?