Washington University, St. LouisEngineering

Essay on Systems Engineering

Systems Engineering1

Systems engineering is a discipline concerned with the integration of multiple interrelated systems. Any significant project is composed of many different parts which must be completed separately, but all of which must work in harmony in the final design. It is the job of a systems engineer to balance and define the requirements of each subsystem to achieve the best possible final design. The engineers within each subsystem are tasked with optimizing their piece of the project under the given constraints with regard to the project as a whole. In this essay, we will give a more full and formal definition of systems engineering, discuss the impact of systems engineering on the technical workplace, and provide some examples of its use in our personal experience.

In its Systems Engineering Handbook2, NASA gives the definition: “Systems engineering is a methodical, disciplined approach for the design, realization, technical management, operations, and retirement of a system. A “system” is a construct or collection of different elements that together produce results not obtainable by the elements alone.” Systems engineering is the link between all processes — design, technical management, and product realization — of a project. Without it, projects would never reach their fullest potentials. Figure 1, also excerpted from the NASA Systems Engineering Handbook, shows the 17 main systems engineering processes, broken down by category.



As an example, consider the development of a space vehicle. Electrical engineers will design a power and communications system; software engineers will program the computer architecture to use and control these systems; mechanical engineers will provide structure and stability for the platform; aerospace engineers will build propulsion systems; and many other groups as well will contribute to the complex task. Each of these groups will want to produce the best subsystem they can in their own right, but the best or simplest subsystem will not necessarily work the best when considering the project as a whole. Trade-offs will have to be made. Some groups may have to perform design changes as a compromise that, while leading their subsystem away from optimal performance, enhance the function of the complete system. These redesigns will not happen unless there is a systems engineer directing the progress and recognizing the necessity of compromise for the final solution.

A great example of systems engineering on a university level can be found in teams participating in the Formula Society of Automotive Engineering competition. Our team is tasked with designing, fabricating, building, and testing an open-cockpit race car. During the competition, the dynamic performance of the car is tested, and the team has to explain and defend the engineering decisions we made. The car is composed of many different systems, each of which requires extensive technical knowledge. A project leader heads every system group and works with the officers and other project leaders to define the overarching goals and set deadlines for the team. As is common with most large projects, there are complex trade-offs between the designs of the systems. For example, the powertrain group tries to maximize the power output, while the suspension group focuses on maneuverability. These two desires are in opposition, and therefore the project leaders must use systems engineering to define a balance between them which satisfies the overall project requirements and resource limits, including manpower and funding.

A good systems engineer must start a project by fully understanding the end goal of the final product. This is usually defined by a set of company or customer requirements. Over time these requirements may change, and it is up to the systems engineer to communicate these changes to the individual subsystem groups. It is also the responsibility of the systems engineer to keep the customer abreast of the progress of the project as a whole and the problems the team has encountered. In order to do this, the systems engineer must understand the interactions between the systems and how the overall requirements apply to each one.

No matter the size of the project, systems engineers are tasked with the same general goals. Smaller projects requiring less labor generally require less systems engineering. However, large-scale projects may require more than one systems engineer in order to oversee the vast amount of work taking place. Each manages certain aspects of the project and then reports back to coordinate with the rest of their systems team.

Members of our team have also worked on the university nanosatellite program. This participation has given us firsthand experience with systems engineering on a small project while offering opportunities to evaluate cases where systems engineering was implemented well and others where it could have been used more effectively. In the program, external and internal design reviews have been implemented well. The nanosatellite program, with the support of Air Force Research Laboratory, conducts four external design reviews per two year program cycle. These reviews are an opportunity to receive external feedback on our progress, and preparing and presenting as a whole team often uncovers problems that went unnoticed when the team was working as individual subsystems. In addition, the team has implemented an internal change review board, comprised of members from each subsystem, which reviews any major design changes to an individual subsystem before they occur. However, due to the labor force of the team, thorough configuration management and updates are not completed and many small changes go unreported and unnoticed by the other subsystems, and therefore can cause problems when they are discovered during the integration process. As the team integrated the satellite into its flight configuration, we discovered several unreported changes in a subsystem which negatively impacted other subsystems and which in some cases would have made the project incapable of completing its mission. In addition, due to time, budget, and labor constraints of the program, we have generally not used requirements management protocols that would be appropriate in a large program. Instead of having technical specifications that flow down from our requirements, we must at times make changes to our requirements based on the abilities of the program.

On the other hand, in a larger program, like a manned space vehicle, systems engineering processes that are not a focus for a university nanosatellite or race car program would be of greater importance. A larger budget and amount of time, as well as a varied proposal structure, would encourage, if not require, that all technical specifications be directly derived from an initially and thoroughly completed requirements document. In addition, processes like risk management and stakeholder expectations definition would have more importance due to the increased risk and number of stakeholders inherent in a larger, manned mission. Systems engineering processes would also facilitate the process of coordinating a larger team throughout the project lifecycle. In larger projects at NASA, not only are there many engineers working on specific parts of the project, but these engineers can also be located in different buildings or in different centers. Without a well-implemented systems engineering policy, collaboration between design groups is likely to be inefficient. For example, the propulsion system could be designed and built in a manner than conflicts with the needs of the power system, or the parts could be built without a common interface due to a lack of technical control processes. In these situations, effective technical communication must also be in place so that the systems engineering decisions can be well-understood by all parties.

Although systems engineering looks different in different applications, the underlying methods utilized remain consistent across different projects. The outcomes of any such projects should share similar characteristics: they should have subsystems, even with opposed constraints, integrated together in a way that ensures the most efficient operation of the overall system. This, if done properly, will result in a project that is best suited to fulfill its specifications; if not done properly, the system may not function at all.

1. Essay written by students in the Reduced Gravity project.

2. United States. National Aeronautics and Space Administration. NASA Systems Engineering Handbook. NASA/SP-2007-6105 Rev1. 2007.

Washington University in St. Louis School of Engineering & Applied Science, Department of Electrical & Systems Engineering

Green Hall, CB 1042, 1 Brookings Drive, Saint Louis, MO, USA 63130
Phone: (314) 935-5565, Fax: (314) 935-7500

Reduce Font SizeEnlarge Font SizePrint Page