Model-based code generation: past, present and future
Explore the source record for details and available documents.
SEARCH · Search NASA
Search indexed NASA NTRS and DOE OSTI research on propulsion, heat transfer, battery materials and energy systems. Follow report and document links to the original sources.
Quote a phrase for an exact phrase match. Source license links do not imply unrestricted reuse.
Explore the source record for details and available documents.
This paper discusses the use of Tcl-formatted data definition files processed at compile time in place of runtime-loaded text tables.
Web-based geospatial client applications such as Google Earth and NASA World Wind must listen to data requests, access appropriate stored data, and compile a data response to the requesting client application. This process occurs repeatedly to support multiple client requests and application instances. Newer Web-based geospatial clients also provide user-interactive functionality that is dependent on fast and efficient server responses. With massively large datasets, server-client interaction can become severely impeded because the server must determine the best way to assemble data to meet the client applications request. In client applications such as Google Earth, the user interactively wanders through the data using visually guided panning and zooming actions. With these actions, the client application is continually issuing data requests to the server without knowledge of the server s data structure or extraction/assembly paradigm. A method for efficiently controlling the networked access of a Web-based geospatial browser to server-based datasets in particular, massively sized datasets has been developed. The method specifically uses the Keyhole Markup Language (KML), an Open Geospatial Consortium (OGS) standard used by Google Earth and other KML-compliant geospatial client applications. The innovation is based on establishing a dynamic cascading KML strategy that is initiated by a KML launch file provided by a data server host to a Google Earth or similar KMLcompliant geospatial client application user. Upon execution, the launch KML code issues a request for image data covering an initial geographic region. The server responds with the requested data along with subsequent dynamically generated KML code that directs the client application to make follow-on requests for higher level of detail (LOD) imagery to replace the initial imagery as the user navigates into the dataset. The approach provides an efficient data traversal path and mechanism that can be flexibly established for any dataset regardless of size or other characteristics. The method yields significant improvements in userinteractive geospatial client and data server interaction and associated network bandwidth requirements. The innovation uses a C- or PHP-code-like grammar that provides a high degree of processing flexibility. A set of language lexer and parser elements is provided that offers a complete language grammar for writing and executing language directives. A script is wrapped and passed to the geospatial data server by a client application as a component of a standard KML-compliant statement. The approach provides an efficient means for a geospatial client application to request server preprocessing of data prior to client delivery. Data is structured in a quadtree format. As the user zooms into the dataset, geographic regions are subdivided into four child regions. Conversely, as the user zooms out, four child regions collapse into a single, lower-LOD region. The approach provides an efficient data traversal path and mechanism that can be flexibly established for any dataset regardless of size or other characteristics.
The operation of the BGRID computer program is described for generating block-structured grids. Examples are provided to illustrate the code input and output. The application of a fully implicit AF (approximation factorization)-based computer code, called TWINGB (Transonic WING), for solving the 3D transonic full potential equation in conservation form on block-structured grids is also discussed.
Program EAGLE (Eglin Arbitrary Geometry Implicit Euler) Numerical Grid Generation System is a composite (multi-block) algebraic or elliptic grid generation system designed to discretize the domain in and/or around any arbitrarily shaped three dimensional regions. This system combines a boundary conforming surface generation scheme and includes plotting routines designed to take full advantage of the DISSPLA Graphics Package (Version 9.0). Program EAGLE is written to compile and execute efficiently on any Cray machine with or without solid state disk (SSD) devices. Also, the code uses namelist inputs which are supported by all Cray machines using the FORTRAN compiler CFT77. The namelist inputs makes it easier for the user to understand the inputs and operation of Program EAGLE. EAGLE's numerical grid generator is constructed in the following form: main program, EGG (executive routine); subroutine SURFAC (surface generation routine); subroutine GRID (grid generation routine); and subroutine GRDPLOT (grid plotting routines). The EAGLE code was modified to use on the NASA-LaRC SNS computer (Cray 2S) system. During the modification a conversion program was developed for the output data of EAGLE's subroutine GRID to permit the data to be graphically displayed by IRIS workstations, using Plot3D. The code of program EAGLE was modified to make operational subroutine GRDPLOT (using DI-3000 Graphics Software Packages) on the NASA-LaRC SNS Computer System. How to implement graphically, the output data of subroutine GRID was determined on any NASA-LaRC graphics terminal that has access to the SNS Computer System DI-300 Graphics Software Packages. A Quick Reference User Guide was developed for the use of program EAGLE on the NASA-LaRC SNS Computer System. One or more application program(s) was illustrated using program EAGLE on the NASA LaRC SNS Computer System, with emphasis on graphics illustrations.
Code to estimate position and attitude of a spacecraft or aircraft belongs to the most safety-critical parts of flight software. The complex underlying mathematics and abundance of design details make it error-prone and reliable implementations costly. AutoFilter is a program synthesis tool for the automatic generation of state estimation code from compact specifications. It can automatically produce additional safety certificates which formally guarantee that each generated program individually satisfies a set of important safety policies. These safety policies (e.g.. array-bounds, variable initialization) form a core of properties which are essential for high-assurance software. Here we describe the AutoFilter system and its certificate generator and compare our approach to the static analysis tool PolySpace.
Explore the source record for details and available documents.
The high cost of software production is driving development organizations to adopt more automated design and analysis methods such as rapid prototyping, computer-aided software engineering (CASE) tools, and high-level code generators. Even developers of safety-critical software system have adopted many of these new methods while striving to achieve high levels Of quality and reliability. While these new methods may enhance productivity and quality in many cases, we examine some of the risks involved in the use of new methods in safety-critical contexts. We examine a case study involving the use of a CASE tool that automatically generates code from high-level system designs. We show that while high-level testing on the system structure is highly desirable, significant risks exist in the automatically generated code and in re-validating releases of the generated code after subsequent design changes. We identify these risks and suggest process improvements that retain the advantages of rapid, automated development methods within the quality and reliability contexts of safety-critical projects.
AutoCert [2] is a formal verification tool for machine generated code in safety critical domains, such as aerospace control code generated from MathWorks Real-Time Workshop. AutoCert uses Automated Theorem Provers (ATPs) [5] based on First-Order Logic (FOL) to formally verify safety and functional correctness properties of the code. These ATPs try to build proofs based on user provided domain-specific axioms, which can be arbitrary First-Order Formulas (FOFs). These axioms are the most crucial part of the trusted base, since proofs can be submitted to a proof checker removing the need to trust the prover and AutoCert itself plays the part of checking the code generator. However, formulating axioms correctly (i.e. precisely as the user had really intended) is non-trivial in practice. The challenge of axiomatization arise from several dimensions. First, the domain knowledge has its own complexity. AutoCert has been used to verify mathematical requirements on navigation software that carries out various geometric coordinate transformations involving matrices and quaternions. Axiomatic theories for such constructs are complex enough that mistakes are not uncommon. Second, adjusting axioms for ATPs can add even more complexity. The axioms frequently need to be modified in order to have them in a form suitable for use with ATPs. Such modifications tend to obscure the axioms further. Thirdly, speculating validity of the axioms from the output of existing ATPs is very hard since theorem provers typically do not give any examples or counterexamples.
The NASA DAIDALUS library provides formal definitions for Detect-and-Avoid avionics concepts such as when an aircraft is well-clear with respect to the surrounding air traffic, i.e., it does not operate in such proximity to create a collision hazard. While several properties are proven correct for DAIDALUS assuming ideal real number arithmetic, an actual implementation that uses floating-point numbers may behave unexpectedly because of round-off errors and run-time exceptions. This paper presents an experience report on the application of a formal methods toolchain to extract and verify floating-point C code from a real-valued specification of the well-clear module of DAIDALUS. This toolchain comprises the PVS theorem prover, the PRECiSA floating-point analyzer and code generator, and the Frama-C analysis suite. The generated code is automatically instrumented to detect when the control flow of the floating-point program may diverge from the ideal real number specification, and it is annotated with contracts that state the maximum accumulated round-off error. The absence of overflows is also formally verified for the generated code. In order to apply the toolchain to an industrial case study such as DAIDALUS, a formally verified pre-processing of the input specification is performed, which includes a program slicing and several semantic-preserving simplifications.
A programming environment supports the activity of developing and maintaining software. New environments provide language-oriented tools such as syntax-directed editors, whose usefulness is enhanced because they embody language-specific knowledge. When syntactic and semantic analysis occur early in the cycle of program production, that is, during editing, the use of a standard compiler is inefficient, for it must re-analyze the program before generating code. Likewise, it is inefficient to recompile an entire file, when the editor can determine that only portions of it need updating. The pcg, or Pascal code generation, facility described here generates code directly from the syntax trees produced by the SAGA syntax directed Pascal editor. By preserving the intermediate code used in the previous compilation, it can limit recompilation to the routines actually modified by editing.
A viewgraph presentation of an automatic code scheme for source verification issues is shown. The topics include: 1) Model-Based Control Law Development with Automatic Code Generation; 2) Source Verification Issues of Automatically Generated Code; 3) MXZ Code Generator; 4) Benefits and Limitations of MXZ; and 5) Current State of the Tool.
Coded timing light generator to place mark on edge of photographic film in order to correlate high speed phenomenon photographed by many cameras
This research was aimed at porting the T programming language, a dialect of LISP, to the Cray X/MP computer. The effort involved research into systems engineering and software engineering problems related not only to compiler design and implementation, but also to parallel computation, the X/MP being a shared-memory multiprocessor. Porting also involved the sub-tasks of retargeting the assembler, code-generator, and run-time system. A reasonably effective porting methodology that is relatively straight forward, although more difficult than table-driven approaches, has been developed. The run-time system was not ported, and thus the T programs cannot be run without explicit linking of the required run-time support. The run-time performance gain achieved in generated code was found to be disappointing. Recommendations for the achievement of higher performance are given.
Software development is widely considered to be a bottleneck in the development of complex systems, both in terms of development and in terms of maintenance of deployed systems. Cost of software development and maintenance can also be very high. One approach to reducing costs and relieving this bottleneck is increasing the reuse of software designs and software components. A method for achieving such reuse is a software parts composition system. Such a system consists of a language for modeling software parts and their interfaces, a catalog of existing parts, an editor for combining parts, and a code generator that takes a specification and generates code for that application in the target language. The Advanced Software Development Workstation is intended to be an expert system shell designed to provide the capabilities of a software part composition system.
Domain-specific knowledge is required to create specifications, generate code, and understand existing systems. Our approach to automating software design is based on instantiating an application domain model with industry-specific knowledge and then using that model to achieve the operational goals of specification elicitation and verification, reverse engineering, and code generation. Although many different specification models can be created from any particular domain model, each specification model is consistent and correct with respect to the domain model.
The benefits of automatic-application code generation are widely accepted within the software engineering community. These benefits include raised abstraction level of application programming, shorter product development time, lower maintenance costs, and increased code quality and consistency. Surprisingly, code generation concepts have not yet found wide acceptance and use in the field of programmable logic controller (PLC) software development. Software engineers at Kennedy Space Center recognized the need for PLC code generation while developing the new ground checkout and launch processing system, called the Launch Control System (LCS). Engineers developed a process and a prototype software tool that automatically translates a high-level representation or specification of application software into ladder logic that executes on a PLC. All the computer hardware in the LCS is planned to be commercial off the shelf (COTS), including industrial controllers or PLCs that are connected to the sensors and end items out in the field. Most of the software in LCS is also planned to be COTS, with only small adapter software modules that must be developed in order to interface between the various COTS software products. A domain-specific language (DSL) is a programming language designed to perform tasks and to solve problems in a particular domain, such as ground processing of launch vehicles. The LCS engineers created a DSL for developing test sequences of ground checkout and launch operations of future launch vehicle and spacecraft elements, and they are developing a tabular specification format that uses the DSL keywords and functions familiar to the ground and flight system users. The tabular specification format, or tabular spec, allows most ground and flight system users to document how the application software is intended to function and requires little or no software programming knowledge or experience. A small sample from a prototype tabular spec application is shown.
Instead of using the criterion of maximum free distance, (df) or the maximum (df) with minimizing a few first distance profiles, short constraint length rate 1/N convolution codes were searched using a criterion of minimizing required bit energy-to-noise density ratio, E(b)/N(o), for a given value of desired bit error rate (BER), for the goodness of a code. The considered channel was binary antipodal signaling over additive white Gaussian noise and no quantization at the channel output. For the BER calculations, the transfer function bounding technique was used. Partial searches were performed using some known facts and a very useful idea that "good codes generate good codes.'' That is, for a given constraint length K, good rate 1/(N + 1) codes can be found by extending the code generator matrices of good rate 1/N codes. The code search results are tabulated for 3 or = K or = 7 and 2 or = N or = 8. For many pairs of K and N, the new codes are shown to save 0.1 to 0.4 dB in the required E(b)/N(o) compared to previously reported codes. Additionally, the benefits of coding bandwidth expansion are confirmed with the new codes.