What a Systems Engineer Can Do For You: 7 Guiding Principles

For several months now I have worked as a systems engineer in the broadcast field. Having applied myself as one during this period, I have realized there are certain best practices to consider while working as one. Research on this topic led me to understand the principles and processes guiding the work of systems engineers in all sorts of fields like manufacturing, defense, telecommunications, power systems. All follow standard models to execute their duties and in this post I shall elaborate what they are.

 

What is Systems Engineering?

This has been defined for years as an interdisciplinary set of technical and managerial activities with the aim to bring together a functioning whole (system) with distinctive parts that solves a unique problem and meets a client’s requirements.

To meet the said definition, an engineer has to employ something called systems thinking. This is a philosophical approach on design and implementation of functioning systems. The ability to see them as a sum of their parts and how causality applies among them. In addition, it requires you to think about the day to day use of the system, future improvements and upgrade-ability in order to provision and manage successfully.

Fortunately, smarter people than I have been developing this idea for a while. The ISO/IEC/IEEE 15288:2015 defines the systems and software engineering – systems life cycle processes which establishes a common framework of processes and descriptions for describing the life cycle of systems created by humans. Such an example is the QFD House of Quality for Enterprise Product Development Processes as in Figure 1. It is from such work that some basic principles and models of systems engineering have been developed.

 

 

Systems Engineering Principles

There are some basic procedures to undertake in order to deliver a well functioning system, these are:

1. Systems requirements analysis
2. Physical and functional design
3. Effectiveness evaluation and decision
4. System integration
5. Simultaneous/concurrent engineering
6. Verification and validation
7. Support analysis and design

This is quite an oversimplification and one can generate an even longer list, but those are the principles in discussion for now.

 

System Requirements Analysis

This is the first stage of the process. You have landed a contract to set up a system with a degree of technical complexity that few can deliver. The requirements analysis is a detailed description of what the finished product should be and what problems it is supposed to solve for the user. This may be a documentation that the user develops alone or with the technical guidance that you offer. This analysis required an understanding of the following:

• The system requirements
• The user expectations, needs, wants of the final outcome
• Technical knowledge of feasible solutions
• Costs and risks involved

The four items are developed in connection with each other for example a particular technology may meet the user needs but it may be too expensive to implement.

It is at this stage that you breakdown the problem into sets of smaller well-defined problems, each with a different approach to execution example solving audio production, video production, transmission, streaming; these are 4 problems in a broadcast facility that a systems engineer may be tasked to solve.

Strive to apply your technical understanding and design skills to ensure customer satisfaction at this level and avoid haphazard segmentation of the project just because different technologies/elements are involved. This is in order to develop an optimal system involving all of the parts avoiding developmental issues that bring increased costs and delayed schedules. The engineer’s knowledge and creativity is seen here, implementation can be seen as an artistic expression incorporating solutions developed from great ideas.

 

Physical and Functional Design

The fun part of this entire process is trying to see how everything will come together. At the end of the day, components will have to be connected, software will have to be configured or coded and the project will come to an end.

The physical design of the systems details the different physical components and how they will be linked together. Schematics and block diagrams are useful in this purpose. The physical design also takes into account the constraints in which the project is based on like the physical space, environmental factors and budget. In the real world, physical design leads to assembly and interconnection/linking of components.

In contrast, the functional design is the logical framework of the system. It details how one output leads to another and how events are managed within the system. This is usually represented diagrammatically by a flowchart, logic circuit or signal flow graph. The functional design determines whether the proposed solution makes sense and the suggested components will perform as expected. The functional design is later used to configure (using hardware or software) the assembled components.

An example of a functional and physical design can be seen in Figure 2, where we have an incoming signal and its desired output.

The physical and logical designs can be analysed together using simulation software.

 

Effectiveness Evaluation and Decision

This is mostly performed at the early stage with a series of meetings with the clients/users. Do the earlier analyses and design outcomes match with the customer’s expectations? This comparison is used to offer modifications and clarity about the designs as integrating prior to forming an understanding between the engineers and the clients leads to wasted time and money.

Effectiveness evaluation is measuring the extent to which targets are being met, and detecting the factors that hinder or facilitate their realization. It also involves establishing cause-effect relationships about the extent to which a particular policy (or a set of policies) produces the desired outcome.
businessdictionary.com

 

This evaluation allows the engineers to put all available alternatives on the table presented to the stakeholders, giving an elaborate outline on risks involved and expected outcome with each alternative. The engineer at this stage improves the suggested solutions using input from the stakeholders as they are most concerned with the overall benefit of the system.

 

System Integration

The physical labor is at this point where you build the actual system. The previous stages generated the instructions upon which the system will be built as well as the physical layout plans and designs. Systems aren’t all erected at once and it is up to the engineers to divide it into sub-systems which can be installed independently.

Risk management also comes at play here. One can informally assess whether the solution makes sense and whether the elements involved meet the requirements of the job or perform as expected.

 

Simultaneous/Concurrent Engineering

During the integration phase, constant remodeling of the solution with newly acquired variables from the field is essential to maintain control over the system output.

In a telecommunications system integration, for example, one may notice that the calculated point of installation of an transmitting antenna (height, coordinates etc) differ from the actual point of installation due to some factors that were missing at the time of initial design. This may in turn require the receiving antenna to change position affecting other installation variables, especially true for microwave links, more about that here.

This domino effect forces an engineer to constantly make edits to her designs and simulations accordingly.

 

Verification and Validation

So close to the end now! A reality check should be performed to ascertain whether the work done meets the stated requirements, and provide suggestions for system optimizations. The system is verified under a particular success criteria the output of which can be used to predict possible points of future failures and concern.

The measurement of effectiveness (MOEs) gives the degree to which mission objectives were achieved and attainment of the desired result.

 

Support Analysis and Design

Finally, a coherent support system should be established. Reports and all required documentation surrendered to the users upon completion/commissioning of the system. An effective method of training the users should also be performed. This requires meticulous design of the support system like the alarms systems involved, if any, and steps taken to correct any fault.

The engineer can establish a timeline of training and support activities within the provided support period/contract, to ensure full customer independence by the end of the stated period.

 

 

Conclusion

If you’ve made it this far you should now have a clue with what goes on in the mind of a systems engineer undertaking a small or large scale project. His hopes to provide the highest value to the stakeholders with his solution as compared to the alternatives. However, he doesn’t have to be alone. Using Integrated Product Teams (IPTs) who are teams of multidisciplinary individuals adds to the overall system creativity with complementary skills that aid in driving the delivery of the final product.

I’m still far away from calling myself a seasoned systems engineer, but I’m currently learning from the best and working my way there. I hope this gives you an overview into the principles I try to work by, if you’d like to add, agree or oppose please comment below.