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 Handbooks, 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 legalization -? 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; ND 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 stickiest 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 Engine nearing 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 reject 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 perpetration group tries to maximize the power output, while the suspension group focuses on invulnerability. 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 AOL 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 neural 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 nationalities program.
This participation has given us firsthand experience with systems engineering on a small project while offering opportunities to evaluate cases here 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 nationalities 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 n 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 eave 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 nationalities 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 lifestyle. In larger projects at NASA, not only are there any 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 sections can be well-understood by all parties.
