Search Results

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.