Daniel Kästner

Markus Pister

Christian Ferdinand

Obtaining DO-178C Certification Credits by Static Program Analysis

Keywords: DO-178C, DO-330, DO-333, certification, static analysis, abstract interpretation, tool qualification

Static analysis has evolved to be a standard method in the software development and verification process. Its formal method, Abstract Interpretation, is one of verification methods covered by the Formal Methods Supplement DO-333 of the DO-178C standard. Static program analysis can contribute to numerous verification goals of DO-178C at various stages of the development process. The main focus of static analysis methods are non-functional software quality hazards, e.g., violations of coding guidelines, violations of software architecture constraints, violations of resource bounds such as stack overflows and realtime deadlines, runtime errors, and data races. This article gives a brief overview of abstract interpretation and its applications to detect different classes of safety hazards. We will review the requirements of DO-178C/DO-333, from High-Level Requirements to requirements for verification of Executable Object Code, and pinpoint aspects that can be covered by static analysis methods. The article concludes with illustrating the relevant requirements for DO-330-compliant tool qualification of static analysis tools.

Introduction

Some years ago, static analysis meant manual review of programs. Nowadays, automatic static analysis tools have been established in modern software development processes as they offer a tremendous increase in productivity by automatically checking the code under a wide range of criteria. Here, the term static analysis is used to describe a variety of program analysis techniques with the common property that the results are only based on the software structure. No execution of the program under analysis is needed. Static analysis can be applied to any kind of program representation, from the model level or the source code level to the executable object code level.

An important distinction of static analysis methods is the complexity of the program properties they aim at determining and the level of rigor at which they operate. In the simplest form, static analysis is focused on the program syntax: purely syntactical methods can be applied to check syntactical coding rules as contained in coding guidelines, such as MISRA C [START_REF] Misra | MISRA-C:2012 Guidelines for the use of the C language in critical systems[END_REF], SEI CERT C [START_REF]SEI CERT C Coding Standard -Rules for Developing Safe, Reliable, and Secure Systems[END_REF], or the Common Weakness Enumeration (CWE) [START_REF]CWE -Common Weakness Enumeration[END_REF]. They aim at a programming style that improves clarity and reduces the risk of introducing bugs. Compliance checking by static analysis tools has become common practice.

Syntactic rules play an important part in coding standards as they are easy to take into acccount while implementing code, and easy to check. However, ultimately, the objective is to prevent code defects which means that semantical properties have to be considered. To that end semantics-based static analyzers are needed which focus on the program semantics and compute invariants about variable values, pointer targets, etc. This is also relevant for coding standard compliance checking, since all commonly used coding guidelines also include semantical rules.

Depending on the level of rigor, semantics-based methods can be grouped into unsound and sound approaches, the essential difference being that when a sound method reports the property under analysis -such as freedom of runtime errors -as satisfied, this is guaranteed to be true. Abstract interpretation is a formal method for sound semantics-based static program analysis [START_REF] Cousot | Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints[END_REF]. It supports formal correctness proofs: it can be proved that an analysis will terminate and that it is sound in the sense that it computes an over-approximation of the concrete program semantics. Abstract interpretation always provides full data and control coverage.

As of today, abstract interpretation-based static analyzers are most widely used to determine non-functional software quality properties [START_REF] Kästner | Efficient Verification of Non-Functional Safety Properties by Abstract Interpretation: Timing, Stack Consumption, and Absence of Runtime Errors[END_REF][START_REF] Kästner | Applying Abstract Interpretation to Demonstrate Functional Safety[END_REF]. On the one hand that includes source code properties, such as compliance to coding guidelines, compliance to software architectural requirements, as well as absence of runtime errors and data races [START_REF] Kästner | High-Precision Sound Analysis to Find Safety and Cybersecurity Defects[END_REF]. On the other hand also low-level code properties are covered such as absence of stack overflows and violation of timing constraints [START_REF] Kästner | Proving the Absence of Stack Overflows[END_REF][START_REF] Kästner | Confidence in Timing. Safecomp 2013 Workshop: Next Generation of System Assurance Approaches for Safety-Critical Systems (SASSUR)[END_REF].

Violations of non-functional software quality requirements often either directly represent safety hazards and cybersecurity vulnerabilities in safety-or security-relevant code, or they can indirectly trigger them. Hence they are invariably addressed by verification obligations in current safety and security norms, such as DO-178C [START_REF]Airborne Systems and Equipment Certification[END_REF], IEC-61508 [START_REF]Functional safety of electrical/electronic[END_REF], ISO-26262 [START_REF]Road vehicles -Functional safety[END_REF], and EN-50128 [START_REF]Railway applications -Communication, signalling and processing systems -Software for railway control and protection systems[END_REF].

In this article we will focus on the DO-178C standard [START_REF]Airborne Systems and Equipment Certification[END_REF], its formal method supplement DO-333 [41], and the DO-330 [START_REF]Software Tool Qualification Considerations[END_REF] which details the tool qualification requirements to be taken into account. We will review the software requirements and verification goals that are amenable to static analyses and hence identify the certification credits that can be obtained by applying different static analysis methods at different levels of the development process. Sec. 2 walks through the DO-178C norm and highlights the relevant software requirements and verification objectives. Sec. 3 illustrates the methodology of static program analysis and presents the fundamentals of its application to compute various non-functional software properties. Sec. 4 then summarizes the verification goals supported by the various applications of static analysis. A brief overview of the tool qualification requirements relevant to static program analysis tools is given in Sec. 5, and Sec. 6 concludes.

DO-178C / DO-333

The DO-178C [START_REF]Airborne Systems and Equipment Certification[END_REF], published in December 2011, is a revision of DO-178B to take progress in software development and verification technologies into account. In general, the DO-178C aims at providing "guidance for determining, in a consistent manner and with an acceptable level of confidence, that the software aspects of airborne systems and equipment comply with airworthiness requirements." It specifically focuses on model-based software development, object-oriented software, the use and qualification of software tools and the use of formal methods to complement or replace dynamic testing. Each of these key aspects is addressed by a dedicated supplement which modifies, complements, and completes the DO-178C core document. The supplements "should be used with and in the same way" as the core document [START_REF]Airborne Systems and Equipment Certification[END_REF]. In this overview we will specifically focus on the DO-178C core document and DO-333 (Formal Methods Supplement to DO-178C and DO-278A) [41].

The DO-178C first discusses general system aspects which are relevant for software development and defines the software life cycle processes, which then are addressed in turn: the software planning, development, and verification processes, as well as the configuration management, quality assurance, and certification processes. The norm also details the software life cycle data and addresses additional considerations, such as tool qualification requirements. In this section we will follow that structure and pinpoint the respective requirements and verification objectives amenable to static analysis techniques. Considerations for formal methods are addressed at the end of this section, tool qualification is addressed in Sec. 5.

System Aspects

System aspects relevant for software development include functional and operational requirements, performance requirements and safety-related requirements, including design constraints and design methods, in particular partitioning (cf. Sec. DO.2.1 of DO-178C [START_REF]Airborne Systems and Equipment Certification[END_REF]). The norm emphasizes that timing and performance characteristics require special attention since they affect the system software and the softwarehardware boundaries and have to be included in the respective information flows.

The DO-178C defines five software levels (criticality levels) ranging from Level A (most critical) to Level E (least critical). According to Sec. DO.2.3 only partitioned software components can be assigned individual software levels by the system safety assessment process. Sec. DO.2.4, Architectural Considerations, states that "if partitioning and independence between software components cannot be demonstrated, all components are assigned the software level associated with the most severe failure condition to which the software can contribute". The standard defines partitioning as a "technique for providing iso-lation between software components to contain and/or isolate faults and potentially reduce the effort of the software verification process". Among others, a partitioned software component "should not be allowed to contaminate another partitioned software component's code, input/output, or data storage areas", and it "should be allowed to consume shared processor resources only during its scheduled period of execution". Thus, freedom of interference, both in the spatial and the temporal domain, is recognized as an important architectural property.

Software Planning & Development Process

In Sec. DO.4.4.2, Language and Compiler Considerations, the DO-178C points out that the software verification process needs to consider particular features of the programming language and compiler. In Sec. DO.4.5 the use of Software Development Standards is demanded which include Software Design Standards and Software Code Standards. One of the goals is to "disallow the use of constructs or methods that produce outputs that cannot be verified or that are not compatible with safety-related requirements". The defined Software Development Standards have to be taken into account during software design and coding (cf. Sec. DO.5.2.2 and Sec. DO.5.3.2).

The Software Design Standards are defined to focus on algorithmic constraints like exclusion of recursion, dynamic objects, or data aliases (cf. Sec. DO.11.7e). They should also include complexity restrictions like maximum level of nested calls, use of unconditional branches, or number of entry/exit points of code components (cf. Sec. DO.11.7f).

The Software Code Standards focus on the programming language. They identify the programming language to be used and should define a safety-oriented language subset (cf. Sec. DO.11.8a). To improve readability (and hence verifiability) they should cover style rules like length restrictions, indentation, and documentation rules (cf. Sec. DO.11.8c), and impose further constraints on code complexity, e.g., regarding the complexity of logical and numerical expressions (cf. Sec. DO.11.8d).

Software Verification Process

Like the DO-178B, the DO-178C addresses the incompleteness of testing techniques: "Verification is not simply testing. Testing, in general, cannot show the absence of errors". Since formal methods are sound they can completely satisfy some verification objectives while for others additional verification such as complimentary testing may be necessary. Purpose and objective of the software verification process are defined in the same way as in the DO-178B: The purpose of the software verification process is to detect and report errors that may have been introduced during the software development processes. Removal of the errors is an activity of the software development processes. The general objectives of the software verification process are to verify that the requirements of the system level, the architecture level, the source code level and the executable object code level are satisfied, and that the means used to satisfy these objectives are technically correct and complete.

As described in Sec. 2.1 non-functional software properties can affect the system and the software level, and consequently, they are addressed at all levels of the software verification process. Design constraints may apply to ensure verifiability of the software.

The software verification process comprises reviews and analyses of high-level requirements, low-level requirements, the software architecture, the source code, and requires testing or formal analysis of the executable object code. One common verification objective at all levels is to demonstrate the compliance with the requirements of the parent level. As the system requirements include performance and safety-related requirements non-functional aspects like timing or storage usage can impact all stages. Consequently, the compatibility with the target computer is a verification objective among the high-level requirements, the low-level requirements, and at the software architecture level.

According to Sec. DO.6.2 the software verification activities have to address the "accuracy, completeness, and verifiability of the software requirements, software architecture, and Source Code". In particular objective 6.3.2.d for reviews and analysis of low-level requirements demands to ensure that each low-level requirement can be verified. Objective 6.4.3.e demands to ensure that the Software Design Standards were followed during the software design process and that deviations from the standards are justified. Also during review and analyses of source code (Sec. DO.6.3.4) the Software Development Standards have to be addressed. Objective 6.3.4.c which aims at verifiability demands to ensure that no statements and structures that cannot be verified are contained in the Source Code. Objective 6.3.4.d demands to show conformance to the Software Code Standards defined, e.g., that complexity limits have been considered. Deviations from the standards have to be justified.

In Sec. DO.6.3 of [START_REF]Airborne Systems and Equipment Certification[END_REF] the system response time is given as an example of target computer properties relevant for high-level requirements and low-level requirements. Computing the response time requires the worst-case execution time to be known. At the source-code level the objective accuracy and consistency explicitly includes determining the worst-case execution time, the stack usage, and runtime errors (memory usage, fixed-point arithmetic overflow and resolution, floating-point arithmetic, use of uninitialized variables). All these characteristics can be checked using formal analysis (cf. Sec. FM. 6.3.4 of [41]).

The data and control flow of the software is of crucial importance for the verification of functional and non-functional correctness properties. In the DO-178C, the verification goal 6.3.3.b (Consistency) demands that "a correct relationship exists between the components of the software architecture. This relationship exists via data flow and control flow." It is complemented by the verification goal of Sec. DO.6.3.4.b (Compliance with the software architecture) which demands to "ensure that the source code matches the data flow and control flow defined in the software architecture". Obviously the data and control flow of the implemented software must match the intended data and control flow as specified in the software architecture, and unintended data and control flow must be avoided. In particular, this implies demonstrating freedom of interference between software components in mixed-criticality software. In addition, the data and control flow also determines the required effort for functional testing. In DO-178C, Objective 8 of Annex A Table A-7 requires that "Test coverage of software structure (data and control coupling) is achieved", referencing Sec. DO.6.4.4.2.c which states that structural coverage analysis should "confirm that the requirements-based testing has exercised the data and control coupling between code components". An in-depth discussion of data and control coupling analysis is given in [START_REF] Kästner | Static Data and Control Coupling Analysis[END_REF].

Worst-case execution time and worst-case stack usage have to be considered at the Executable Object Code level. The reason is that the impact of the compiler, linker, and of hardware features on the worst-case execution time and stack usage has to be assessed. Both can be checked by formal analyses at the Executable Object Code level (cf. Sec. FM.6.7 of [41]). Runtime errors also can be addressed at the Executable Object level, e.g. to deal with robustness issues like out-of-range loop values and arithmetic overflows (cf. Sec. FM.6.7.b of [41]), or to verify the software component integration. The latter implies, e.g., detecting incorrect initialization of variables, parameter passing errors, and data corruption.

At the Executable Object Level complimentary testing is still required, e.g., to address transient hardware faults, or incorrect interrupt handling (cf. Sec. DO.6.4.3. of [START_REF]Airborne Systems and Equipment Certification[END_REF]). Formal analysis performed at the source code level can be used for verification objectives at the executable object code if property preservation between source code and executable code can be demonstrated (cf. Sec. FM.6.7.f of [41]).

Formal Methods (DO-333)

[41] defines formal methods as "mathematically based techniques for the specification, development, and verification of software aspects of digital systems". It distinguishes three categories of formal analyses: deductive methods, such as theorem proving, model checking, and abstract interpretation. The computation of worst-case execution time bounds and the maximal stack usage are listed as reference applications of abstract interpretation. The importance of soundness is emphasized: "an analysis method can only be regarded as formal analysis if its determination of a property is sound. Sound analysis means that the method never asserts a property to be true when it is not true."

Regarding the applicability of formal methods, the DO-333 states that "formal methods provide comprehensive assurance of particular properties only for those aspects that are formalized in the formal model, so defining the limits of the model is essential." Formal analyses at the source code level have to be based on a formal source code semantics. For formal analyses done at the object code level, the object code becomes a formal model the semantics of which are treated as they are by the target hardware. When formal analysis is used to meet a verification objective, it has to be ensured that each formal method used is correctly defined, justified, and appropriate to meet this verification objective (cf. Sec. FM. [START_REF] Barr | Camry software Analysis by Michael Barr[END_REF]

.2.1 of [41]):

• all notations used for formal analysis should be formal notations

• the soundness of each formal analysis method should be justified • all assumptions related to each formal analysis should be described and justified; for example assumptions associated with the target computer or about the data range limits.

At the Executable Object Level, coverage analysis depends on whether formal methods are used to complement or to replace dynamic testing methods. When any low-level testing is used to verify low-level requirements for a software component then the entire software component will be subject to test coverage analysis consisting of requirements-based coverage analysis and structural coverage analysis. Requirements-based coverage analysis establishes that verification evidence exists for all of the requirements of the system. Structural coverage analysis is necessary since no exhaustive testing is achievable and used to ensure that the testing performed is rigorous and sufficient (cf. Sec. DO.6.4. of [START_REF]Airborne Systems and Equipment Certification[END_REF], Sec. FM.6.7.1 of [41], and Sec. FM.12.3.5 of [41]).

When only formal methods are used to verify requirements for a software component, a different coverage analysis for that component has to be performed, consisting of the following steps (cf. Sec. FM.6.7.2 of [41]):

• requirements-based coverage analysis to determine how well the implementation of the software requirements has been verified.

• complete coverage of each requirement to ensure that all assumptions made during the formal analysis are verified.

If the assumptions are all verified then the formal analysis can give complete coverage of each requirement.

• completeness of the set of requirements

• detection of unintended dataflow relationships

• detection of extraneous code, including dead code and deactivated code

• review and analyses of the formal analysis cases, procedures, and results for the executable object code.

Static Analysis & Abstract Interpretation

Static analysis often is perceived as a technique for source code analysis at the programming language level, but it can also be applied at the binary machine code level. In that case it does not compute an approximation of a programming language semantics, but an approximation of the semantics of the machine code of the microprocessor. The theory of abstract interpretation [START_REF] Cousot | Abstract interpretation: a unified lattice model for static analysis of programs by construction or approximation of fixpoints[END_REF] is a mathematically rigorous formalism providing a semantics-based methodology for static program analysis. The semantics of a programming language is a formal description of the behavior of programs. The most precise semantics is the so-called concrete semantics, describing closely the actual execution of the program. Yet in general, the concrete semantics is not computable. Even under the assumption that the program terminates, it is too detailed to allow for efficient computations. The solution is to introduce an abstract semantics that approximates the concrete semantics of the program and is efficiently computable. This abstract semantics can be chosen as the basis for a static analysis. Compared to an analysis of the concrete semantics, the analysis result may be less precise but the computation may be significantly faster. Abstract interpretation based static analyzers have been demonstrated to scale up to industry-size software projects containing millions of line of code [START_REF] Kästner | Finding All Potential Runtime Errors and Data Races in Automotive Software[END_REF][START_REF] Kästner | Analyze This! Sound Static Analysis for Integration Verification of Large-Scale Automotive Software[END_REF].

In the remainder of this section we will describe how static analysis, and abstract interpretation in particular, can be applied to code guideline checking, software architecture analysis, runtime error analysis, and to determine worst-case stack usage and worst-case execution times. Code guideline checking, software architecture analysis and run-time error analysis operate at the source code level. Worst-case stack usage analysis and worst-case execution time analysis are performed at the binary level, because they have to take the instruction set and hardware architecture into account. As explained above, a sound analysis computes a safe over-approximation of the concrete semantics and reports any potential defect of the defect classes under analysis:

• For worst-case execution time analysis soundness means that the reported WCET is never below the actual execution time in some execution environment. Overestimations may occur.

• In the same way, the computed stack height must never be below the stack usage in any concrete execution. Overestimations may occur.

• For run-time error analysis soundness means that the analysis never omits to signal an error that can appear in some execution environment. False alarms may occur.

Code Guideline Checking

Coding guidelines aim at improving code quality and can be considered a prerequisite for developing safety-or securityrelevant software. In particular, obeying coding guidelines is strongly recommended by all current safety standards. The norms do not enforce compliance to a particular coding guideline, but define properties to be checked by the coding standards applied. As an example, the ISO 26262 gives a list of topics to be covered, including enforcement of low complexity, enforcing usage of a language subset, enforcing strong typing, and use of well-trusted design principles (cf. [START_REF]Road vehicles -Functional safety -Part 6: Product development at the software level[END_REF], Table 1). The language subset to be enforced should exclude, e.g., ambiguously defined language constructs, language constructs that could result in unhandled runtime errors, and language constructs known to be error-prone. As discussed in Sec. 2 the DO-178C is less prescriptive, but mandates coding guidelines nontheless.

There is a variety of code guidelines, in particular for C and C++, which are widely used in industry. The most prominent guidelines for C are MISRA C:2012 [START_REF] Misra | MISRA-C:2012 Guidelines for the use of the C language in critical systems[END_REF], ISO/IEC TS 17961 [START_REF]Information Technology -Programming Languages, Their Environments and System Software Interfaces -Secure Coding Rules[END_REF], the SEI CERT C Coding Standard [START_REF]SEI CERT C Coding Standard -Rules for Developing Safe, Reliable, and Secure Systems[END_REF], and the MITRE Common Weakness Enumeration CWE [START_REF]CWE -Common Weakness Enumeration[END_REF]. Prominent coding standards for C++ include MISRA C++:2008 [START_REF] Misra | MISRA C++:2008 Guidelines for the use of the C++ language in critical systems[END_REF], the SEI CERT C++ Coding Standard [43], the C++ Core Guidelines [START_REF] Bjarne | C++ Core Guidelines[END_REF], the Adaptive AUTOSAR C++ Coding Guidelines [START_REF] Autosar | Guidelines for the use of the C++14 language in critical and safety-related systems[END_REF], and the Joint Strike Fighter Air Vehicle C++ Coding Standards [START_REF] Martin | Joint strike fighter air vehicle c++ coding standards for the system development and demonstration program[END_REF]. However, as of 2021, the discussion which C++ language features should be admitted to which extent for safety-critical software projects, is in full swing, and there is no clear consensus yet [START_REF] Kästner | Safety-Critical Software Development in C++[END_REF].

Most coding guidelines try to make coding rules easy to follow for programmers, and easy to check by automatic tools, hence, many coding rules are formulated at the syntactic level. They can be addressed by static analyzers operating purely on the program syntax.

However, obeying syntactic coding guidelines can reduce the risk of programming errors but not prevent them. Hence, all coding standards also explicitly contain semantic rules. These rules require a deeper understanding of the code as they focus on semantical properties which requires knowledge about variable values, pointer targets etc. To address such rules, and, in consequence, identify semantical code defects, semanticsbased static analyses can be applied. Many semantical rules are associated with runtime errors due to undefined or unspecified behaviors of the programming language used (cf. Sec. 3.5). All safety norms, including DO-178C, consider demonstrating the absence of such runtime errors explicitly as a verification goal. They typically address general runtime errors (e.g., division by zero, invalid pointer accesses, arithmetic overflows), and additionally consider corruption of content, synchronization mechanisms, and freedom of interference in concurrent execution. This is reflected, e.g., in MISRA C:2012, e.g., by Rule 1. In contrast to other coding standards, MISRA C provides a clear classification which rules are based on semantic properties: typically such rules are labeled as system/undecidable. This is important since -due to their inherent undecidability -for semantical rules there cannot always be a correct and precise "yes" or "no" answer. As discussed above, there can always be false alarms (false positives), and, in case of unsound analyzers, also missed defects (false negatives). Therefore, developers have to be aware of the class and the operational context of the static analysis tool in use.

Software Architecture Analysis

All current safety norms require determining the data and control flow in the source code and making sure that it is compliant to the intended control and data flow as defined in the software architecture. In traditional static code analysis, data accesses via pointer variables and control flow by function pointer calls might be missed.

Using sound static analysis based on abstract interpretation, it is possible to guarantee the absence of runtime errors that could cause memory corruption and control flow corruption. Further-more, it is possible to guarantee that in the analysis, all data and function pointer targets are considered and that the possible data and control coupling is fully captured. This way, a safe approximation of the data and control coupling between software components can be determined. That makes it possible to detect critical data and control flow errors and allows to complement traditional code coverage criteria by the degree of data and control coupling covered by the testing process, helping to identify relevant previously untested scenarios. In addition, freedom of spacial interference between software components can be demonstrated at the source code level [START_REF] Kästner | Static Data and Control Coupling Analysis[END_REF].

Stack Usage Analysis

In safety-critical systems, stack overflows can cause catastrophic damage. The run-time stack (often just called "the stack") typically is the only dynamically allocated memory area. It is used during program execution to keep track of the currently active procedures and facilitate the evaluation of expressions. The maximal stack usage has to be statically known: at configuration time of the system sufficient stack space has to be reserved for each task.

However, the stack height cannot be easily determined from the source code, since it depends on the dynamic call depth of functions, on compiler optimizations, and on link-time optimizations. Overestimating the maximum stack usage means wasting memory resources. Underestimation can lead to stack overflows where memory cells from the stacks of different tasks or other memory areas are overwritten. This can cause crashes due to memory protection violations and can trigger arbitrary erroneous program behavior, if return addresses or other parts of the execution state are modified. In consequence stack overflows are typically hard to diagnose and hard to reproduce, but they are a potential cause of catastrophic failure. One example is the series of accidents caused by unintended acceleration of the 2005 Toyota Camry: the expert witness' report commissioned by the Oklahoma court in 2013 identifies a stack overflow as most probable failure cause [START_REF] Barr | Camry software Analysis by Michael Barr[END_REF]47].

For safe stack size analysis, it is important to work on fully linked binary code, since the effects of code generation -inserting padding bytes, register allocation, etc. -or link-time optimizations have to be taken into account. Hence the static stack usage analysis cannot be based on the source code but must work on the executable machine code. It approximates the semantics of the machine code of the microprocessor by using an abstract model of the processor architecture. The abstract model does not need to cover the entire state of the microprocessor, only the parts affecting the stack space are needed. The hardware state relevant for worst-case stack analysis includes the processor registers and the memory cells. For a naive analysis, only the stack pointer register is needed, but for precise results it is important to perform an elaborate value analysis on the contents of processor register and memory cells.

In the following we will give an overview of the structure and analysis phases of StackAnalyzer [START_REF]StackAnalyzer Website[END_REF], which is an example tool from this category. First, the control-flow graph is reconstructed from the input file, the binary executable. Then a static value analysis computes value ranges for registers and address ranges for instructions accessing memory. StackAnalyzer reports computed branch and call instructions in case their targets cannot be automatically resolved by its value analysis, as well as unbounded recursions. Missing information such as recursion bounds and call targets can be manually specified in a formal annotation language, AIS [START_REF] Kästner | Proving the Absence of Stack Overflows[END_REF]. Function pointer targets can also be automatically imported from an Astrée analysis. By concentrating on the value of the stack pointer during value analysis, StackAnalyzer computes how the stack increases and decreases along the various control-flow paths. This information can be used to derive the maximum stack usage of the entire task. StackAnalyzer takes the entire application into account and interprocedurally analyzes each call site with its precise stack height. The results of StackAnalyzer are presented as annotations in a combined call graph and control-flow graph. It shows the critical path, i.e., the path on which the maximum stack usage is reached which gives important feedback for optimizing the stack usage of the application under analysis. Experimental results show that the analysis is fast and precise so that only few explicit annotations are needeed [START_REF] Kästner | Proving the Absence of Stack Overflows[END_REF].

Worst-Case Execution Time Analysis

In real-time systems the overall correctness depends on the correct timing behavior: each real-time task has to finish before its deadline, hence, reliable bounds of the worst-case execution time (WCET) of real-time tasks have to be determined.

With end-to-end timing measurements timing information is only determined for one concrete input. Due to caches and pipelines the timing behavior of an instruction depends on the program path executed before. Therefore, usually no full test coverage can be achieved and there is no safe test end criterion. Techniques based on code instrumentation modify the code which can significantly change the cache and pipeline behavior (probe effect): the times measured for the instrumented software do not necessarily correspond to the timing behavior of the original software.

One safe method for timing analysis is static analysis by Abstract Interpretation which provides guaranteed upper bounds for WCET of tasks. Static WCET analyzers are available for complex processors with caches and complex pipelines, and, in general, support both single-and multi-core processors. A prerequisite is that good models of the processor/System on-Chip (SoC) architecture can be determined. However, there are modern high performance SoCs which contain unpredictable and/or undocumented components that influence the timing behavior. Analytical results for such processors are unrealistically pessimistic.

A hybrid WCET analysis combines static value, loop and path analysis with measurements to capture the timing behavior of tasks. Compared to end-to-end measurements the advantage of hybrid approaches is that measurements of short code snippets can be taken which cover the complete program under analysis. Based on these measurements a worst-case path can be computed.

In the following we will focus on applications of static analysis to WCET computation and illustrate the basic principles to establish their contribution to verification goals of DO-178C.

For an overview of methods and tools for WCET analysis we refer to [START_REF] Wilhelm | The worst-case execution-time problem-overview of methods and survey of tools[END_REF] , and recommend [START_REF] Maiza | A survey of timing verification techniques for multicore real-time systems[END_REF] for a general survey on methods for timing analysis on multi-core processors.

Timing Predictability

In general, a system is predictable if it is possible to predict its future behavior from the information about its current state [START_REF] Axer | Building timing predictable embedded systems[END_REF]. The primary sources of uncertainty in execution time of an instruction sequence are the program input and the hardware state in which its execution begins. Hardware-related timing predictability can be expressed as the maximal variance in execution time due to different hardware states for an arbitrary but fixed input. Analogously, software-related timing predictability corresponds to the maximal variance in execution time due to different inputs for an arbitrary but fixed initial hardware state.

Even in single-core processors timing predictability is compromised by performance-enhancing hardware mechanisms like caches, pipelines, out-of-order execution, branch prediction and other mechanisms for speculative execution, which can cause significant variations in timing depending on the hardware state. On multi-core architectures, in addition the intercore parallelism becomes relevant. To interconnect the several cores, buses, meshes, crossbars, and also dynamically routed communication structures are used. In that case, the interference delays due to conflicting, simultaneous accesses to shared resources (e.g. main memory) are the main cause of imprecision.

Fully Static WCET Analysis

Static analysis by Abstract Interpretation can provide guaranteed upper bounds for WCET of tasks. Over the past decades, a standard architecture has emerged [START_REF] Ermedahl | A Modular Tool Architecture for Worst-Case Execution Time Analysis[END_REF][START_REF] Ferdinand | Reliable and precise WCET determination for a real-life processor[END_REF] which neither requires code instrumentation nor debug information and is composed of the following major building blocks:

Decoding: The instruction decoder identifies the machine instructions and reconstructs the call and control-flow graph.

To ensure safety of later analysis results, this graph itself must be safe, i.e., all possible paths that can occur during execution of the program must be represented.

Value analysis: Value analysis aims at statically determining the contents of the registers and memory cells at each program point and for each execution context. The results of the value analysis are used to predict the addresses of data accesses, the targets of computed calls and branches, and to find infeasible paths caused by conditions that always evaluate to true, or always evaluate to false in a specific context.

Micro architectural analysis:

The execution of a program is statically simulated by feeding instruction sequences from the control-flow graph to a micro-architectural timing model which is centered around the cache and pipeline architecture. It computes the system state changes induced by the instruction sequence at cycle granularity and keeps track of the elapsing clock cycles.

Path analysis: Based on the results of the combined cache/pipeline analysis the worst-case path of the analyzed code is computed with respect to the execution timing. The execution time of the computed worst-case path is the worst-case execution time for the task.

A tool which implements this architecture is the static WCET analyzer aiT [START_REF] Souyris | Computing the worst case execution time of an avionics program by abstract interpretation[END_REF]. It is available for a variety of microprocessors including multi-core processors which can be configured in a timing-predictable way to avoid or bound inter-core interferences like Infineon AURIX TC27x [START_REF]aiT WCET Analyzer Website[END_REF].

Hybrid WCET Analysis

Hybrid WCET analysis tools combine static context-sensitive path analysis with real-time instruction-level tracing to provide worst-case execution time estimates. By its nature, an analysis using measurements to derive timing information is aware of timing interference due to concurrent execution and multi-core resource conflicts, because the effects of asynchronous events (e.g. activity of other running cores or DRAM refreshes) are directly visible in the measurements. An example tool is the hybrid WCET Analyzer TimeWeaver [START_REF] Kästner | TimeWeaver: A Tool for Hybrid Worst-Case Execution Time Analysis[END_REF][START_REF]Timeweaver website[END_REF], which builds on non-intrusive instruction-level tracing: the probe effect is avoided since no code instrumentation is needed. The computed estimates are safe upper bounds with respect to the given input traces, i.e., TimeWeaver derives an overall upper timing bound from the execution time observed in the given traces. Thus, the coverage of the input traces on the analyzed code is an important metric that influences the quality of the computed WCET estimates.

The trace information needed for running TimeWeaver is provided by embedded trace units of modern processors, like NEXUS IEEE-ISTO 5001, Infineon TriCore MCDS, or ARM CoreSight. They allow the fine-grained observation of a program execution on single-and multi-core systems.

The main inputs for TimeWeaver are the fully linked executable(s), timed traces and the location of the analyzed code in the memory (entry point, which usually is the name of a task or function). The analysis proceeds in several stages: decoding, loop/value analysis, trace analysis, and path analysis, most of which are shared with aiT [START_REF] Souyris | Computing the worst case execution time of an avionics program by abstract interpretation[END_REF]. The main difference is that micro-architectural analysis is replaced by the trace analysis stage:

Trace analysis: The given traces are analyzed such that each trace event is mapped to a program point in the controlflow graph and the trace points and segments are defined.

In case a preemptive system has been traced, interrupts are detected and reported. The extracted timing information, i.e., the clock cycles which have been elapsed between two consecutive trace points are annotated to the CFG in a context-sensitive manner [START_REF] Kästner | TimeWeaver: A Tool for Hybrid Worst-Case Execution Time Analysis[END_REF].

Run-Time Errors and Data Races

In this section we focus on source-level runtime errors due to undefined or unspecified behaviors of the programming language used. Examples are faulty pointer manipulations, numerical errors such as arithmetic overflows and division by zero, data races, and synchronization errors in concurrent software. Such errors can cause software crashes, invalidate separation mechanisms in mixed-criticality software, and are a frequent cause of errors in concurrent and multi-core applications. At the same time, these defects also constitute security vulnerabilities, and have been at the root of a multitude of cybersecurity attacks, in particular buffer overflows, dangling pointers, or race conditions [START_REF] Kästner | Detecting Safetyand Security-Relevant Programming Defects by Sound Static Analysis[END_REF]. Runtime errors are one important cause of software-induced memory corruption in safety-critical systems. The other two main causes are stack overflows, and miscompilation, where the compiler silently generating erroneous code from a correct input program. As described above, with abstract interpretation, the absence of runtime errors and stack overflows can be proven; when using a formally proven compiler like CompCert [START_REF] Kästner | Closing the gap -the formally verified optimizing compiler CompCert[END_REF][START_REF] Kästner | CompCert: Practical Experience on Integrating and Qualifying a Formally Verified Optimizing Compiler[END_REF] no miscompilation is possible, hence all main sources of software-induced memory corruption can be covered.

In the following we will give a brief overview of the Astrée analyzer as an example of sound static runtime error analysis tools [START_REF] Kästner | Finding All Potential Runtime Errors and Data Races in Automotive Software[END_REF] [START_REF] Miné | Taking Static Analysis to the Next Level: Proving the Absence of Run-Time Errors and Data Races with Astrée[END_REF]. To achieve high precision Astrée provides a variety of abstract domains covering, e.g. , intervals, octagons, digital filters, finite state machines, and interpolations. The memory domain empowers Astrée to exactly analyze pointer arithmetic and union manipulations and to perform a type-safe analysis of absolute memory addresses. Floating-point computations are precisely modeled while keeping track of possible rounding errors. Astrée also implements a low-level concurrent semantics [START_REF] Miné | Static analysis of run-time errors in embedded realtime parallel C programs[END_REF] which provides a scalable sound abstraction covering all possible thread interleavings. The interleaving semantics enables Astrée, in addition to the classes of runtime errors found in sequential programs, to report data races, and lock/unlock problems, i.e., inconsistent synchronization. The set of shared variables does not need to be specified by the user: Astrée assumes that every global variable can be shared, and discovers which ones are effectively shared, and on which ones there is a data race. Since Astrée is aware of all locks held for every program point in each concurrent thread, Astrée can also report all potential deadlocks. The abstract domains are parameterized, which enables users to fine-tune the precision of the analyzer to the software under analysis to minimize the number of false alarms.

In its data and control flow analysis module, Astrée tracks accesses to global, static, and local variables in case those accesses are made outside of the frame in which the local variables are defined (e.g., because their address is passed into a called function). The soundness of the analysis ensures that all potential targets of data and function pointers are taken into account. Function pointer targets are automatically resolved and can be exported in AIS format to support binary-level static analyzers. Astrée's data and control flow reports show the number of read and write accesses for every global, static, and out-offrame local variable, lists the location of each access and shows the function from which the access is made. All variables are classified as being thread-local, effectively shared between different threads, or subject to a data race. Astrée also suports data and control coupling analysis [START_REF] Kästner | Static Data and Control Coupling Analysis[END_REF], and can check compliance to commonly used coding guidelines such as MISRA C/C++, CWE, SEI CERT C/C++, Adaptive Autosar C++, etc. Furthermore, Astrée includes a program slicer, and a user-configurable taint analysis [START_REF] Kästner | High-Precision Sound Analysis to Find Safety and Cybersecurity Defects[END_REF].

Practical experience on avionics and automotive industry applications are given in [START_REF] Kästner | Finding All Potential Runtime Errors and Data Races in Automotive Software[END_REF][36] [START_REF] Kästner | Analyze This! Sound Static Analysis for Integration Verification of Large-Scale Automotive Software[END_REF]. They show that industrysized programs of millions of lines of code can be analyzed in acceptable time with high precision for runtime errors and data races.

Coverage of Verification Objectives

In this section we give an overview of the verification objectives of DO-178C to which static analysis methods can be applied. The relevant verification objectives are summarized in Annex-A of [41]. We will explicitly list the sections of the DO-178C and the DO-333 that address verification objectives to which sound static analysis for WCET (worst-case execution time), WCSU (worst-case stack usage), and RTE (runtime errors), as well as simple unsound code guideline checking (CG) can contribute. The section names of the DO-333 match the corresponding sections in the DO-178C, e.g. Sec. FM.6.3.1.c of DO-333 corresponds to Sec. 6.3.1.c of DO-178C, so in the following we will just use the numbering from [41] for simplicity.

In general, worst-case execution time analysis, worst-case stack usage analysis and runtime error analysis contribute to all objectives related to the target environment. Stack usage, response times and execution times are determined by the target computer. They can cause violations of high-level requirements, violations of low-level requirements, incompatibility of the software architecture with the target computer, and they can affect the accuracy and consistency of the source code. Sound static source code analysis enables sound data and control flow analysis which is required to demonstrate consistency between software architecture level and source code level. Detecting runtime errors is required to deal with robustness issues like out-of-range loop values and arithmetic overflows, or to verify the software integration. The latter implies, e.g., detecting incorrect initialization of variables, parameter passing errors, and data corruption.

The sections Sec. FM.6.3.1.c, FM.6.3.2.c, and FM.6.3.3.c address the compatibility with the target computer, hence, sound static analyses for WCET, WCSU, and RTE are relevant for all of them. The timing aspect is emphasized as response times and is explicitly listed as an example in Sec. FM. [START_REF] Barr | Camry software Analysis by Michael Barr[END_REF] case execution time or stack consumption of the software under certification. The possibility to deeply investigate the behavior of the analyzed software on the assembly level allows to derive information about timing contribution of specific parts of the software but also to trace back contents of memory cells and/or register values to the corresponding source code. Hence sound static binary code analysis as needed for WCET and WCSU also contributes to the paragraphs a till d in Sec. FM.6.7.

As specified in Sec. FM.6.7.f, relevant properties can also be verified on source code level if property preservation between source and object code level is ensured. For the language C, this can be achieved by using the formally verified compiler CompCert [START_REF] Kästner | Closing the gap -the formally verified optimizing compiler CompCert[END_REF]. The code it produces is proven to behave exactly as specified by the semantics of the source C program. Leveraging this, sound static RTE analysis is relevant for all points in Sec. FM.6.7 and also contributes to Sec. FM.6.6.a: program slicing and taint analysis, e.g. , as available in Astrée, support identifying program parts contributing to run-time errors, and program parts affected by data corruption, respectively, hence possibly pinpointing flaws in the Data Item File. Furthermore a type-safe analysis of absolute addresses at the source code level as available in Astrée can detect incorrect hardware addresses, and also reports memory overlaps. The value analysis component of sound binary-level analyzers for WCET and WCSU supports proving that memory accesses are made to the expected memory regions at the Executable Object Level. These analyses contribute to Sec. FM.6.3.5.a which deal with review and analyses of the output of the integration process.

Code guideline checkers, either as standalone tools, or included in sound RTE analyzers such as Astrée typically also compute code metrics, and provide checks to demonstrate conformance to thresholds defined. These capabilities support requirements of the Software Design Standards (e.g., recursion, dynamic objects, call nesting levels) and of the Software Code Standards (e.g., style rules, expression complexity). They also support traceability requirements by appropriate coding rule checks. In summary, they contribute to various verification objectives, in particular the objectives Sec. FM.

Tool Qualification

Whenever the output of a tool is either part of a safety-critical system to be certified or the tool output is used to eliminate or reduce any development or verification effort for such a system, that tool needs to qualified. DO-178C regulates when a tool qualification is to be applied and DO-330 [START_REF]Software Tool Qualification Considerations[END_REF] gives guidance on the tool qualification requirements.

Relevant Tool Qualification Levels (TQL)

First, the necessary qualification activities and results have to be identified. For this, DO-330 defines the so-called tool qualification level (TQL). There are five different levels, from the most critical level TQL-1 down to TQL-5.

The TQL is determined by the potential tool impact and the software level. TQL-4 TQL-5 TQL-5 To summarize, the tool qualification levels relevant for static analyzers are TQL-4 and TQL-5. TQL-4 applies when the software under analysis is Level A/B and the tool categorized as criteria 2. In all other cases, TQL-5 applies. In the following, we summarize the qualification material that is required for a TQL-4 qualification, and outline a well-proven example on how this can be supported.

Tool Qualification Requirements

The tables T-0 to T-10 in DO-330 define requirements (called objectives) to the tool qualification. Each table addresses a different process associated with the life cycle of the tool under qualification in order to cover the relevant aspects of the affected processes.

Summarizing the objectives in these tables, the qualification data to be provided for a TQL-4 verification tool boils down to the following. First, tool (operational) requirements have to be specified, i.e. , the intended tool behavior must be defined in an explicit and detailed manner. Second, test cases have to be created which cover all those functional requirements. This includes providing descriptions of test case objectives, execution procedures, expected results, and records of their execution. Unique identifiers for requirements and test cases allow to establish trace data between those data elements which in the end allows to claim coverage of all requirements by successfully passed test case executions. For the static analyzers described in Sec. 3 these requirements are fully covered by socalled Qualification Support Kits (QSKs).

In addition to the tool behavior, the qualification material needs to address certain aspects of the tool development processes. The Tool Qualification Plan (TQP) gives an overview to the tool qualification as a whole. The Tool Development Plan (TDP) includes the objectives, standards, and tool life cycle(s) to be used in the tool development processes. The Tool Verification Plan (TVP) is a description of the activities to satisfy the tool verification process objectives. The Tool Configuration Management Plan (TCMP) establishes the methods to be used to satisfy the objectives of the TCM process throughout the tool life cycle. The Tool Quality Assurance Plan (TQP) establishes the methods to be used to satisfy the objectives of the tool quality assurance process. The execution of all activities defined in these plans needs to produce evidence records that are archived and part of the qualification data. AbsInt provides these evidences about the applied tool life cycle activities as part of the QSKs.

Typically, static analyzers are categorized as so-called Commercial Off-The-Shelf (COTS) tools, basically meaning that the tool developer is different from the tool user. To qualify COTS tools, the tool developer provides the basis for the required qualification material from a "tool developers" perspective. The tool user then needs to either adapt the material or to describe how its tool use maps to the data provided by the developer. For example: the tool user might needs to define how the tool is used and which functionality (from the provided operational requirements) is used.

To provide high confidence in the correct functioning of a tool it is necessary to demonstrate that the tool works correctly in the operational context of its users. This is a common requirement of most current safety standards. The correct functioning of a tool might be affected by the OS version, system libraries installed, software patch levels, etc. For the tools listed in Sec. 3 there is dedicated support for tool users to automatically execute the QSK test cases and automatically create all data required for the certification package.

Conclusion

Static analysis has evolved to be a standard method in the software development and verification process. It can be applied to various verification activities required for DO-178C certification, in particular by performing code guideline checking, data and control coupling analysis, interference analysis, worst-case stack and execution time analysis, and runtime error analysis. In this article we precisely identified the verification requirements and objectives that can be covered by static analysis and its formal method, abstract interpretation. For each application of static analysis mentioned above we summarized the underlying analysis concepts and illustrated them with practical examples. We also summarized the required tool qualification activities, and illustrated them with a well-proven example approach to tool qualification.

  3. (goal: preventing undefined or critical unspecified behavior) and Directive 4.1 (goal: minimization of run-time failures)). Rule 1.3 and Directive 4.1 are examples for semantical guidance.

Table 1 :

 1 .3.1.c and Sec. FM.6.3.2.c. Sound analyzers for WCET, WCSU and RTE can report unreached code and dead code, thus also contributing to Sec. FM.6.3.3.a, Sec. FM.6.3.4.a, and Sec. FM.6.3.4.e. Compliance to low-level requirements (Sec. FM.6.3.4.a) also necessitates the absence of programming defects as reported by sound RTE analysis. The data and control flow analysis provided by sound RTE analysis relates to Sec. FM.6.3.3.b and FM.6.3.4.b. Subsequently, Sec. FM.6.3.4.f explicitly lists determining worst-case execution time, stack usage, and absence of runtime errors as verification objectives.Sec. FM.6.7 addresses the formal analysis of the executable object code. Sound analysis of WCET and WCSU both contribute to Sec. FM.6.7.e by computing safe bounds to the worst-Coverage

	Obj. Ref.	WCET WCSU CG RTE
	Table FM.A-3
	3 FM.6.3.d
	FM.6.3.1.c
	Table FM.A-4
	3 FM.6.3.d
	FM.6.3.2.c
	5 FM.6.3.f
	FM.6.3.2.e
	8 FM.6.3.3.a	*
	9 FM.6.3.c	*	*
	FM.6.3.3.b
	10 FM.6.3.d
	FM.6.3.3.c
	11 FM.6.3.e	*	*
	FM.6.3.3.d
	12 FM.6.3.f	*	*
	FM.6.3.3.e
	13 FM.6.3.3.f
	Table FM.A-5
	1 FM.6.3.a
	FM.6.3.4.a
	2 FM.6.3.a
	FM.6.3.4.b
	3 FM.6.3.e
	FM.6.3.4.c
	4 FM.6.3.f
	FM.6.3.4.d
	5 FM.6.3
	FM.6.3.4.e
	6 FM.6.3.b
	FM.6.3.c
	FM.6.3.4.f
	7 6.3.5.a
	Table FM.A-6
	1 FM.6.7.a		**
	FM.6.7.c
	2 FM.6.7.b		**
	FM.6.7.c
	3 FM.6.7.d		**
	FM.6.7.c
	4 FM.6.7.b		**
	FM.6.7.c
	5 6.4.e		**
	FM.6.7.e
	* Leveraging the built-in value analysis
	** Using CompCert to ensure semantic preservation

of DO-178C verification objectives by sound static WCET analysis (WCET), sound static stack usage analysis (WCSU), static code guideline checking (CG) and sound static runtime error analysis (RTE).

  6.3.3.d, Sec. FM.6.3.3.e, Sec. FM.6.3.4.c, Sec. FM.6.3.4.d, and Sec. FM.6.3.4.e, in general supporting to check the verifiability of software design and implementation.

  There are three tool impact categories where Criteria 1 denotes the highest impact and Criteria 3 the lowest. Criteria 1 does not apply to static verification tools since it is associated with tools whose output is part of the airborne software. Analysis and verification tools are subject to Criteria 2/3. The difference between the latter two categories is whether the output of the tool is used to justify the elimination or reduction of other verification or development activities or not. The following table illustrates how the TQLs are assigned based on Criteria and Software Level.


Uriel Rigoberto Quispe Quezada

AGRIBUSINESS AND ITS PRODUCTIVE POTENTIAL TOWARDS THE BICENTENNIAL

Keywords: Agronegocios, potencialidades, cultivos, productivas Agribusiness, potential, crops, productive. ARTÍCULO

RESUMEN

El aporte de los agronegocios de cara al bicentenario en el Perú, está siendo representada cada vez más con mayor prestancia en los mercados internacionales y la comunidad científica, por las bondades que ofrece a través de los cultivos con altísimo valor nutricional y alimentario, rescatada en algunos casos, por su apreciable valor genético de los recursos que se encuentran en los bancos de germoplasma, en cuyas especies es vasta y el número de accesiones y líneas cada vez cobra importancia, en los usos que se les da, que contribuye opciones para su industrialización y recibida por los consumidores que aprecian su riqueza nutricional y colma expectativas. El objetivo de la investigación aborda conocer las múltiples potencialidades de cultivos de exportación, promovidos a través de los agronegocios de cara al bicentenario en el país. En cuanto a la metodología aborda tomando en referencia niveles de análisis de cómo se ha venido comportando los cultivos bandera en los mercados internacionales apoyadas con la utilización y sistematización de fuentes variadas de información, en cuya incisión investigativa aborda con capacidad crítica. Las conclusiones que se presenta a lo largo de décadas, los cultivos de bandera están teniendo su participación, un lugar expectante en los ambientes comerciales, resaltando sus potencialidades al presentar riqueza nutraceútica, las cuales son utilizadas como fuente de alimento para el consumo humano y a la vez emplaza la participación de éstas en un mundo cada vez más competitivo.

INTRODUCCIÓN

Los agronegocios en el Perú, incluye actividades productivas, industriales, exportadoras y comerciales [START_REF] García | Cadenas agroalimentarias: un instrumento para fortalecer la institucionalidad del sector agrícola y rural[END_REF]. Cada sector se interrelaciona a través de productos que conforman la oferta agroexportable a lo largo de cadenas agroalimentarios [START_REF] García | Cadenas agroalimentarias: un instrumento para fortalecer la institucionalidad del sector agrícola y rural[END_REF]. Agronegocios es un sistema que agrupa varias fases que van desde la producción del campo, transformación, almacenamiento, distribución y comercialización [START_REF] Maiz | [END_REF]. Para [START_REF] Castro | El Sistema De Agronegocios En El Perú: De La Agricultura Familiar Al Negocio Agroalimentario[END_REF], el sistema de los agronegocios peruano incluye desde las actividades productivas, industriales, exportadoras y comerciales. Estas se interrelacionan a través de productos que conforman la oferta agroexportable a lo largo de cadenas agroalimentarias [START_REF] Castro | El Sistema De Agronegocios En El Perú: De La Agricultura Familiar Al Negocio Agroalimentario[END_REF] Es innegable de la capacidad que posee el país, en poseer una gran variedad de cultivos en calidad de exportación, recursos genéticos de alto valor, biodiversidad de especies vegetales invaluables, cada uno de ellos desde su espacio, vienen contribuyendo al desarrollo de país, colocándolo un lugar cada vez más expectante en el mercado internacional. Recursos genéticos con incalculable valor, que muchos de los países ya desearían tener, poniendo al Perú en la cima de una riqueza tradicional, desde lo prehispánico y utilizadas para muchos fines de investigación, en la búsqueda constante de identificar potencialidades para usos comerciales. Utilizadas por la comunidad científica, tomando prestancia en las diversas investigaciones y en cuyos resultados viene generando aportes en solucionar problemáticas y contribuyendo a generar valor agregado.

La presencia en los países de desarrollo se ve con mayor prestancia cultivos altoandinos de gran riqueza tradicional y nutracéutica, actualmente bien valorada por los consumidores de estos países al tener como alimento base en su dieta alimenticia, por la gran problemática en su población de sobrepeso, exceso de ingesta de carbohidratos que ocasiona problemas cardiacos y entre otros., cuando en el Perú estos alimentos se ha venido consumiendo a lo largo de las décadas en su dieta familiar, desde lo prehispánico hasta la actualidad.

En la actualidad el país tiene la oportunidad de liderar, en particular, el sector agroexportador mundial, debiendo enfrentar el reto de potenciar su producción en cantidad y calidad, así como la generación de valor agregado [START_REF] Castro | El Sistema De Agronegocios En El Perú: De La Agricultura Familiar Al Negocio Agroalimentario[END_REF]. En general, la mayor parte de estudios buscan identificar la influencia de diferentes factores como la competitividad [START_REF] Castellanos | La geopolítica de los agronegocios: Competitividad del mercado agroalimentario en el nuevo orden mundial[END_REF], la asociatividad [START_REF] Cedeño | De la agricultura arcaica al agronegocio y los modelos asociativos. Su impacto social[END_REF] y la sostenibilidad [START_REF] Junca | Sostenibilidad de modos ancestrales de producción agrícola en el Perú: ¿conservar o sustituir? Mundo agrario[END_REF], pero de manera individual, sin identificar sinergias o inconsistencias en las estrategias comerciales [START_REF] Castro | El Sistema De Agronegocios En El Perú: De La Agricultura Familiar Al Negocio Agroalimentario[END_REF], y las oportunidades (Geldes & Felzensztein, 2013).

La promoción de estos cultivos en los ambientes internacionales, propició mayores compras y precios competitivos de productos con alto valor nutritivo, en muchos de los casos consolidándose su presencia en los mercados con calidad de exportación, Las superficies de áreas cosechadas durante el periodo 2004 al 2018 crecieron en un 258%, representando 57,441 ha y 205,600 ha respectivamente. (PROMPERU, 2019). PURIQ Vol. 3, Núm. 3. 2021|ISSN 2664-4029|E-ISSN 2707-3602 Universidad Nacional Autónoma de Huanta

MÉTODO

Esta investigación es considerada descriptiva bajo el enfoque cualitativo, tomando en consideración el uso y sistematización de fuentes variadas de información procedente de artículos científicos de investigación, revistas especializadas, libros, boletines informativos y medios electrónicos, las cuales son analizadas de manera crítica, abordando la problemática de los agronegocios frente al bicentenario.

PERSPECTIVAS Y POTENCIALIDADES DE GRANOS ANDINOS

El caso de la quinua, producto emblemático del país, que en los últimos años vienen consolidándose como uno de los alimentos con múltiples bondades nutricionales. Toma relevancia mundial después de la promoción que se le ha dado en el año 2017, declarándose año internacional de la quinua, donde los niveles de importación han sido significativos en relación al promedio normal de estos productos. Alcanzando precios muy competitivos, en cuya alza estuvo expectante logrando cubrir los costos productivos por parte de los agricultores. Posteriormente, a la falta de promocionar adecuadamente por parte del gobierno, y ejercer una política de conservar el recurso genético, hoy en día muchos de los países en el mundo vienen sembrando estos productos y logrando altos niveles de producción en comparación al Perú.

La existencia de pérdida de material genético le está costando al país, perdiendo niveles de posicionamiento en estos rubros, a la falta de una política de nivel de seguridad y proteccionismo nacional, que beneficiaría a muchas poblaciones altoandinas que ven como su fuente de recurso económico que al menos cubra sus expectativas y reditúe ciertos niveles de utilidad.

Citar, el caso de la quinua un grano con alto valor proteico, que aporta proteínas, ácidos grasos insaturados y minerales; kiwicha conocida también como amaranto, alimento de excelencia para los incas, debido a sus propiedades nutritivas y medicinales, contiene un alto valor en proteínas y minerales como calcio, fosforo, potasio, zinc y otros; Cañihua cultivo que prospera en el altiplano peruano resistiendo a las heladas y sequías (UnahALDIA, 2020a).

Destacando sus propiedades nutricionales un alto contenido proteico y un balance de aminoácidos como lisina, isoleucina y triptófano, posee además vitaminas E y complejo B; Sacha Inchi, planta oleaginosa de la Amazonía peruana, cuyas semillas contienen una de las más importantes fuentes de omega 3, 6 y 9 del mundo; Camu Camu pequeño fruto ovalado de superficie lisa, color rojo y centro ácido, contiene un alto índice de vitamina C; Lúcuma sus beneficios nutricionales destacan que aporta vitaminas y minerales; Aguaymanto poderoso antioxidante con altos contenidos de vitaminas A, B y C., [START_REF] Noticias | agencia peruana de[END_REF] y entre otros alimentos de importancia económica (UnahALDIA, 2020b). Otros de los productos que tiene mayor prestancia en el mundo comercial es el amaranto, este cultivo antes de la presencia del cultivo de la quinua ha tenido su posicionamiento comercial en el mundo, e incluso por sus bondades nutricionales ha sido galardonada por organismos internacionales.

Al igual que estos también se traduce hoy con mayor prestancia el cultivo de la cañihua, utilizándose en una diversidad de usos, desde los ya conocidos y ampliamente En varias décadas el Perú sigue siendo uno de los países con altos niveles de producción y venta manteniendo volúmenes de producción e importación de estos productos por parte de empresas en el exterior. Mas allá de los hábitos de consumo, éstas poseen un mercado potencial claramente definido y a lo largo de la franja costera aún se está en plenas campañas de producción, industrialización y exportación. Sumadas a éstos cultivos, la páprika que es uno de los ajíes de mayor salida y alta potencialidad que también en el país se viene promoviendo activamente en su producción e industrialización, e incluso muchas de las tierras agrícolas con instalaciones de cultivos permanentes el caso de la alfalfa, y otras especies en las regiones ganaderas han venido cambiando el giro de producción, tomando prestancia las instalaciones de estos cultivos que cada vez más demandan mayores producciones para su venta externa.

La alcachofa, sigue siendo un cultivo de mayor prestancia, a lo largo de muchos años, se han presentado muchas alternativas a fin de lograr altísimos niveles de producción, con la dotación de cultivares a nivel de precocidad, resistencia y capacidad de producción. Este también interviene en los procesos de industrialización que se da por diversas presentaciones, muy reconocido en la comunidad exterior y al ser cultivos estacionales le permite cubrir adecuadamente en los meses de estiaje a nivel internacional. En muchos de los sectores del Perú, se presenta este tipo de cultivares, no obstante, el grueso de la población del país aún no conoce sobre las potencialidades de este cultivo, PURIQ Vol. 3, Núm. 3. 2021|ISSN 2664-4029|E-ISSN 2707-3602 Universidad Nacional Autónoma de Huanta ni más tener los hábitos de consumo que le harían tener mayores probabilidades de que su participación sea de manera sostenible.

Al igual que éstas, muchos de las especies vegetales están siendo cada vez más demandada, por los consumidores y viene sentando alternativas en su industrialización, como son las papas andinas, estos productos actualmente viene siendo insumos en el procesamiento de papas saladas, presentes en los ambientes gastronómicos, comerciales, la característica es que presentan diversas tonalidades y es producto de una variada nivel genético de estas especies, muchos de ellas agrupadas en los bancos de germoplasma, donde el nivel de acciones son debidamente conservadas y sembradas a fin de reponer su potencialidad genético.

La contribución hacia el bicentenario, se mira expectante, en continuar apostando por las especies naturales, caso de camu camu, cultivo de calidad de exportación con múltiples oportunidades en su industrialización, especies de vegetales que son consideradas medicinales en caso de guion, uña de gato, mashua, y otros.

SUPERFRUTAS PERUANAS QUE CONQUISTAN MERCADOS

La existe de frutas de calidad de exportación aún mantienen niveles expectantes de comercio, el caso del mango peruano, sembrando a lo largo de franja costera, hasta llegar a los climas cálidos para su producción y posterior exportación, muy demandado en los mercados asiáticos, quienes valoran por sus niveles de consistencia, sabor, aroma, cuerpo, y carnosidad, El caso de la uva de mesa, las especies de redglobe, también es otro de los productos que cosechan muchas de las empresas de agroexportación en la franja costera, a través de una buena política de manejo controlado de plagas y enfermedades, obtención de certificaciones de sus instalaciones, campos de cultivo aseguran que la producción sea de altísima calidad, y posteriormente representa el insumo principal para su procesamiento e industrialización, guardando niveles de control permanente a nivel de certificaciones de sus instalaciones y campos de cultivo, que le hacen ser fuente de insumos para la obtención de diversos productos por las empresas, A estos se suma otro de los productos vadera el caso de la lúcuma, fruto proveniente de la familia de las sapotáceas originario de los valles interandinos en el Perú, fruta muy utilizada en la elaboración de postres y helados, así como insumo principal para usos industriales en la obtención de deshidratados y entre otros.

REDUCCIÓN DE BRECHAS ENTRE PRODUCTOS TRADICIONALES Y NO TRADICIONALES

En el Perú, el sector agroexportador se ha constituido, en los últimos veinte años, en la segunda actividad económica con mayor rentabilidad después de la minería, multiplicándose casi ocho veces sus ganancias a nivel de exportaciones de productos no tradicionales [START_REF] Castro | El Sistema De Agronegocios En El Perú: De La Agricultura Familiar Al Negocio Agroalimentario[END_REF]. Hace varias décadas el Perú en inminentemente exportador de productos primarios, llegando hasta un nivel del 70% promedio, no obstante, estos altos porcentajes se han visto reduciendo por la presencia de mayor incremento en las exportaciones no tradicionales, PROMPERU, (2019). En el año 2000 llegaban a 95 mercados con un valor cercano a los US$400 millones; en el 2019 se PURIQ Vol. 3, Núm. 3. 2021|ISSN 2664-4029|E-ISSN 2707-3602 Universidad Nacional Autónoma de Huanta incrementaron a más de US$6,292 millones cubriendo 145 mercados internacionales (Economía, 2019).

Este último en base a un crecimiento sostenido por la presencia e importancia de que el país viene apostando por la agroexportación, teniendo una vasta condición geográficas que le permiten poder cultivar tierras de cultivos de exportación y condiciones de infraestructura de riego, que asegure dotar del recurso hídrico indispensable para el desarrollo de las plantas y asegure las cosechas bajo los estándares de calidad y normas técnicas exigentes en los mercados internacionales. De los más de 5 millones de hectáreas que constituyen la superficie agrícola del Perú, alrededor de 100,000 corresponden a una agricultura moderna. Estas son responsables de los casi US$ 3,333 millones de exportación no tradicional y parte de los US$ 1,168 millones de exportación tradicional, excepto el café que se cultiva en las zonas medias altas de nuestra Amazonia (CONEXIONESAN, 2011).

A partir de los acuerdos comerciales en el 2000 y la expansión de la frontera agrícola con los grandes proyectos de irrigación en la costa, las exportaciones agrarias han venido creciendo exponencialmente (Gestión, 2018), posicionado al Perú entre los 20 principales proveedores de alimentos en el mundo de productos como la quinua, espárrago, café, mango, maca, aceituna, uva, palta, alcachofa, pimientos secos, frijol, mandarina, jengibre, habas, cebollas, arveja fresca y recientemente arándanos, cultivos que tienen además un enorme valor en términos de su aporte a la seguridad alimentaria mundial (Gestión, 2018).

No solamente la importancia de apostar por la agroexportación a lo largo de franja costera donde se encuentran la mayor proporción de áreas de cultivos potenciales, sino que además estas actividades se orientan en la sierra y en el oriente del Perú, cuya contribución si bien es cierto es limitada pero no menos importante a escala nacional, de ahí su importancia de orientar todos los esfuerzos necesarios en promocionar desde las instituciones públicos y privadas hacia la internacionalización, con una serie de mecanismos que beneficie a empresas de gran escala, mediana y pequeños emprendimientos, en su proceso de colocación de sus productos en el mundo.

EXPECTATIVAS COMERCIALES EN EL MUNDO

Las experiencias exitosas de empresas que han logrado ingresar a mercados internacionales, le ha abierto camino a nuevos escenarios y a la vez concretizar transacciones comerciales con clientes muy exigentes y competitivos, con la oferta de una cartera de portafolio diverso de productos de altísima calidad e innovadoras. Este esfuerzo ha requerido tiempo e inversión, con el apoyo en algunos casos de Instituciones nacionales en materia de comercio exterior, dotándolos en la capacidad organizativa y de presentación en las distintas ferias internacionales, ruedas de negocio, entrevistas con potenciales clientes, lográndose resultados positivos en factor de este sector.

Durante el año 2019, el Departamento de Agronegocios de PROMPERÚ estuvo presente en 14 ferias internacionales, 3 misiones comerciales itinerantes, 1 misión comercial local y 8 ruedas de negocios, generando más de US$ 1,160 millones en oportunidades comerciales logradas a través de 10,290 citas comerciales gestionadas para 430 empresas peruanas expositoras. (PROMPERU, 2019) La apertura de nuevos mercados por parte del gobierno, constituye una oportunidad de negocios, en el sector empresarial, quienes pueden acogerse a una serie de beneficios que contemplan en dichos acuerdos. Es evidente sobre la participación del gobierno en ser un ente promotor de la industria nacional. El crecimiento de las exportaciones y diversificación de mercados de productos frescos se dio gracias a la apertura de mercados que pudieron ser concretadas durante periodo el periodo 2018 y 2019.

En el 2018 se abrió el mercado de los cítricos hacia destinos como República Dominicana, Malasia y Japón; siendo la variedad beneficiada la mandarina satsuma para estos dos últimos destinos. Otros mercados que se lograron abrir gracias a mejoramientos de acceso fueron Malasia e Indonesia como sucedió para la uva fresca. Durante el año 2019, se concretaron accesos de mercado importantes como la palta hass fresca para Tailandia y Corea del Sur. Para el 2020 se proyecta que se pueda concretar nuevas aperturas mediante acuerdos sanitarios con países como Filipinas, Japón, India, Taiwán, China, Malasia, Colombia y Corea del Sur (PROMPERU, 2019)

PANDEMIA Y SUS EFECTOS EN LOS AGRONEGOCIOS

Uno de los escenarios que se presentó en la última década, según Pulcha-Ugarte et al., (2020) a finales del 2019 en Wuhan (China), se originó a una pandemia que alcanzaría una escala global, comparándose con otras tan letales que se ha presentado en la historia de la humanidad. Esta es una neumonía viral atípica y altamente contagiosa, covid-19, cuya causa se le atribuye a un coronavirus de transmisión zoonótica al que se denominó SARS-CoV-2 (Pulcha-Ugarte et al., 2020b) (Quispe Quezada, 2020). Esta crisis sanitaria trajo severas consecuencias en los sectores comerciales y los agronegocios en el Perú no estuvo exento de esta problemática, afectando actividades comerciales en algunos rubros.

Perú fue el primer país de la región en decretar una cuarentena general obligatoria, el 15 de marzo. El presidente Martín Vizcarra también ordenó el cierre de sus fronteras durante un lapso de 15 días [START_REF] Mundo | Coronavirus | Cómo hace frente al covid-19 cada país de América Latina[END_REF]. Después de la declaración de emergencia nacional, el sector se vio afectada, por la paralización que duró varios meses, por la incidencia de la pandemia, tal como lo evidenciaría posteriormente reportes del ejecutivo a mediados de abril del 2020, las pérdidas estimadas ascendían hasta S/. 1611 millones de soles en el sector agropecuario, afectando a pequeños agricultores, quienes no suelen tener acceso al sistema bancario, ni son beneficiarios de programas sociales del Estado.

El sector agroexportador registró caídas en sus niveles de exportación por la presencia del coronavirus a nivel mundial, que obligó a que los países implementen cuarentenas obligatorias a su población como medidas de prevención para afrontar la diseminación del virus y consecuentemente el cierre del comercio internacional entre países, decisiones drásticas que pusieron en serias dificultades al Perú para colocar sus productos al mercado, en muchos de los casos productos que se encontraban en los lugares de destino, no pudiendo ingresar por las medidas de confinamiento aplicadas (Quispe Quezada, 2020).

El cierre de las fronteras internacionales impuestas en los diversos países en el mundo, presentaron restricciones comerciales en las empresas a la hora de realizar PURIQ 384 PURIQ Vol. 3, Núm. 3. 2021|ISSN 2664-4029|E-ISSN 2707-3602 Universidad Nacional Autónoma de Huanta contratos con el flete de las embarcaciones de carga, así como la exigencia en cumplir con la calidad de cartera como es sabido que se da por medio de las liquidaciones de destino. La entrada a la etapa de confinamiento en tiempos distintos, ha generado un desfase entre el suministro y la demanda entre los países que cerraron las fronteras para frenar la propagación del virus ejemplos como: China ingresó en cuarentena el 23 de febrero, seguida de Corea del Sur, Estados Unidos a finales de marzo, la Unión Europea que agrupa a varios países entró a mediados de marzo y el Perú hizo lo propio el 15 de marzo.

(UnahALDIA, 2020a)

En el segundo semestre del año 2020, aun reflejaba problemas teniendo en cuenta contextos habituales en la que el inicio de las campañas agrícola en la siembre de cultivos iniciaba los primeros días del mes de agosto, no obstante, las paralizaciones afectarían la cadena de comercialización y en cuyas respuestas hacia los agricultores llegaría tardíamente. Frente a este escenario posteriormente por disposiciones del ejecutivo ponía a disponibilidad el Programa de Garantía para el Financiamiento Agrario Empresarial (FAE-Agro) (AS. COM, 2020), que aseguraba un desembolso de aproximadamente S/2,000 millones de soles para el otorgamiento de garantías a pequeños agricultores.

Los impactos que se generó por la pandemia evidenciarían que los sectores de una agricultura a menor escala no fueron tan severos tanto en sus niveles de producción al igual que los precios. no obstante, en los sectores mayores afectaron por los bloqueos internacionales al cerrar sus principales puertos de destino, las cuales fueron aperturando a medida que esta pandemia estuvieron bajo control pero que, sin embargo, en forma irregular, esto consecuentemente afectaría el nivel de las agroexportaciones peruanas a los mercados internacionales.

Los principales mercados a las que se destina son a la China, Estados Unidos, la Unión Europea, quienes son considerados socios estratégicos del Perú y permiten dinamizar las exportaciones no tradicionales. Alimentos, que cada vez más son demandados en los mercados internacionales con buenos precios, aun durante la crisis de la pandemia del covid-19 (¡Qué!, 2020), que ha generado un cambio de actitud en los consumidores en preferir alimentos naturales y saludables (UnahALDIA, 2020a).

En base a las conclusiones de investigadores quienes realizaron un análisis exhaustivo manifiestan que la pandemia no ha tenido afectación significativa en el sector agroexportador, en donde La tendencia de crecimiento, a pesar de que por mes no ha tenido aumento sino disminución, a nivel de acumulado trimestral o cuatrimestralmente hablando ha representado un porcentaje de crecimiento del sector agroexportador de manera positiva, manteniendo a sus principales destinos y productos, y hasta aumentando las exportaciones del mismo (Velarde Flores, 2020), (Apolino, A; Llontop, M; Acuña, M; Paredes, 2020)

AGRADECIMIENTOS

A la Universidad Nacional Autónoma de Huanta, por su incansable motivación a sus docentes en promover investigación y análisis en el ambiente académico-científico.

CONCLUSIONES

El Perú país maravilloso, que posee riquezas invaluables, cuyos productos agrícolas provenientes de épocas prehispánicas, adaptadas a las condiciones altoandinas como la quinua, cañihua y amaranto, en las últimas décadas toma mayor relevancia e importancia en los mercados internacionales por sus propiedades nutraceúticas, rico en proteínas y aminoácidos, que favorece a la salud humana y es considerada una alternativa frente al consumo excesivo de grasas saturadas por la población, hoy en día se encuentra en los principales cadenas de minoristas en varios países del mundo, gracias al esfuerzo de varios años de promoción y posicionamiento del sector público y privado.

Hace muchos años, el país viene consolidando con sus productos agroexportables de bandera, éstas aun hasta el presente, sigue manteniendo su condición de líderes de producción en los mercados nacionales e internacionales, cumpliendo con los estándares de calidad e inocuidad fitosanitaria, siendo representados por el espárrago, alcachofa, páprika, y entre otros.

Frutos de consistencia carnosa-drupas, bayas: mango, durazno, palta, uva; cítricos, calidad de exportación, cuyos productos conquistan exitosamente mercados occidentales, europeos, asiáticos, por su capacidad de presentar características de consistencia, cuerpo, sabor, color, acidez, muy reconocidos por los empresarios importadores, por presentar en el país áreas con ventajas comparativas frente a otros, que le hacen ser únicos y competitivos, aún mantienen con expectativa negocios comerciales en la región y en otros ámbitos geográficos.

Productos con propiedades medicinales y orgánicas, en las últimas décadas están siendo investigadas, cuyos resultados cada vez más, cumplen con expectativas y se generan actividades comerciales, siendo la maca, mashua, yacón, camu camu y entre otros, y la vez generan nuevos productos a nivel procesados de altísima calidad.

La generación de agronegocios en el país hace varias décadas está tomando mayor importancia, generando movimientos comerciales, dinamizando el sector empresarialproductivo, contribuyendo al desarrollo nacional, mejorando calidad de vida en la población.

La contribución en la economía nacional proveniente de la actividad comercial en los agronegocios, está encaminada con expectativa frente al bicentenario, dejando épocas difíciles que tradujeron recesión económica, vulnerabilidad en los mercados internacionales y entre otras problemáticas, aún queda por doblegar esfuerzos hacia la consolidación con miras estratégicas en el sector.

La pandemia, en el rubro de los agronegocios, si bien es cierto que los impactos generados no han trascendido en su real magnitud, si ha tenido efectos en colocar productos a mercados internacionales y una de las formas que ha transcendido para aminorar estos efectos fue la diversificación de mercados, gracias a los convenios suscritos y acuerdos comerciales del Perú con otros países, sumadas a la reactivación económica temprana de países como China, Corea del Sur e India. A nivel interno los impactos han sido sopesados por la fortaleza de los productores a menor escala, quienes con su esfuerzo y sacrificio salieron adelante, pese a las carencias y dificultades en lograr acceder a

PURIQVol. 3, Núm. 3. 2021|ISSN 2664-4029|E-ISSN 2707-3602 Universidad Nacional Autónoma de Huanta difundidos en el mercado nacional los jugos de cañihua, quinua y amaranto, acompañados por una variada gastronomía, muy valorada por los consumidores locales y mercados internacionales[START_REF] Pasco | Productores de maca obtienen certificación orgánica con apoyo del Mincetur[END_REF].Otra de las especies es el cultivo de la maca, producido en las zonas altoandinas en las regiones de Junín, Pasco Huancavelica y algunas zonas altiplánicas, su potencialidad en encuentra en la obtención de harinas siendo el mercado principal Estados Unidos, algunos países de la región asiática el Japón, con el avance se ha logrado consolidar en la obtención de certificaciones orgánicas, que les ha permitido ingresar con valor agregado y de manera directa a los mercados de Estados Unidos y la Unión Europea, manteniendo esa característica de que en el país se producen alimentos de calidad, libres de insumos químicos y respetando el medio ambiente[START_REF] Pasco | Productores de maca obtienen certificación orgánica con apoyo del Mincetur[END_REF]. No solamente se queda ahí sino también en la obtención de diversos productos derivados caso licores, infusiones y entre otros.Productos orgánicos toman mayor relevancia, según Suca, (2004), en especial se toma atención en la calidad, poseer precio de venta competitivos y lograr una buena diferenciación de los productos peruanos, son tres aspectos fundamentales para que las agroexportaciones peruanas tengan éxito en los mercados internacionales, como productos orgánicos de la unidad productiva.PRODUCTOS FRESCOS BANDERA DE CALIDAD EXPORTABLECultivos de representación nacional considerados a nivel de producción dentro del top ten en caso del espárrago, muchas de las agroexportadoras siembran a gran escala y posteriormente éstas vienen siendo procesadas en sus diversas presentaciones y combinadas con otros, poniendo a disposición en los mercados internacionales.