Onboard Software
other
Onboard Software

Onboard software aircraft

 

The main purpose of regulatory documents and standards is to provide guidance materials for use in the processes of creating software for aircraft on-board systems, which must perform appropriate functions with a level of safety confidence that meets the requirements for aircraft airworthiness.

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 of functional on-board systems and software level. The main purpose of certification procedures is, first of all, obtaining certain security guarantees: preventing death, bodily harm, deteriorating health of people, loss of property. The beginning of work on the certification of software of any complex technical system is the analysis of possible consequences of the loss (violation) of the function of the system on the safety of its operation or use for human and property. And it does not matter what caused the violation of the function - user error, hardware failure or software design errors. Important are the depth of system control, detection and the ability to parry failures by the system itself or a system of a higher hierarchy level, the need for redundancy, reconfiguration. The analysis of the consequences of the violation of the function of the system, as a rule, has to be returned repeatedly after the following stages, since the rigidity of the software requirements depends on the correct definition of the criticality category of the system.

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 software level B software of such a functional system, the failure state of which, due to an error in the software, may lead to an emergency situation for the aircraft. The emergency situation is characterized by a significant deterioration in the characteristics of the aircraft or exceeding its limiting limits, as well as the physical stress of the flight crew, in which he can not perform his functions precisely and completely. An emergency situation can lead to significant damage to the aircraft, injury to people or individual victims. The probability of such a situation for one hour of flight should be extremely unlikely, ie, be in the range of 10 M0 ~ 9;

  • C level software - software of such a functional system, the failure state of which, due to an error in the software, can lead to a complicated situation for the aircraft. The difficult situation is characterized by a noticeable deterioration in the characteristics of the aircraft, the release of one or more parameters for operational limitations, but without reaching limiting limits, as well as reducing the ability of the crew to cope with this situation due to increased workload and due to unfavorable conditions that reduce the effectiveness of the crew . A difficult situation can cause discomfort to passengers, including, possibly, injuries. The probability of a difficult situation for one flight hour should be unlikely, that is, be in the range of 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 depends not only on the criticality category of the function. A significant role is played by the architecture of the system and the structure of its software. For example, the analyzed system can have a redundant analog channel, which completely duplicates the functions of the digital channel. In certain circumstances this may be sufficient to reduce the level of software. Conversely, in the case where the analyzed system is used in one VS in such a way that its failure meets one criterion category, and on the other VS the failure of the same system leads to more critical operating conditions, the system developer can determine a higher level of software. The methods of designing it also have an important influence on the definition of the software level. For examplemeasures, 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 probability of occurrence of special situations do not concern the probability of undetected errors in the software. It is impossible to apply the developed mathematical apparatus of the theory of statistics to the software, which makes it possible to calculate the probability of events, since there is no direct connection between the probability of occurrence of special situations and the probability of not revealing errors in the software. Thus, software levels or reliability indicators based on software levels can not be used in the process of evaluating system security, for example, as the intensity of hardware failures is used.

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 initial material for initiating software development processes is the declared requirements for the system, which must be formalized in the form of an appropriate document (DF <"zero">), and which must be converted into software requirements (D1), precisely due to the fact that the implementation functions of digital electronic systems, as already noted, is carried out by software. The software requirements development process (P1) is the process of transforming system requirements into 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 directly derived from an analysis of the requirements for the system, taking into account the specifics of its construction. It is necessary to observe the following conditions: each requirement for the system should be transferred to one or more requirements for high-level software, and vice versa, each requirement for high-level software - for one or more system requirements, with the exception of derivative requirements that do not arise directly From the system requirements (for example, the requirement of interrupt handling, depending on the features of the selected target calculator). Derived high-level requirements must be transferred to the system security evaluation process. High-level requirements include functional and technical requirements, interoperability requirements 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.

The accompanying documents are standards and other normative documents (D2) for technical assignments, for design, for coding, for maintenance. Verification measure, completing the first stage of development, is a comparison of software requirements with system requirements in order to verify the compatibility of the distribution of functions between hardware and software and interfaces, completeness and adequacy of software requirements. The recommended form of documentation is a cross-reference table, which can be designed as a separate verification document, or be part of a general document describing the verification procedures for all phases, their results, and the emerging problems and measures for their elimination.

The next stages of development are planning the processes of creating software and managing its quality. The main goal of the planning is to determine the resources and the sequence of actions to achieve the set goals. Here the organization (interrelation) of processes is still determined. As a result, five documents must be issued (reasonable combination is allowed): software certification plan (DZ), software development plan, verification plan, and software configuration management plans (D6) and quality assurance. Verification activities (В2, ВЗ) refer, basically, to the procedures for coordinating plans at the approval stage, as well as to their correction based on observations that occurred at later stages of the creation and even operation of the software. The content of the documents is discussed further.

Continuation of the development process is the process of software design. Here the requirements for high-level software are refined over several iterations of the design process to form the software architecture of the functioning algorithms, taking into account the low-level requirements to such an extent that it is possible to compile the source code from them. To meet safety requirements, control flows of data and data should be provided, for example, to provide watchdog, consistency checking and crossflow comparison, of course with a corresponding response to "failures". The design results are recorded in the document describing the software project.

Verification event В4 - verification of the software project for compliance with software requirements and design standards, including checking the algorithms of the system operation. The main purpose of verification of the project is to ensure its "verifiability". At the same time, at least such factors must be taken into account: sequence of program execution, data flows and possible distortion thereof, potential influence of hardware on isolation and integrity of functions. In the verification document, D13, the table of compliance of the software project with software requirements in the form of cross-analysis should be presented. Deviations from 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 a process that implements low-level requirements is always the source code (D9), which should be transformed into a software project. Accounting software architecture in the design process is implemented in the procedures for integrating software components, and the integration of software into the target computer will eventually give the executable object code (DU) and the corresponding software bundle (D11). Incorrect or insufficient input data identified in these processes should be returned to previous processes for correction or clarification. In addition, the environment for creating software (which, most often, and its environment of support) should be clearly and in detail 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 model, the highest ("optimizing") level of technological maturity - the fifth one - corresponds entirely to the automated process of software production on the basis of a mathematical model using the methods of parametric and structural optimization, and the organization focuses on improving the processes. One of the signs of the lower first ("initial") level is the dependence of the organization on individual programmers, and one of the conditions for transition from the second ("repeated") level to the third ("certain") - documenting the processes under the management of the corresponding service, headed by the person in charge From the top 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.

Blog and articles

upstairs