Should The Systems Engineer Be Involved At The Component Level?
In a previous post on the definition of Systems Engineering, it was stated that the systems engineer should be involved in the big picture items. However, this does not mean that the systems engineer cannot or will not be involved in the details of components, or even sub-components. In this post, we explore some of the circumstances that will motivate the systems engineer to dive into the details of the system.
For the majority of the system development process, the systems engineer will be involved at the subsystem level down to the component level. There will be an overlap with the design specialist at the component level since the system engineer will generate specifications and interface requirements for components.
What Component Level Activities Will The Systems Engineer Be Involved In?
There are at least three activities of the systems engineer that require knowledge to the component level:
1. Specification/Requirements Development: The systems engineer must have knowledge to the component level in order to properly develop requirements. Otherwise, the resulting requirements may contain items that are not within the capabilities scope of available components. For example, unless the systems engineer understands the strength capabilities of a load bearing interface component, it is possible to create requirements for that component that are not achievable.
2. Cost Estimates (development and production): The systems engineer must know the cost versus specification information for components so that the overall development and production cost goals of the system are achieved. For instance, the output power specification for an amplifier in a radar system is roughly proportional to cost. The systems engineer needs to know the cost versus power specification for that component so that the correct system architecture can be developed that meets requirements and cost objectives.
3. System Level Trade Studies: When performing system level trade studies, it is often useful for the systems engineer to know the capabilities of components. With component level knowledge, the systems engineer is able to push certain parts of the system to better understand boundaries of the system trade space. In other words, without knowledge of the range of values of the component critical parameters, then it is difficult to do trade studies.
What Circumstance Will Cause The Systems Engineer To Probe Deep Into Sub-Component Level Details?
There are a few circumstances that will motivate the systems engineer to probe even deeper into the details–to the sub-component level. A few of those circumstances are:
•The subcomponent is critically important to the performance of the system
•The subcomponent has possible reliability concerns
•The subcomponent is vital to the operation of the system
•The subcomponent is a new technology that does not have a proven track record
A Real World Example Of When The Systems Engineer Should Be Involved At The Sub-Component Level
An example of when the systems engineer should be involved at the sub-component level is the O-ring seal in the Space Shuttle Challenger booster rocket tragedy. The seal did not perform at low temperature which resulted in the Challenger disaster. The systems engineers should have known the behavior of those seals and their performance at low temperature. This would have allowed them to determine the impact on the system as a whole, the reliability issues, and safety concerns.