Abstract: According to some embodiments, an Arbitrary Software Logic Modeling (“ASLM”) data source may store electronic records associated with units, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic. An ASLM platform may express system requirements at a logic block level and establish the logic blocks as self-contained entities and connections in accordance with the system requirements (the established logic blocks graphically representing systems logic). The ASLM platform may then explicitly transform the systems logic automatically to output language agnostic common design information exchange model information. The ASLM platform may also translate and maintain traceability among the system requirements, common design information exchange model information, and generated code.

Abstract: A method for model-based design of safety-critical software is disclosed. The method includes receiving natural-language software requirements, developing a specification model by implementing either semantic modeling or graphical modeling, applying formal requirements analysis to the specification model, auto generating requirements based and robustness test cases from the specification model, developing a design model based on the specification model, applying test cases to the design model, auto-generating source code using the design model, verifying the source code using both test cases and static analysis technology, and compiling executable object code from the verified source code. If a result of the analysis of the software specification or design models is not satisfactory then adjusting the specification or design model to correct any inconsistency, and repeating applying the analysis and test cases.

Abstract: A computer-implemented system for generating test cases and/or test procedures to verify software having a nonlinear arithmetic constraint over a Real number range. The system includes a translator that receives, as input, software specification models for the software to be verified. The translator is configured to generate, as output, a plurality of SMT formulas that are semantically equivalent to the software specification models. The system includes an analytical engine pool that receives, as input, the plurality of SMT formulas from the translator and analyzes the plurality of SMT formulas, and generates, as output, test case data for each of the plurality of SMT formulas determined to be satisfiable. The system includes a post-processor that receives, as input, the test case data from the analytical engine pool and generates, as output, the test cases and/or test procedures for the software to be verified based on the test case data.

Abstract: According to some embodiments, an Arbitrary Software Logic Modeling (“ASLM”) data source may store electronic records associated with units, each electronic record including a unit identifier, one or more identification tags, context data, unit parameters, unit variables, and internal logic. An ASLM platform may express system requirements at a logic block level and establish the logic blocks as self-contained entities and connections in accordance with the system requirements (the established logic blocks graphically representing systems logic). The ASLM platform may then explicitly transform the systems logic automatically to output language agnostic common design information exchange model information. The ASLM platform may also translate and maintain traceability among the system requirements, common design information exchange model information, and generated code.

Abstract: Automated requirements-based test case generation method includes constructing a software architecture model derived from software design model architectural information, allocating requirement models into blocks/operators of the software architecture model, and generating component-level requirements-based test cases from the software architecture configured to be executable at different levels in the software architecture.

Abstract: Automated requirements-based test case generation method includes constructing in a model-based development tool a software architecture model automatically derived from architectural information of a software design model, allocating requirement models into blocks/operators of the software architecture model, and generating component level requirements-based test cases from the software architecture.

Abstract: Methods, apparatus, systems and articles of manufacture to facilitate efficient scheduling of digital tasks in a system are disclosed. Periodic and aperiodic tasks may be identified, an initial minimum required duration may be determined based on the periodic and aperiodic tasks, a finish-to-activate duration of the aperiodic task may be determined, a final minimum required duration may be determined based on the initial minimum required duration and the finish-to-activate duration, a time budget may be adjusted to be the final minimum required duration, and the aperiodic task may be activated within the time budget based on the finish-to-activate duration.

Abstract: A computer-implemented system for generating test cases and/or test procedures to verify software having a nonlinear arithmetic constraint over a Real number range. The system includes a translator that receives, as input, software specification models for the software to be verified. The translator is configured to generate, as output, a plurality of SMT formulas that are semantically equivalent to the software specification models. The system includes an analytical engine pool that receives, as input, the plurality of SMT formulas from the translator and analyzes the plurality of SMT formulas, and generates, as output, test case data for each of the plurality of SMT formulas determined to be satisfiable. The system includes a post-processor that receives, as input, the test case data from the analytical engine pool and generates, as output, the test cases and/or test procedures for the software to be verified based on the test case data.

Abstract: According to some embodiments, a system includes a communication device operative to communicate with a user to obtain the one or more requirements associated with a specification model for a semantic module; a semantic module to receive the one or more requirements, store the one or more requirements and transform the one or more requirements into a semantic model; a specification module to receive the semantic model, store the semantic model, translate the semantic model and generate a specification model; a memory for storing program instructions; at least one specification model platform processor, coupled to the memory, and in communication with the specification module and the semantic module and operative to execute program instructions to: transform the one or more requirements into a semantic model by executing the semantic module; translate the semantic model into a graphical model by executing the specification module; and modify the graphical model by executing the specification module to generate

Abstract: Automated requirements-based test case generation method includes constructing in a model-based development tool a software architecture model automatically derived from architectural information of a software design model, allocating requirement models into blocks/operators of the software architecture model, and generating component level requirements-based test cases from the software architecture.

Abstract: A method for model-based design of safety-critical software is disclosed. The method includes receiving natural-language software requirements, developing a specification model by implementing either semantic modeling or graphical modeling, applying formal requirements analysis to the specification model, auto generating requirements based and robustness test cases from the specification model, developing a design model based on the specification model, applying test cases to the design model, auto-generating source code using the design model, verifying the source code using both test cases and static analysis technology, and compiling executable object code from the verified source code. If a result of the analysis of the software specification or design models is not satisfactory then adjusting the specification or design model to correct any inconsistency, and repeating applying the analysis and test cases.

Abstract: According to some embodiments, a system includes a communication device operative to communicate with a user to obtain the one or more requirements associated with a specification model for a semantic module; a semantic module to receive the one or more requirements, store the one or more requirements and transform the one or more requirements into a semantic model; a specification module to receive the semantic model, store the semantic model, translate the semantic model and generate a specification model; a memory for storing program instructions; at least one specification model platform processor, coupled to the memory, and in communication with the specification module and the semantic module and operative to execute program instructions to: transform the one or more requirements into a semantic model by executing the semantic module; translate the semantic model into a graphical model by executing the specification module; and modify the graphical model by executing the specification module to generate

Abstract: A pulse detonation turbine engine (PDTE) includes at least one controllable multi-tube pulse detonation combustor (PDC) configured to initiate firing of one or more pulse detonation tubes in response to operation of a plurality of controllable peripheral PDC components to regulate PDTE output characteristics. A control system including a programmable controller directed by algorithmic software operates to generate control inputs for the plurality of controllable peripheral PDC components in response to PDTE input conditions, such that one or more PD tube controllable inputs can be different for at least one PD tube relative to another PD tube within the multi-tube PDC, and further such that detonation timing can be different for at least one PD tube relative to another PD tube within the multi-tube PDC.