Commission Regulation (EC) No 482/2008 (repealed)Show full title

Article 2 U.K. Definitions

For the purposes of this Regulation, the definitions in Article 2 of Regulation (EC) No 549/2004 shall apply.

The following definitions shall also apply:

1.

‘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;

2.

‘configuration data’ means data that configures a generic software system to a particular instance of its use;

3.

‘non-developmental software’ means a software not developed for the current contract;

4.

‘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;

5.

‘organisation’ means either an ATS provider, a CNS provider or an entity providing ATFM or ASM;

6.

‘functional system’ means a combination of systems, procedures and human resources organised to perform a function within the context of ATM;

7.

‘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;

8.

‘hazard’ means any condition, event, or circumstance which could induce an accident;

9.

‘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;

10.

‘safety objective’ means a qualitative or quantitative statement that defines the maximum frequency or probability at which a hazard can be expected to occur;

11.

‘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;

12.

‘cutover or hot swapping’ means the approach of replacing European air traffic management network (EATMN) system components or software while the system is operational;

13.

‘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;

14.

‘EATMN software’ means software used in the EATMN systems referred to in Article 1;

15.

‘requirements validity’ means the confirmation by examination and provision of objective evidence that the particular requirements for a specific use are as intended;

16.

‘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;

17.

‘software malfunction’ means the inability of a programme to perform a required function correctly;

18.

‘software failure’ means the inability of a programme to perform a required function;

19.

‘COTS’ means a commercial available application sold by vendors through public catalogue listings and not intended to be customised or enhanced;

20.

‘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;

21.

‘independent software components’ means those software components which are not rendered inoperative by the same failure condition that causes the hazard;

22.

‘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;

23.

‘software capacity’ means the ability of the software to handle a given amount of data flow;

24.

‘accuracy’ means the required precision of the computed results;

25.

‘software resource usage’ means the amount of resources within the computer system that can be used by the application software;

26.

‘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;

27.

‘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;

28.

‘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;

29.

‘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;

30.

‘software life cycle’ means:

(a)

an ordered collection of processes determined by an organisation to be sufficient and adequate to produce a software product;

(b)

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;

31.

‘system safety requirement’ means a safety requirement derived for a functional system.