Translated automatically from the French version of Kelclinic. Contact us for remarks, questions or help.
russian English French German italian spanish
Onboard Software
other
Onboard Software

Onboard software aircraft

 

The main purpose of regulations and standards - presentation of instructional materials for use in the processes of software development aircraft on-board systems that have to perform proper function to the level of security assurance to meet the requirements of the airworthiness of aircraft.

Among international instruments containing software requirements AT is the most important document DO-178, first formulated in 1978 At the present time it is used improved versions: DO-I78A, in force since 1985 city, and DO-I78B, in force since 1993 , at which significant attention is paid to the issue of qualification of software tools.

In Ukraine and Russia, there are analogues of these documents: respectively CT 178A with 1998 city and CT 178V with 2004, the addition to these eligibility requirements are documents 178A RM and RM-178V.

Among the series of standards ISO, operating in Ukraine and related software, is dominated by two: DSTU ISO 9000-3-98 and DSTU 3918-1999 (ISO / IEC 12207: 1995). The first is devoted to the organization and activities of the quality system in relation to the software, the second process life cycle software. The requirements of ISO standards directly related to the certification procedures sun and its components, including software certification procedures.

In addition, the certification of enterprises aviation industry, in this case, the production processes of creation and application software used ARMAK document "Guidelines 21.2S", namely section "Element 3. Quality assurance software "which is divided into two parts:" Part A. The onboard software "and" Part B: software for the acceptance of products. "

Software refers to the onboard software of the electronic systems of the Armed Forces, which includes part of the certification basis of the Armed Forces of a certain type and installed on board for the purpose of performing the necessary functions for the operation of the Armed Forces. Software systems designed, for example, for testing the Sun, though installed on board the aircraft is not airborne, and refers to the process of creating instruments AT.

Since the functions of onboard digital systems are implemented via software, the latter is the subject of particular attention certification body due to its direct impact on the safe operation of aircraft.

Criticality functional onboard systems and software level. The main purpose of certification procedures - is, above all, to obtain certain guarantees of security: prevention of death, injury, ill health, loss of property. The beginning of work on the certification for any complex technical system is to analyze the possible consequences of the loss (impairment) of the safety features of its work or the use of human and property. And it does not matter what caused the dysfunction - user error, hardware failure or software design errors. Important are the depth control system, the identification and the ability to parry bounce means of the system or a higher level of the hierarchy, the need for redundancy, reconfiguration. To analyze the consequences of violation of functions of the system, as a rule, you have to go back many times after the following steps, as the correct definition of the category of severity depends on the rigidity of the requirements to the software.

CT 178V document defines five categories of severity of functional systems and thus five levels of software. Despite the fact that for certain categories of critical systems and software levels are rigidly connected, the process of establishing levels of permissible deviations in one or the other side.

Classification level software criticality categories as follows:

  • IN A level - on such a functional system failure conditions which has arisen due to an error in the software could lead to a catastrophic situation for the sun when it is practically impossible to prevent the death of the sun and the people. The likelihood of such a situation, one hour flight to be almost unbelievable, t. E. Less than 10 ~ 9;

  • The levels in such a functional software system failure conditions which has arisen due to an error in the software could lead to an emergency situation for the aircraft. An emergency situation characterized by a significant deterioration of the sun or exceeding its limit restrictions, as well as such physical stress of the flight crew, in which he can not accurately and fully perform their functions. An emergency situation can lead to significant sun damage, personal injury, or to individual victims. The likelihood of such a situation, one hour flight to be highly unlikely, that is. e. be in the range 10 M0 ~ 9;

  • ON level from - to such a functional system failure conditions which has arisen due to an error in the software could lead to a difficult situation for the aircraft. The difficult situation characterized by a marked deterioration of the sun, the output of one or more parameters for the operating restrictions, but without reaching the limiting constraints, as well as a decrease in the ability of the crew to cope with this situation due to increased workload and because of unfavorable conditions, which reduce the effectiveness of the crew . The difficult situation can cause discomfort to passengers, including possibly injury. The likelihood of a difficult situation on the one hour flight to be unlikely, ie. e. be in the range 10 5-10-7;

  • According to the level D - IN a functional system failure conditions which has arisen due to an error in the software could lead to a complication of flight conditions for aircraft. This situation is characterized by a slight deterioration of the sun or a slight increase in the workload of the crew. This situation can be avoided, for example by changing the flight plan, and for passengers, it should not lead to more than some inconveniences;

  • According to the level of E - ON this functional system, which the state exemption, which arose due to an error in the software does not affect the operational capabilities of the Armed Forces and does not increase the load on the crew. Getting from the certification body to confirm that the software belongs to the level E, it means that the provisions of the document CT 178V not apply to him.

 

CT 178A document defines three categories of critical functions onboard aircraft systems:

  • essential if a special situation which may arise in the performance of violation of at least one of the functions of the Armed Forces, is characterized as catastrophic or emergency;

  • Importantly, if a special situation which may arise in the performance of violation of at least one of the functions of the Armed Forces, are complex;

  • insignificant if a special situation which may arise in the performance of violation of at least one of the functions of the Armed Forces, is to complicate the flight conditions or implications.

 

Accordingly, there are three levels of software:

  • 1 level for the category of "critical" to the most demanding software and the maximum amount of work that must be fulfilled in order to prove compliance with certification requirements and the maximum amount of supporting documentation;

  • level 2 - for the category "substantial" with lower requirements;

  • level 3 - for the category of "non-essential" with the minimum requirements.

The level of software does not depend only on the category of critical functions. Important role played by the architecture of the system and the structure of its software. For example, the system can be analyzed have a backup analogue channel that fully duplicate the functions of the digital channel. Under certain circumstances, this may be sufficient to reduce the level of software. Conversely, when analyzed on a Sun system is used such that it corresponds to one category rejection criticality, and by other AC rejection of the system leads to a critical operating conditions, the system designer can determine the higher level software. An important influence in determining the level of the software are also methods of design. Egmeasures, the method of isolation or control as a method of protection against certain failure conditions by continuous validation of the function or multi-versioned method, the implementation of which envisages the creation of two or more software components that perform one function in different ways and to different software provides the ability to separate functionally independent software components to isolate failures.

The above quantitative values ​​of the likelihood of exceptions do not apply to the probability of undetected errors in software. It is impossible to apply software developed mathematical apparatus of the theory of statistics, which barks possible to calculate the probability of events, as there is no direct link between the probability of occurrence of particular situations and are not likely to detect errors in the software. Thus, levels of reliability or performance, based on the levels of the software can not be used in the evaluation of system security, such as using the intensity of a hardware failure.

However, the regulations recommend the use of these or other quantitative criteria for assessing the quality of the software or to achieve a certain level of quality, taking into account the fact that the software industry has accumulated a large collection of models and metrics that allow you to evaluate different characteristics of software. Furthermore, during the development and verification of software is strongly recommended to keep a record of the detected errors and disadvantages, as well as measures taken to address them.

 

The processes of development, verification and validation of software

The main step in the creation of any technical product is its design, including prototyping, test it to verify compliance with the requirements and, in the end, the approval of its serviceability. Creating a software product fully complies with these processes.

Presents the process of creating a software product of interest from the point of view of obtaining certain guarantees of security. Here, every event associated with the development of (P) has a corresponding verification event (B). And they both produce the relevant documents (D).

The starting material to initiate the process of creating the software are stated system requirements that need to be made in the form of a corresponding document (DF <"zero">), and which must be converted into software requirements (D1), is due to the fact that the implementation of functions of digital electronic systems, as already noted, is carried out by software. The process of developing software requirements (R1) - this is the process of transforming the system requirements to software requirements.

To facilitate understanding of the transformation procedure, both during development and its verification procedure is recommended to divide into at least two parts: a high level design requirements and subsequent development requirements low.

High-level requirements are derived directly from the analysis of system requirements, taking into account the peculiarities of its construction. It is necessary to observe the following conditions: each requirement to the system should be transferred to one or more requirements at a high level, and vice versa, every requirement at a high level - in one or more of the system requirements, except for derivative claims that are not directly arise of the requirements for the system (for example, the requirement for handling interrupts, depending on the characteristics of the selected target calculator). Derivatives of high-level requirements must be passed in the process of assessing the safety of the system. For high-level requirements are functional and technical requirements, requirements for interoperability and security requirements.

Low-level requirements are stated in terms of software engineering and are obtained by analyzing and detailing high-level requirements. Requirements low levels are directly related to the procedures of coding and aggregation software, t. E. It is the requirements for the applicable programming languages, compilers, architecture and middleware, to the structure of its components, to the classification of software objects to the operator basis, to the environment, development and verification as well as to the style of programming.

Related documents are standards and other regulatory documents (D2) on technical specifications, design, coding, support. The verification exercise, completing the first stage of development, - a comparison of the requirements for the software system requirements in order to verify the compatibility of the distribution of functions between hardware and software and interfaces, completeness and appropriateness of the requirements for the software. The recommended form of documentation - cross-reference table, which can be issued as a separate document verification, or be part of a general document describing the procedures for the verification of all stages of their results, as well as the problems and measures to address them.

The next stages of development - planning processes of software development and management of its quality. The main purpose of planning - identifying resources and action sequences, ensuring the achievement of the goals. There is still determined by the organization (the relationship) processes. As a result, they should be issued five documents (which is allowed a reasonable combination): Plan Certification Software (RS), the software development plan, plan verification and configuration management plans (D6) and guarantee its quality. Verification activities (V2, OT) relate mainly to the harmonization of procedures for the approval of plans for the stage, as well as their correction on the observations that emerged in the later stages of the operation, and even software. The contents of documents considered further.

The continuation of the development process is the process of designing software. Here the requirements specified by the highest level for several iterations of the design process to form software architecture of algorithms of operation, with the requirements of low level to such an extent that they can be at compile the source code. To meet safety requirements should provide control of control and data flow, for example, to provide a watchdog timer, checking for consistency and comparison cross flow naturally with the corresponding reaction to the "refusal" state. The results are recorded in the design document describing the project on.

Verification V4 event - checking software project for compliance to the software and standards for the design, including testing algorithms of the system. The main purpose of verification of the project is to provide its "verifiability". This should be taken into account, at least the following factors: the sequence of program execution, data flows and possible distortion of their potential impact on the separation of hardware and integrity functions. The document verification D13 should be a table of compliance software project requirements for software in the form of cross-sectional analysis. Deviations from the standards and requirements should be noted and justified.

All of the stages so far, Lager design phase of the software can be described as preliminary. Only as a result of the programming process (R5), interconnecting software components (R6) and the integration of software with hardware (R7) appears own software products in their final form.

The first result of the process of implementing the requirements of a low level, is always a source code (D9), which should be transformed into a project on. Accounting software architecture design process is implemented in the procedures of interconnecting software components, and the integration of the software on the target computer will eventually executable object code (DOJ) and the appropriate directory configuration software (D11). Incorrect or insufficient input data identified in this process, should be returned to the previous processes for making corrections or clarity. In addition, the environment of software development (it is, more often, and among its support) must be clearly and thoroughly defined and fixed (D12).

Needless to say, at this stage of development carried out the most voluminous, the most complex in content and the most important verification measures (V5, V6, V7) under the title - testing (test) software to detect errors contained in the software. The problem here is that the detected errors are usually eliminated, not identified may not even be predicted.

The contents of all three verification measures.

This process consists of a number of iterations, and includes all of the positions in each iteration and for each event. The results of the process are recorded in a document D13.

Review processes of software development would be incomplete without mention of the plans and UKPO GKPO. to be implemented by internal and external audits of the configuration, as well as appropriate organizational and technological procedures, and are reflected in the minutes and D14 D15.

Implementing the plan software certification document D16 fixed.

The cycle of software development is completed the tests confirm the operational suitability of onboard digital functional system (V9). These tests are carried out as part of the official certificate (certification) that the system on this aircraft in the stated operating conditions is functioning correctly.

The documentation for software certification. In the US, there was officially 1987 method Institute SEI (Software Engineering Institute), which allows to determine the level of technological maturity of the companies that develop software and improve the development process. Originally Capability Maturity

Model (CMM), and later - Capability Maturity Model Integration (CMMI). In accordance with the supreme model ("optimizing") the level of technological maturity - the fifth - responds fully automated production process software based on mathematical model using parametric methods and structural optimization and the organization focuses on improving processes. One sign of the lower first ("original") level is the dependence of the organization on individual programmers, and one of the conditions of transition from the second ("repeats") level on the third ("Definitions") - documenting the processes under the control of the relevant service at the head of the person in charge from the senior management of the organization.

All phases of the software life cycle have a beginning and an end to the documentation can exist forever. Therefore, to formulate the requirements for documentation - it means to formulate the requirements for all the above process of creating software. Documentation is the very material factor by which certified software. Documentation is also a key element in the investigation carefully analyzed the prerequisites of disasters or emergencies.

A very important form and content of the document, the inclusion of quantitative and qualitative characteristics of the product, the depth of its monitoring and analysis, the presence of the possibility of recording and storage, the level of responsibility of the persons signing the document. The weakest link in the documentation - complete view of the statement to her demands.

A specific list of documents required for certification of software depends on the software (on the criticality of the system) and is determined in the process of approval of the plan of certification with the certification authority. The following briefly shows the essence and the already mentioned documents.

  • D1 "Software Requirements" - contains a description of the transformation of the system requirements to software requirements with the release of the requirements of high and low levels and with special attention to security and the possible failure conditions. To be defined performance criteria features and possible limitations, such as memory, time-frequency, for interaction. Particular attention is paid to the isolation of software components.

  • D2 - "Standards of software development" - plural list. At least - this is a list of formal standards, requirements development, design, coding, testing software. Along with the standards - a few documents.

  • Their content - methods for creating, structuring rules, restrictions on the project (for example, the exclusion of recursion, dynamic objects, alternative symbols of data), limits on complexity (eg, nesting of calls, the use of hops) on language and compiler, environment and tools.

  • CLE - "Plan software certification" is served for approval to the State certification authority, defines procedures, methods of proving compliance with the requirements of the product to him to a system for the Armed Forces and the required documentation.

  • D4 "software development plan" - defines the life cycle of software development, the interaction of the performers and the development environment.

  • D5 - "Plan software verification" - defines the steps (the position of the development process and criteria for the transition to the verification procedures), techniques, procedures, environment and tools of verification, including software tools, instructions on achieving the necessary quality parameters (safety) and instructions on rescanning and testing after making changes to the software, which guarantee the elimination of the detected errors.

  • D6 - "Software Configuration Management Plan" - sets the rules for identifying software and equipment units, the basic version and traceability on derivative versions of the rules of change management, the rules of order and configuration status accounting, archiving, monitoring and protection of the data handling unit software.

  • D7 - "Plan quality assurance software" sets the scope, responsibilities and powers of inspection and audit and other activities related to the process of obtaining guarantees, including reports of problems, their monitoring and corrective actions.

  • D8 - "Description of the project software" - contains a detailed description of how the software meets the requirements of the high-level requirements, including algorithms, data structures, and how software requirements allocated to tasks and processes. In addition, a description of software architecture, libraries, I / O data flows and control the allocation of resources and the related restrictions, procedures, scheduling, inter-process schemes and inter-application sharing, interrupts, software components, methods for their isolation.

  • D9 "Source Code" - contains the source code, the compiler instructions for code generation, data editing and download links.

  • D10 - "Object executable code" - contains the code which is suitable for the direct implementation of the target processor, calculator, t. E. One that is loaded into the system of avionics equipment.

  • D11 - "Product configuration software" - defines the configuration of the product delivered as a unit. It must identify the software as a whole, each component corresponding to the documents and media.

  • D12 - "Product Environment Software" - contains a description of the software life cycle environment, from the stage of specifying the requirements and finishing phase of the write-off of product use. In the catalog identified by development tools, verification, tracking software, provides data about the qualifications of tools.

  • D13 - "The procedures and the results of verification" may be divided into two or three documents, which must be described procedures for the review, analysis, testing at all stages of development, application examples and test results of the procedures identified components of the software. All the problems and corrective actions should be described in detail.

  • D14 - "Protocols UKPO."

  • D15 - "Protocols GKPO."

  • D16 - "The final conclusion about software" - is the main document that secures the implementation of the "Plan of software certification" and the extent to which the "Software Requirements". It must contain a brief description of the system and software, certification conditions (agreements), characteristics, identification and state of software documentation for a list of software and a statement of the extent to which software requirements.

Comments

CAPTCHA
This question is to determine whether you are a human automated spam submissions.
upstairs