natgillin/translations-raw huggingface dataset:
Toto nařízení stanoví požadavky na určení a zavedení systému zajištění bezpečnosti softwaru poskytovateli letových provozních služeb (ATS), subjekty zajišťujícími uspořádání toku letového provozu (ATFM) a uspořádání vzdušného prostoru (ASM) pro všeobecný letový provoz a poskytovateli komunikačních, navigačních a pozorovacích služeb (CNS).
This Regulation lays down the requirements for the definition and implementation of a software safety assurance system by air traffic service (ATS) providers, entities providing air traffic flow management (ATFM) and air space management (ASM) for general air traffic, and providers of communication, navigation and surveillance (CNS) services.
Nařízení určuje a schvaluje povinná ustanovení bezpečnostních regulačních požadavků organizace Eurocontrol – ESARR 6, nazvaná „Software v systémech ATM“, vydaných dne 6. listopadu 2003.
It identifies and adopts the mandatory provisions of the Eurocontrol Safety Regulatory Requirement — ESARR 6 — entitled ‘Software in ATM Systems’ issued on 6 November 2003.
Toto nařízení se použije na nový software a veškeré změny softwaru v systémech ATS, ASM, ATFM a CNS.
This Regulation shall apply to the new software and to any changes to the software of the systems for ATS, ASM, ATFM, and CNS.
Nepoužije se na software palubních prvků ani na zařízení v kosmickém prostoru.
It shall not apply to the software of airborne constituents and to space-based equipment.
Pro účely tohoto nařízení se použijí definice uvedené v článku 2 nařízení (ES) č. 549/2004.
For the purposes of this Regulation, the definitions in Article 2 of Regulation (EC) No 549/2004 shall apply.
„softwarem“ se rozumí počítačové programy a odpovídající konfigurační data, včetně nevyvíjeného softwaru, s výjimkou elektronických prvků, jako jsou aplikace určitých integrovaných obvodů, programovatelných logických obvodů nebo logické přepínače v ustáleném stavu;
‘software’ means computer programmes and corresponding configuration data, including non-developmental software, but excluding electronic items, namely application specific integrated circuits, programmable gate arrays or solid-state logic controllers;
„konfiguračními daty“ se rozumí data, která konfigurují druhový softwarový systém v jednotlivých případech použití;
‘configuration data’ means data that configures a generic software system to a particular instance of its use;
„nevyvíjeným softwarem“ se rozumí software, který nebyl vyvinut pro stávající smlouvu;
‘non-developmental software’ means a software not developed for the current contract;
„zajištěním bezpečnosti“ se rozumí veškeré plánované a systematické činnosti nezbytné k poskytování přiměřené jistoty, že výrobek, služba, organizace nebo funkční systém dosahuje přijatelné nebo přípustné bezpečnosti;
‘safety assurance’ means all planned and systematic actions necessary to provide adequate confidence that a product, a service, an organisation or a functional system achieves acceptable or tolerable safety;
„organizací“ se rozumí poskytovatel ATS, poskytovatel CNS nebo subjekt zajišťující ATFM nebo ASM;
‘organisation’ means either an ATS provider, a CNS provider or an entity providing ATFM or ASM;
„funkčním systémem“ se rozumí kombinace systémů, postupů a lidských zdrojů, které jsou uspořádány tak, aby plnily určitou funkci v rámci ATM;
‘functional system’ means a combination of systems, procedures and human resources organised to perform a function within the context of ATM;
„rizikem“ se rozumí kombinace celkové pravděpodobnosti nebo četnosti výskytu škodlivého účinku vyvolaného nebezpečím a závažnosti tohoto účinku;
‘risk’ means the combination of the overall probability, or frequency of occurrence of a harmful effect induced by a hazard and the severity of that effect;
„nebezpečím“ se rozumí jakýkoliv stav, událost nebo okolnost, která by mohla vyvolat nehodu;
‘hazard’ means any condition, event, or circumstance which could induce an accident;
„novým softwarem“ se rozumí software, který byl objednán nebo na který byly podepsány závazné smlouvy po vstupu tohoto nařízení v platnost;
‘new software’ means a software that has been ordered or for which binding contracts have been signed after the entry into force of this Regulation;
„bezpečnostním cílem“ se rozumí kvalitativní nebo kvantitativní výrok, který určuje nejvyšší četnost nebo pravděpodobnost, s níž se podle očekávání může vyskytnout nebezpečí;
‘safety objective’ means a qualitative or quantitative statement that defines the maximum frequency or probability at which a hazard can be expected to occur;
„bezpečnostním požadavkem“ se rozumí prostředek pro zmírnění rizika, určený strategií zmírňování rizik, který splňuje určitý bezpečnostní cíl a zahrnuje organizační, provozní, procedurální, funkční a výkonnostní požadavky, požadavky interoperability nebo charakteristiku prostředí;
‘safety requirement’ means a risk-mitigation means, defined from the risk-mitigation strategy that achieves a particular safety objective, including organisational, operational, procedural, functional, performance, and interoperability requirements or environment characteristics;
„přepnutím nebo výměnou za provozu“ se rozumí způsob výměny prvků systému evropské sítě pro řízení letového provozu (EATMN) nebo softwaru za provozu systému;
‘cutover or hot swapping’ means the approach of replacing European air traffic management network (EATMN) system components or software while the system is operational;
„bezpečnostním požadavkem na software“ se rozumí popis toho, co má software vytvářet při daných vstupech a omezeních a co v případě splnění zajistí, že software EATMN pracuje bezpečně a v souladu s provozními potřebami;
‘software safety requirement’ means a description of what is to be produced by the software given the inputs and constraints, and if met, ensures that EATMN software performs safely and according to operational need;
„softwarem EATMN“ se rozumí software používaný v EATM podle článku 1;
‘EATMN software’ means software used in the EATMN systems referred to in Article 1;
„platností požadavků“ se rozumí potvrzení na základě zkoumání a poskytnutí objektivního důkazu, že jsou splněny konkrétní požadavky zamýšleného použití;
‘requirements validity’ means the confirmation by examination and provision of objective evidence that the particular requirements for a specific use are as intended;
„nezávislým dosažením“ se v případě činností v rámci procesu ověřování softwaru rozumí, že činnosti v rámci procesu ověřování provádí jiná osoba (jiné osoby) než osoba, která ověřovaný prvek vyvinula;
‘achieved with independence’ means, for software verification process activities, that the verification process activities are performed by a person(s) other than the developer of the item being verified;
„poruchou softwaru“ se rozumí neschopnost programu správně vykonávat požadovanou funkci;
‘software malfunction’ means the inability of a programme to perform a required function correctly;
„selháním softwaru“ se rozumí neschopnost programu vykonávat požadovanou funkci;
‘software failure’ means the inability of a programme to perform a required function;
„aplikací COTS“ (Commercial Off-The-Shelf) se rozumí komerčně dostupná aplikace, kterou prodávají obchodníci prostřednictvím veřejně dostupných katalogů a která není určena pro úpravu podle požadavků zákazníka nebo zdokonalování;
‘COTS’ means a commercial available application sold by vendors through public catalogue listings and not intended to be customised or enhanced;
„složkami softwaru“ se rozumí moduly, které lze instalovat nebo kombinovat s jinými opakovaně využitelnými softwarovými moduly k vytvoření softwarové aplikace podle požadavků zákazníka;
‘software components’ means a building block that can be fitted or connected together with other reusable blocks of software to combine and create a custom software application;
„nezávislými prvky softwaru“ se rozumí prvky softwaru, které nevyřadí z provozu stejné selhání, jímž je způsobeno nebezpečí;
‘independent software components’ means those software components which are not rendered inoperative by the same failure condition that causes the hazard;
„reakční dobou softwaru“ se rozumí čas, během něhož má software reagovat na dané vstupy nebo periodické události a/nebo výkon softwaru z hlediska transakcí nebo zpráv zpracovaných za jednotku času;
‘software timing performances’ means the time allowed for the software to respond to given inputs or to periodic events, and/or the performance of the software in terms of transactions or messages handled per unit time;
„kapacitou softwaru“ se rozumí schopnost softwaru zpracovat daný objem toku dat;
‘software capacity’ means the ability of the software to handle a given amount of data flow;
„přesností“ se rozumí požadovaná přesnost vypočtených výsledků;
‘accuracy’ means the required precision of the computed results;
„využitím zdrojů“ se rozumí objem zdrojů výpočetního systému, které může aplikační software využívat;
‘software resource usage’ means the amount of resources within the computer system that can be used by the application software;
„odolností softwaru“ se rozumí chování softwaru v případě neočekávaných vstupů, poruch hardwaru a přerušení dodávky elektřiny buď přímo do výpočetního systému, nebo do připojených zařízení;
‘software robustness’ means the behaviour of the software in the event of unexpected inputs, hardware faults and power supply interruptions, either in the computer system itself or in connected devices;
„tolerancí přetížení“ se rozumí chování systému, a zejména jeho tolerance v případě výskytu většího objemu vstupů, než je objem očekávaný při běžném provozu systému;
‘overload tolerance’ means the behaviour of the system in the event of, and in particular its tolerance to, inputs occurring at a greater rate than expected during normal operation of the system;
„správným a úplným ověřením softwaru EATMN“ se rozumí všechny požadavky na bezpečnost softwaru, které správně stanoví, co vyžaduje postup pro posuzování a zmírňování rizika od prvků softwaru, a jejich zavedení prokazatelně dosahuje požadované úrovně bezpečnosti softwaru;
‘correct and complete EATMN software verification’ means all software safety requirements which correctly state what is required of the software component by the risk assessment and mitigation process and their implementation is demonstrated to the level required by the software assurance level;
„daty životního cyklu softwaru“ se rozumí data vytvořená během životního cyklu softwaru, která slouží plánování, řízení, vysvětlování, určování, zaznamenávání nebo poskytování důkazů o činnostech; tato data umožňují schvalování procesů životního cyklu softwaru, systémů nebo zařízení a modifikaci softwarového produktu po schválení;
‘software life cycle data’ means the data that is produced during the software life cycle to plan, direct, explain, define, record, or provide evidence of activities; this data enables the software life cycle processes, system or equipment approval and post-approval modification of the software product;
„životním cyklem“ se rozumí:
‘software life cycle’ means:
objednaný soubor postupů určených organizací jako dostačující a přiměřené pro vytvoření softwarového produktu;
an ordered collection of processes determined by an organisation to be sufficient and adequate to produce a software product;
časový úsek, který začíná rozhodnutím vytvořit nebo upravit softwarový produkt a končí vyřazením produktu z provozu;
the period of the time that begins with the decision to produce or modify a software product and ends when the product is retired from service;
„požadavkem na bezpečnost systému“ se rozumí bezpečnostní požadavek odvozený pro funkční systém.
‘system safety requirement’ means a safety requirement derived for a functional system.
Kdykoli má organizace zavést postup pro posuzování a zmírňování rizika v souladu s platnými právními předpisy Společenství nebo vnitrostátními právními předpisy, určí a zavede systém zajištění bezpečnosti softwaru, který se bude zabývat konkrétními aspekty týkajícími se softwaru EATMN, včetně všech provozních změn softwaru on-line, jako je přepnutí nebo výměna za provozu.
Whenever an organisation is required to implement a risk assessment and mitigation process in accordance with applicable Community or national law, it shall define and implement a software safety assurance system to deal specifically with EATMN software related aspects, including all on-line software operational changes, and in particular cutover or hot swapping.
Organizace zajistí, aby její systém zajištění bezpečnosti softwaru poskytoval alespoň důkazy a argumenty, které svědčí o tom, že:
The organisation shall ensure, as a minimum, that its software safety assurance system produces evidence and arguments that demonstrate the following:
požadavky na bezpečnost softwaru správně stanoví, co se požaduje od softwaru ke splnění bezpečnostních cílů a požadavků stanovených v rámci postupu pro posuzování a zmírňování rizika;
the software safety requirements correctly state what is required by the software, in order to meet safety objectives and requirements, as identified by the risk assessment and mitigation process;
je zajištěna sledovatelnost všech požadavků na bezpečnost softwaru;
traceability is addressed in respect of all software safety requirements;
zavedení softwaru neobsahuje žádné funkce, které mají nepříznivý vliv na bezpečnost;
the software implementation contains no functions which adversely affect safety;
software EATMN splňuje na něj kladené požadavky na úrovni jistoty, která je v souladu s kritičností softwaru;
the EATMN software satisfies its requirements with a level of confidence which is consistent with the criticality of the software;
je zajištěno splnění všeobecných bezpečnostních požadavků stanovených v písmenech a) až d) a argumenty, jimiž lze toto zajištění prokázat, lze kdykoli odvodit:
assurances are provided confirming that the general safety requirements set out in points (a) to (d) are satisfied, and the arguments that demonstrate the required assurances are at all times derived from:
ze známé spustitelné verze softwaru,
a known executable version of the software;
ze známého rozsahu konfiguračních dat,
a known range of configuration data;
ze známého souboru softwarových produktů a popisů, včetně specifikací, které byly použity při vytvoření dané verze.
a known set of software products and descriptions, including specifications, that have been used in the production of that version.
Organizace poskytne vnitrostátnímu dozorovému orgánu potřebné záruky, prokazující, že požadavky stanovené v odstavci 2 byly splněny.
The organisation shall make available the required assurances, to the national supervisory authority, demonstrating that the requirements provided for in paragraph 2 have been satisfied.
Požadavky na systém zajištění bezpečnosti softwaru
Requirements applying to the software safety assurance system
Organizace zajistí, aby systém zajištění bezpečnosti softwaru splňoval alespoň tato kritéria:
The organisation shall ensure, as a minimum, that the software safety assurance system:
systém je zdokumentovaný výslovně jako součást všeobecné dokumentace posuzování a zmírňování rizika;
is documented, specifically as part of the overall risk assessment and mitigation documentation;
každému provozovanému softwaru EATMN přiřadí systém úroveň zajištění softwaru v souladu s požadavky stanovenými v příloze I;
allocates software assurance levels to all operational EATMN software in compliance with the requirements set out in Annex I;
systém zahrnuje zajištění týkající se:
includes assurances of:
platnosti požadavků na bezpečnost softwaru v souladu s požadavky stanovenými v příloze II části A;
software safety requirements validity in compliance with the requirements set out in Annex II, Part A;
ověření softwaru v souladu s požadavky stanovenými v příloze II části B;
software verification in compliance with the requirements set out in Annex II, Part B;
řízení konfigurace softwaru v souladu s požadavky stanovenými v příloze II části C;
software configuration management in compliance with the requirements set out in Annex II, Part C;
sledovatelnosti požadavků na bezpečnost softwaru v souladu s požadavky stanovenými v příloze II části D;
software safety requirements traceability in compliance with the requirements set out in Annex II, Part D;
systém určuje nároky na úroveň zajištění; nároky musí být stanoveny pro každou úroveň zajištění softwaru a zvyšovány s rostoucí kritičností softwaru; za tím účelem:
determines the rigour to which the assurances are established; the rigour must be defined for each software assurance level, and increase as the software increases in criticality; for that purpose:
rozdílné nároky odpovídající jednotlivým úrovním zajištění softwaru musí zahrnovat kritéria:
the variation in rigour of the assurances per software assurance level must include the following criteria:
která se musí splnit nezávisle,
required to be achieved with independence;
která se musí splnit,
required to be achieved;
která se nemusí splnit;
not required;
zajištění odpovídající každé úrovni zajištění softwaru musí poskytovat dostatečnou jistotu, že software EATMN lze provozovat s přípustnou mírou bezpečnosti;
the assurances corresponding to each software assurance level must give sufficient confidence that the EATMN software can be operated tolerably safely;
systém využívá zkušenosti se softwarem EATMN jako zpětnou vazbu pro potvrzení, že systém zajištění bezpečnosti softwaru a přiřazení jednotlivých úrovní zajištění jsou přiměřené.
uses feedback of EATMN software experience to confirm that the software safety assurance system and the assignment of assurance levels are appropriate.
Za tímto účelem se musí účinky poruchy nebo selhání softwaru, vykázané podle příslušných požadavků na vykazování a posuzování bezpečnostních incidentů, posuzovat ve srovnání s účinky stanovenými pro příslušný systém podle schématu klasifikace závažnosti stanoveného v oddílu 3.2.4 přílohy II nařízení (ES) č. 2096/2005.
For that purpose, the effects from a software malfunction or failure reported according to the relevant requirements on reporting and assessment of safety occurrences shall be assessed in comparison with the effects identified for the system concerned as per the severity classification scheme established in Section 3.2.4 of Annex II to Regulation (EC) No 2096/2005.
Požadavky na změny softwaru a na určitý software
Requirements applying to changes to software and to specific software
V případě jakýchkoli změn softwaru nebo určitých druhů softwaru, např. COTS, nevývojového softwaru nebo dříve používaného softwaru, na nějž nelze použít některé z požadavků čl. 3 odst. 2 písm. d) nebo e) nebo čl. 4 odst. 2, 3, 4 nebo 5, organizace zajistí, aby systém zajištění bezpečnosti softwaru poskytoval pomocí jiných prostředků vybraných a odsouhlasených vnitrostátním dozorovým orgánem stejnou úroveň jistoty jako příslušná úroveň zajištění softwaru v případě, že je definovaná.
For any changes to the software or for specific types of software such as COTS, non-developmental software or previously used software for which some of the requirements of Article 3(2)(d) or (e) or of Article 4(2), (3), (4) or (5) cannot be applied, the organisation shall ensure that the software safety assurance system provides, through other means chosen and agreed with the national supervisory authority, the same level of confidence as the relevant software assurance level whenever defined.
Tyto prostředky musí poskytovat dostatečnou jistotu, že software splňuje bezpečnostní cíle a požadavky stanovené v rámci postupu pro posuzování a zmírňování rizika.
Those means must give sufficient confidence that the software meets the safety objectives and requirements, as identified by the safety risk assessment and mitigation process.
Pro posouzení prostředků uvedených v odstavci 1 může vnitrostátní dozorový orgán použít uznávanou organizaci nebo oznámený subjekt.
In the assessment of the means referred to in paragraph 1, the national supervisory authority may use a recognised organisation or a notified body.
V příloze II nařízení (ES) č. 2096/2005 se doplňuje nový text, který zní:
In Annex II to Regulation (EC) No 2096/2005, the following section is added:
Systém zajištění bezpečnosti softwaru
Software safety assurance system
V rámci systému řízení bezpečnosti zavede poskytovatel letových provozních služeb systém zajištění bezpečnosti softwaru v souladu s nařízením Komise (ES) č. 482/2008 (ze dne 30. května 2008, kterým se stanoví systém zajištění bezpečnosti softwaru, který má být zaveden poskytovateli letových navigačních služeb, a kterým se mění nařízení (ES) č. 2096/2005.Článek 7
Within the operation of the safety management system, a provider of air traffic services shall implement a software safety assurance system in accordance with Commission Regulation (EC) No 482/2008 of 30 May 2008 establishing a software safety assurance system to be implemented by air navigation service providers and amending Annex II to Regulation (EC) No 2096/2005.Article 7
Použije se ode dne 1. ledna 2009 na nový software systémů EATMN uvedený v čl. 1 odst. 2.
It shall apply from 1 January 2009 to the new software of EATMN systems referred to in Article 1(2), first subparagraph.
Použije se ode dne 1. července 2010 na jakékoli změny softwaru systémů EATMN uvedených v čl. 1 odst. 2, které budou k uvedenému dni v provozu.
It shall apply from 1 July 2010 to any changes to the software of EATMN systems referred to in Article 1(2), first subparagraph, in operation by that date.
Nařízení ve znění nařízení (ES) č. 1315/2007 (Úř. věst. L 291, 9.11.2007, s. 16).
Regulation as amended by Regulation (EC) No 1315/2007 (OJ L 291, 9.11.2007, p. 16).
Úř. věst. L 141, 31.5.2008, s. 5.“
OJ L 141, 31.5.2008, p. 5.’
Požadavky na úroveň zajištění softwaru podle čl. 4 odst. 2
Requirements applying to the software assurance level referred to in Article 4(2)
Úroveň zajištění softwaru musí odpovídat nárokům na zajištění softwaru podle kritičnosti softwaru EATMN v souladu se schématem pro klasifikaci závažnosti stanoveným v příloze II oddílu 4 bodu 3.2.4 nařízení (ES) č. 2096/2005, v kombinaci s pravděpodobností výskytu určitého nepříznivého účinku.
The software assurance level shall relate the rigour of the software assurances to the criticality of EATMN software by using the severity classification scheme set out in Section 4 of point 3.2.4 of Annex II to Regulation (EC) No 2096/2005 combined with the likelihood of the occurrence of a certain adverse effect.
Určí se alespoň čtyři úrovně zajištění softwaru, přičemž úroveň zajištění softwaru 1 označuje nejkritičtější úroveň.
A minimum of four software assurance levels shall be identified, with software assurance level 1 indicating the most critical level.
Přiřazená úroveň zajištění softwaru musí být podle přílohy II oddílu 4 bodu 3.2.4 nařízení (ES) č. 2096/2005 přiměřená nejnepříznivějšímu účinku, jaký mohou poruchy nebo selhání softwaru způsobit.
An allocated software assurance level shall be commensurate with the most severe effect that software malfunctions or failures may cause, as referred to in Section 4 of point 3.2.4 of Annex II to Regulation (EC) No 2096/2005.
Zohlední se zejména rizika spojená s poruchami nebo selháními softwaru a příslušné ochranné mechanismy na úrovni architektury a/nebo postupů.
This shall, in particular, take into account the risks associated with software malfunctions or failures and the architectural and/or procedural defences identified.
Prvkům softwaru EATMN, jejichž vzájemnou nezávislost nelze prokázat, se přiřadí úroveň zajištění softwaru odpovídající nejkritičtějším závislým prvkům.
EATMN software components that cannot be shown to be independent of one another shall be allocated the software assurance level of the most critical of the dependent components.
Část A: Požadavky na zajištění platnosti požadavků na bezpečnost softwaru podle čl. 4 odst. 3 písm. a)
Part A: Requirements applying to the software safety requirements validity assurance referred to in Article 4(3)(a)