natgillin/translations-raw huggingface dataset:
«independent software components» means those software components which are not rendered inoperative by the same failure condition that causes the hazard;
«uavhengige programvarekomponenter» programvarekomponenter som ikke settes ut av drift som følge av den funksjonssvikt som forårsaket faren,
«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;
«programvarens reaksjonstid» den tid som programvaren trenger for å reagere på en viss innmating eller på periodiske hendelser, og/eller programvarens ytelse målt i antall behandlede transaksjoner eller meldinger per tidsenhet,
«software capacity» means the ability of the software to handle a given amount of data flow;
«programvarekapasitet» programvarens evne til å håndtere en gitt datastrøm,
«accuracy» means the required precision of the computed results;
«nøyaktighet» den presisjon som kreves for de beregnede resultatene,
«software resource usage» means the amount of resources within the computer system that can be used by the application software;
«programvarens ressursbruk» den mengde ressurser i datasystemet som kan utnyttes av brukerprogramvaren,
«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;
«programvarestabilitet» programvarens oppførsel ved uventet innmating, maskinvarefeil og strømbrudd, enten i selve datasystemet eller i tilknyttet utstyr,
«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;
«evne til å tåle overbelastning» systemets oppførsel ved, og særlig dets evne til å tåle, innmating som skjer raskere enn ventet under normal drift av systemet,
«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;
«riktig og fullstendig verifikasjon av EATMN-programvare» alle sikkerhetskrav til programvare som på en riktig måte angir hva som kreves av programvarekomponenten i samsvar med risikovurderings- og risikoreduksjonsprosessen, og at oppfyllelsen av disse sikkerhetskravene er vist i henhold til det nivå som kreves ifølge sikkerhetsnivået for programvaren,
«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;
«livssyklusdata for programvare» data som produseres i løpet av programvarens livssyklus for å planlegge, styre, forklare, definere, registrere eller dokumentere virksomhet. Disse dataene muliggjør programvarens livssyklusprosesser, godkjenning av systemet eller utstyret samt endringer av programvareproduktet etter godkjenning,
«software life cycle» means:
«programvarens livssyklus»
an ordered collection of processes determined by an organisation to be sufficient and adequate to produce a software product;
en ordnet samling av prosesser som en organisasjon anser som tilstrekkelig og egnet til å produsere et programvareprodukt,
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;
den tidsperiode som begynner med beslutningen om å produsere eller endre et programvareprodukt, og som avsluttes når produktet tas ut av drift,
«system safety requirement’ means a safety requirement derived for a functional system.
«sikkerhetskrav til systemet» et sikkerhetskrav som gjelder for et funksjonssystem.
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.
Når en organisasjon skal gjennomføre en risikovurderings- og risikoreduksjonsprosess i samsvar med gjeldende fellesskapsregelverk eller nasjonal lovgivning, skal den definere og gjennomføre et system for sikkerhetsbekreftelse av programvare som særlig skal håndtere forhold knyttet til EATMN-programvare, herunder alle driftsmessige programvareendringer foretatt elektronisk, og særlig systemovergang eller bytte under drift.
The organisation shall ensure, as a minimum, that its software safety assurance system produces evidence and arguments that demonstrate the following:
Organisasjonen skal minst sikre at dens system for sikkerhetsbekreftelse av programvare ved hjelp av dokumentasjon og argumenter viser følgende:
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;
sikkerhetskravene til programvaren angir på en riktig måte hva som kreves av programvaren for at sikkerhetsmålene og –kravene fastlagt under risikovurderings- og risikoreduksjonsprosessen skal være oppfylt,
traceability is addressed in respect of all software safety requirements;
alle sikkerhetskrav til programvare omfatter sporbarhet,
the software implementation contains no functions which adversely affect safety;
innføringen av programvaren inneholder ingen funksjoner som innvirker negativt på sikkerheten,
the EATMN software satisfies its requirements with a level of confidence which is consistent with the criticality of the software;
EATMN-programvaren oppfyller sine krav med en grad av pålitelighet som tilsvarer programvarens kritikalitet,
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:
forsikringer gis som bekrefter at de alminnelige sikkerhetskravene fastsatt i bokstav a)–d) er oppfylt, og argumentene til støtte for den påkrevde sikkerhet til enhver tid bygger på
a known executable version of the software;
en kjent gjennomførbar versjon av programvaren,
a known range of configuration data;
en kjent samling konfigurasjonsdata,
a known set of software products and descriptions, including specifications, that have been used in the production of that version.
en kjent samling av programvareprodukter og -beskrivelser, herunder spesifikasjoner, som er brukt ved produksjonen av den aktuelle versjonen.
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.
Organisasjonen skal sørge for at den nasjonale tilsynsmyndighet får tilgang til de forsikringer som kreves for å vise at kravene fastsatt i nr. 2 er oppfylt.
Requirements applying to the software safety assurance system
Krav til systemet for sikkerhetsbekreftelse av programvare
The organisation shall ensure, as a minimum, that the software safety assurance system:
Organisasjonen skal minst sikre at systemet for sikkerhetsbekreftelse av programvare
is documented, specifically as part of the overall risk assessment and mitigation documentation;
er dokumentert, særlig som en del av dokumentasjonen av den overordnede risikovurdering og -reduksjon,
allocates software assurance levels to all operational EATMN software in compliance with the requirements set out in Annex I;
tildeler programvaresikkerhetsnivåer til all operativ EATMN-programvare i samsvar med kravene fastsatt i vedlegg I,
includes assurances of:
kan godtgjøre at
software safety requirements validity in compliance with the requirements set out in Annex II, Part A;
sikkerhetskravene til programvaren er validert i samsvar med kravene fastsatt i vedlegg II del A,
software verification in compliance with the requirements set out in Annex II, Part B;
programvaren er verifisert i samsvar med kravene fastsatt i vedlegg II del B,
software configuration management in compliance with the requirements set out in Annex II, Part C;
programvarens konfigurasjonsstyring er i samsvar med kravene fastsatt i vedlegg II del C,
software safety requirements traceability in compliance with the requirements set out in Annex II, Part D;
sikkerhetskravene til programvaren er sporbare i samsvar med kravene fastsatt i vedlegg II del D,
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:
fastsetter hvor strenge krav forsikringene oppfyller; strenghetsgraden skal fastsettes for hvert programvaresikkerhetsnivå, og den skal øke når programvarens kritikalitet øker; for det formål skal
the variation in rigour of the assurances per software assurance level must include the following criteria:
variasjonen i strenghetsgrad for hvert programvaresikkerhetsnivå omfatte følgende kriterier:
required to be achieved with independence;
skal oppnås på en uavhengig måte
required to be achieved;
skal oppnås
not required;
behøver ikke oppnås
the assurances corresponding to each software assurance level must give sufficient confidence that the EATMN software can be operated tolerably safely;
forsikringene for hvert programvaresikkerhetsnivå gi tilstrekkelig tillit til at EATMN-programvare kan benyttes med en akseptabel sikkerhetsrisiko,
uses feedback of EATMN software experience to confirm that the software safety assurance system and the assignment of assurance levels are appropriate.
anvender tilbakemelding fra erfaringer med EATMN-programvare for å bekrefte at systemet for sikkerhetsbekreftelse av programvare og tildelingen av sikkerhetsnivåer er hensiktsmessige.
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.
For det formål skal virkningene av programvarefunksjonssvikt eller programvaresvikt som blir meldt i samsvar med relevante krav om melding og vurdering av sikkerhetshendelser, vurderes i forhold til de virkningene som er angitt for det berørte system i klassifiseringen av alvorlighetsgrad gjengitt i avsnitt 3.2.4 i vedlegg II til forordning (EF) nr. 2096/2005.
Requirements applying to changes to software and to specific software
Krav som gjelder endringer av programvare og særskilt programvare
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.
For endringer av programvare eller særskilte programvaretyper som COTS, standardprogramvare eller programvare som er brukt tidligere, og som noen av kravene i artikkel 3 nr. 2 bokstav d) eller e) eller i artikkel 4 nr. 2, 3, 4 eller 5 ikke kan anvendes på, skal organisasjonen sørge for at systemet for sikkerhetsbekreftelse av programvare på en annen måte, som velges og godkjennes i samråd med den nasjonale tilsynsmyndighet, gir samme grad av pålitelighet som gjeldende programvaresikkerhetsnivå, når et slikt er fastsatt.
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.
Disse midlene skal skape tilstrekkelig tillit til at programvaren oppfyller sikkerhetsmålene og sikkerhetskravene i samsvar med sikkerhetsvurderings- og risikoreduksjonsprosessen.
In the assessment of the means referred to in paragraph 1, the national supervisory authority may use a recognised organisation or a notified body.
Ved vurderingen av midlene nevnt i nr. 1 kan den nasjonale tilsynsmyndighet benytte en godkjent organisasjon eller et meldt organ.
Software safety assurance system
System for sikkerhetsbekreftelse av programvare
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(*).
Innenfor rammen av sikkerhetsstyringssystemet skal ytere av lufttrafikktjenester innføre et system for sikkerhetsbekreftelse av programvare i samsvar med kommisjonsforordning (EF) nr. 482/2008 av 30. mai 2008 om opprettelse av et system for sikkerhetsbekreftelse av programvare, som skal gjennomføres av ytere av flysikringstjenester, og om endring av vedlegg II til forordning (EF) nr. 2096/2005(*).
It shall apply from 1 January 2009 to the new software of EATMN systems referred to in Article 1(2), first subparagraph.
Den får anvendelse fra 1. januar 2009 på ny programvare for EATMN-systemene nevnt i artikkel 1 nr. 2 første ledd.
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.
Den får anvendelse fra 1. juli 2010 på alle endringer av programvaren for EATMN-systemene nevnt i artikkel 1 nr. 2 første ledd som er i drift på nevnte dato.
Requirements applying to the software assurance level referred to in Article 4(2)
KRAV SOM GJELDER PROGRAMVARESIKKERHETSNIVÅET NEVNT I ARTIKKEL 4 NR. 2
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.
Ved bestemmelse av programvaresikkerhetsnivået knyttes graden av strenghet for programvaresikkerheten til EATMN-programvarens kritikalitet ved anvendelse av skjemaet for klassifisering av alvorlighetsgrad i nr. 3.2.4 avsnitt 4 i vedlegg II til forordning (EF) nr. 2096/2005 kombinert med sannsynligheten for en viss skadelig virkning.
A minimum of four software assurance levels shall be identified, with software assurance level 1 indicating the most critical level.
Det skal fastsettes minst fire programvaresikkerhetsnivåer, og nivå 1 skal være det mest kritiske.
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.
Et tildelt programvaresikkerhetsnivå skal stå i forhold til den alvorligste virkning som programvarefunksjonssvikt eller programvaresvikt kan forårsake, som nevnt i nr. 3.2.4 avsnitt 4 i vedlegg II til forordning (EF) nr. 2096/2005.
This shall, in particular, take into account the risks associated with software malfunctions or failures and the architectural and/or procedural defences identified.
Det skal særlig tas hensyn til risikoene knyttet til programvarefunksjonssvikt eller programvaresvikt og arkitektoniske mottiltak og/eller mottiltak knyttet til framgangsmåte.
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.
EATMN-programvarekomponenter som det ikke kan påvises er uavhengige av hverandre, skal tildeles det programvaresikkerhetsnivået som gjelder for den mest kritiske av de avhengige komponentene.
Part A: Requirements applying to the software safety requirements validity assurance referred to in Article 4(3)(a)
Del A: Krav som gjelder validering av sikkerhetskravene til programvare i henhold til artikkel 4 nr. 3 bokstav a)
Software safety requirements shall specify the functional behaviour in nominal and downgraded modes, of the EATMN software, timing performances, capacity, accuracy, software resource usage on the target hardware, robustness to abnormal operating conditions and overload tolerance, as appropriate.
I sikkerhetskravene til programvare skal EATMN-programvarens funksjon ved nominelt og nedsatt funksjonsnivå angis, dvs. reaksjonstid, kapasitet, nøyaktighet, programvarens ressursbruk på målmaskinvaren, stabilitet under unormale driftsforhold og evne til å tåle overbelastning, når dette er relevant.
Software safety requirements shall be complete and correct, and compliant with the system safety requirements.
Sikkerhetskravene til programvaren skal være fullstendige og riktige, og være i samsvar med sikkerhetskravene til systemet.
Part B: Requirements applying to the software verification assurance referred to in Article 4(3)(b)
Del B: Krav som gjelder verifisering av programvare i henhold til artikkel 4 nr. 3 bokstav b)
The functional behaviour of the EATMN software, timing performances, capacity, accuracy, software resource usage on the target hardware, robustness to abnormal operating conditions and overload tolerance, shall comply with the software requirements.
EATMN-programvarens funksjon, dvs. reaksjonstid, kapasitet, nøyaktighet, programvarens ressursbruk på målmaskinvaren, stabilitet under unormale driftsforhold og evne til å tåle overbelastning, skal oppfylle kravene til programvaren.
The EATMN software shall be adequately verified by analysis and/or testing and/or equivalent means, as agreed with the national supervisory authority.
EATMN-programvaren skal verifiseres på en hensiktsmessig måte ved analyse og/eller prøving og/eller tilsvarende metoder, etter avtale med den nasjonale tilsynsmyndighet.
The verification of the EATMN software shall be correct and complete.
Verifiseringen av EATMN-programvaren skal gjennomføres på en riktig og fullstendig måte.
Part C: Requirements applying to the software configuration management assurances referred to in Article 4(3)(c)
Del C: Krav som gjelder konfigurasjonsstyring av programvare i henhold til artikkel 4 nr. 3 bokstav c)
Configuration identification, traceability and status accounting shall exist such that the software life cycle data can be shown to be under configuration control throughout the EATMN software life cycle.
Det skal finnes framgangsmåter for identifisering av konfigurasjon, sporbarhet og tilstandsregistrering slik at det kan påvises at programvarens livssyklusdata er under konfigurasjonskontroll i EATMN-programvarens samlede livssyklus.
Problem reporting, tracking and corrective actions shall exist such that safety related problems associated with the software can be shown to have been mitigated.
Det skal finnes framgangsmåter for melding og sporing av problemer samt korrigerende tiltak slik at det kan påvises at sikkerhetsproblemer knyttet til programvaren er redusert.
Retrieval and release procedures shall exist such that the software life cycle data can be regenerated and delivered throughout the EATMN software life cycle.
Det skal finnes framgangsmåter for gjenfinning og frigivelse av data slik at programvaresyklusdata kan gjenopprettes og leveres i EATMN-programvarens samlede livssyklus.
Requirements applying to the software safety requirements traceability assurances referred to in Article 4(3)(d)
Krav som gjelder sporbarheten for sikkerhetskravene til programvare i henhold til artikkel 4 nr. 3 bokstav d)
Each software safety requirement shall be traced to the same level of design at which its satisfaction is demonstrated.
Hvert sikkerhetskrav til programvare skal spores tilbake til det designnivå det skal tilfredsstille.
Each software safety requirement, at each level in the design at which its satisfaction is demonstrated, shall be traced to a system safety requirement.
Hvert sikkerhetskrav til programvare på hvert designnivå det skal tilfredsstille, skal føres tilbake til et sikkerhetskrav til systemet.
implementing Directive 2004/36/EC of the European Parliament and of the Council as regards the prioritisation of ramp inspections on aircraft using Community airports
om gjennomføring av europaparlaments- og rådsdirektiv 2004/36/EF når det gjelder prioritering av inspeksjoner på bakken av luftfartøyer som benytter lufthavner i Fellesskapet
It requires the Member States to conduct ramp inspections on third-country aircraft suspected of non-compliance with international safety standards landing at any of its airports open to international air traffic following a harmonised procedure, and to participate to the collection and exchange of information on the ramp inspections carried out.
Direktivet inneholder krav om at medlemsstatene foretar inspeksjoner på bakken, etter en harmonisert framgangsmåte, av tredjestaters luftfartøyer som lander i en av deres lufthavner som er åpen for internasjonal lufttrafikk, dersom det foreligger mistanke om at luftfartøyene ikke overholder internasjonale sikkerhetsstandarder, samt krav om at medlemsstatene deltar i innsamlingen og utvekslingen av opplysninger om de inspeksjoner på bakken som er foretatt.
In order to maximise the limited resources available to the competent inspection authorities of each Member State, they should give priority to conducting ramp inspections of certain categories of operators and aircraft which are particularly susceptible to safety deficiencies.
For at vedkommende inspeksjonsmyndighet i hver enkelt medlemsstat i størst mulig grad skal kunne utnytte de begrensede ressurser de har til rådighet, bør de prioritere inspeksjoner på bakken av visse kategorier av operatører og luftfartøyer som er særlig utsatt for sikkerhetsmangler.
«prioritisation of ramp inspections» means the dedication of an appropriate portion of the total number of ramp inspections conducted by a Member State on an annual basis, as provided under Article 2 of this Regulation;
«prioritering av inspeksjoner på bakken» øremerking av en passende andel av det samlede antall inspeksjoner på bakken som en medlemsstat foretar hvert år, som fastsatt i artikkel 2 i denne forordning,
«subject» means an operator and/or all operators from a particular State and/or an aircraft type and/or a particular aircraft.
«inspeksjonsobjekt» en operatør og/eller alle operatører fra en bestemt stat og/eller en luftfartøytype og/eller et bestemt luftfartøy.
Prioritisation criteria
Prioriteringskriterier
Without prejudice to Article 8(3) of Directive 2004/36/EC, Member States shall prioritise their ramp inspections on the following subjects landing at any of their airports open to international air traffic:
Uten at artikkel 8 nr. 3 i direktiv 2004/36/EF berøres, skal medlemsstatene prioritere inspeksjoner på bakken av følgende inspeksjonsobjekter som lander i en av deres lufthavner som er åpen for internasjonal lufttrafikk:
Subjects identified as posing a potential safety threat on the basis of the regular analyses conducted by the European Aviation Safety Agency (EASA).
Inspeksjonsobjekter som ifølge de regelmessige analyser som utføres av Det europeiske flysikkerhetsbyrå (EASA), utgjør en mulig fare for sikkerheten.
Subjects identified on the basis of an opinion expressed by the Air Safety Committee within the context of the implementation of Regulation (EC) No 2111/2005 of the European Parliament and the Council(
Inspeksjonsobjekter som ifølge en uttalelse fra Flysikkerhetskomiteen i forbindelse med gjennomføringen av europaparlaments- og rådsforordning (EF) nr. 2111/2005(