CommTech Systems provides Systems Engineering services to both government and commercial customers.
The process and Introduction
Systems Engineering is a structured process to create a system. Our focus is on the Engineering Design Process, a disciplined, holistic approach that focuses on the system’s lifecycle requirements. It is a holistic approach since success is not only determined by meeting a schedule or a budget; success also depends on the involvement and support of all stakeholders. Ours is a lifecycle approach that considers requirements, production, operations, change, and the system end of life.
Our system engineering experience ranges from large Federal Contracts that cross the domains of multiple agencies, international development contracts, and commercial manufacturing systems. The success or failure of these projects is often the same. They often are problems with requirement definition, scale, and political or stakeholder engagement. Our approach in System Engineering is to address and manage these issues up-front and throughout the project life cycle.
A key element in the system engineering process is collaboration. Often the best result in dealing with large projects is to start small; a good way to ensure failure is to start big. With smaller projects, collaboration is easier, false assumptions are uncovered without much risk, the logistics on a smaller scale are easier to manage and control. Through demonstration projects, the requirements are refined, stakeholders are validated.
System Engineering is a universal approach to building systems and solving problems. There are many valid approaches; what works best is the disciple that an organization has experience with and can deliver the best result. Our approach uses the System Engineering Approach outlined in the NASA System Engineering Handbook SP-601S. In brief, this is an iterative process that lists eleven functions and tools. This is not a sequential process; many of these functions are run concurrently, with one function supporting others.
- Establishing the top-level requirements or the mission objectives also defines the success criteria through validated metrics. It is also discovering the intent of the objectives; it is not uncommon that the first set of top-level objectives are not aligned with the mission intent.
- The development of the derived requirements and decomposition of the requirements results in a list of the enabling requirements. These become the task lists of things required to achieve the mission objectives. These are then further decomposed into a hierarchy of requirements.
- The architecture design is how the system is constructed based on the mission objectives and the requirements that influence them. It begins as a hierarchy of subsystems, often described by major block diagrams with one or two tiers, and becomes detailed with additional tiers as the system is deconstructed. It is not uncommon that some top-level requirements are changed due to discovery in the requirement decomposition process. This is the iterative process of validating requirements and adjusting to meet the mission objectives. As the project progresses, it is through the demonstration projects that assumptions and requirements are validated.
- The concept of operations is the general description of the project; it is how the system will operate to meet stakeholder expectations.
- The validate and verify (V&V) is a continuous function during requirements, architectural design, and ConOps. The goal of V&V is to provide a great degree of assurance that the requirements, design, and ConOps will achieve the intent of the mission objectives. As these elements are developed concurrently, there is the need to construct tests and means to validate them in the testing function. In general, there are three elements of testing that need to be considered; requirements verification proving that each requirement is satisfied; system verification assuring the system integrity; system validation ensuring the system is built as intended by the mission objectives.
- The interfaces and ICD (Interface Control Document) define and outline how the system receives data and communicates. All systems depend on data and a data pathway or interface that crosses the system boundaries. The data pathways are often radio waves, mechanical, environmental, electrical, thermal, etc. These interfaces are developed and included in the design as the architecture is developed and matures. This is also a hierarchical process and is documented by the ICD with the addition of each subsystem and its components.
- The mission environment will define the operating system environment, affecting almost all aspects of system design. These can be physical environment constraints, social or political considerations, technical constraints, etc.
- The technical resource budget tracking identifies and tracks resource budgets. These are system resources and are not associated with financial costs or budgets. Each system requires resources to operate and function, including power, weight, cube, memory storage, communication capacity or bandwidth, etc.
- Risk management identifies risks. These risks include safety, cyber and environmental threats, performance, cost, schedule, etc. The risk management function identifies risks and rates them by their severity and probability of impact. Risk management develops strategies to address the highest-rated risks.
- Configuration management and project management documentation established the document control process. It sets access permissions, documentation, and distribution rules. It ensures the team has access to the management information needed to run the project.
- System Engineering reporting Milestone Reviews and Reports reports the status of the technical engineering and project management functions. This, as with most other functions, relies on tools that collect data for assessing progress, identifying problems or issues, and providing alternatives.
What we do.
CommTech Systems, as a systems integrator, follows the system engineering process. Industrial Control Systems, Communication Systems, Precision Agriculture are essentially systems of systems. These systems have a purpose; it is the production of something, industrial output or product, a communication production or link, crops or produce. Each of these systems has phases, and these production phases depend on sensors, data support infrastructure, data collection, storage, and analysis. The decision support system is entirely reliant on this data collection infrastructure. For these systems to work, there needs to be a design architecture supported by the system engineering process; that is what CommTech Systems does.