Search Results

ECOA is an active software architecture research programme conducted by the French Republic and United Kingdom. It is one product of the recent Defence and Security Co-operation Treaty signed between the two nations. This paper provides an overview of the programme goals and progress as well as an introduction to the technology being developed and comparison to related initiatives. The goal of the ECOA programme is to define an open software architecture that enables collaborative development of mission system software. The ECOA programme is needed to reduce development and lifecycle costs of future military air programmes. For this reason the programme has a specific focus on combat-air mission systems but the underlying technology is general purpose, applying to multiple military and civil domains. At present, the programme has defined a concept, delivered a set of initial technical standards and produced a joint demonstrator to validate the technology developed.

SCONES (Stress CONcentration Expert System) software is used to predict stress concentrations. When dimensions and loads are modified it instantaneously updates the display, making the system easy to use. SCONES contains validated and extended data from various sources, including complex interacting features which augments SCONES role. However, the natural progression is to extend the research to the interaction of processes including, for example, surface processes like anodising. These process interactions will dovetail into, and enhance features within the strain life factors. This paper will describe new work which will extend current knowledge in feature interactions and strain life factors and will improve SCONES versatility.

Impact events on composite structures that may cause damage can be readily detected and located using sensors that respond to the resulting impact stress waves as they propagate. This capability can be used as an alert to maintainers or operators who use the structures that an incident has occurred. However, for this capability to be truly useful it must include the capacity to determine automatically if the impact has caused damage. This will avoid the situation where a follow up inspection of the impact site reveals that no damage has been caused (no-fault found). This paper reports results from impact tests on glass and carbon composite, structural test specimens in which impact sensor data has been processed to reveal clear features that allow discrimination between damaging and non-damaging impacts.

Determination of the so-called stress concentration factor (Kt) is essential for the correct design of components subject to fatigue-inducing loading. The paper introduces methods and software for stress concentration analysis and techniques for structural design optimization based on the redistribution of material to balance stress concentration efforts.

A Distributed Engine Control Working Group (DECWG) consisting of the Department of Defense (DoD), the National Aeronautics and Space Administration (NASA)- Glenn Research Center (GRC) and industry has been formed to examine the current and future requirements of propulsion engine systems. The scope of this study will include an assessment of the paradigm shift from centralized engine control architecture to an architecture based on distributed control utilizing open system standards. Included will be a description of the work begun in the 1990's, which continues today, followed by the identification of the remaining technical challenges which present barriers to on-engine distributed control.

It is generally accepted that the development of hardware and software for safety critical systems follow their own lifecycles as defined by standards such as RTCA DO254 and RTCA DO178C. What is less clear is what should be done to ensure the system safety objectives are met when the software is installed in the electronic hardware. This paper seeks to discuss the activities that may be undertaken do demonstrate not only that the integration of the software and hardware “work” together, but they do so in a manner that meets the safety objectives in line with the guidelines described in SAE ARP4754A. According to ARP4754A, hardware and software are different “items” developed according to their own requirements and standards, when two or more items are brought together, they are a system, which may be part of a larger system. Therefore system level considerations need to be applied from the beginning of the development program addressing the system safety and certification activities.