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.

Within the aerospace industry there is a growing interest in evaluating and reducing the environmental impacts of products and related risks to business. Consequently, requests from governments, customers, manufacturers, and other interested stakeholders, for environmental information about aerospace products are becoming widespread. Presently, requests are inconsistent and this limits the ability of the aerospace industry to meet the informational needs of various stakeholders and reduce the environmental impacts of their products in a cost-effective manner. Energy consumption is a significant business cost, risk, and a simple proxy value for overall environmental impact. This paper presents the initial research carried out by an academic and industry consortium to develop standardised methods for calculating and reporting the embodied manufacturing energy content of aerospace products.

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.

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.

Quality has been the illustrious word of the 80s and 90s as we speak organizations are chasing quality problems through the engineering teams and into production. Taskforces of workers in white coats are being sent on to the production line to furiously check components, monitoring process capability in an attempt to improve product quality. Unfortunately it's only after several years of production that the first “real” data gets back to the engineering teams, when it is often too late to remove the causes of these quality problems. The organization is left kicking itself over the same old catch twenty-two situations, “If only the team knew this process data before they decided to engineer it like that!”

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.

Aircraft as a System of Systems: A Business Process Perspective, written by Sean Barker, FBCS CEng and a former research scientist at BAE Systems in the UK, explains how developing even simple parts like a lever needs several different types of knowledge before moving on to the complications of designing a system. Today's airframers have taken on more of the role of systems integrators, putting the focus on the aircraft as a system-of-many-systems. Whereas an aircraft integrates many different systems into a single design, the system of systems which supports it is built by federating the systems of the different organizations, which were built and run independently of each other. Aircraft as a System of Systems: A Business Process Perspective provides a thorough analysis of how building aircraft taps into a huge pool of knowledge, how its complexity is also reflected in the numerous process links that exchange knowledge between different groups.