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, to 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, and the logistics on a smaller scale are easier to manage and control.  Through demonstration projects, the requirements are refined, and 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 discipline 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.  

  1. 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. 
  2. 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. 
  3. 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.
  4. The concept of operations is the general description of the project; it is how the system will operate to meet stakeholder expectations. 
  5. 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, three elements of testing need to be considered; requirements verification proving that each requirement is satisfied; system verification assuring the system integrity; and system validation ensuring the system is built as intended by the mission objectives.
  6. 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. 
  7. 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. 
  8. 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.
  9. 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.
  10. 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. 
  11. 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, and System Security are essentially systems of systems.  These systems have a purpose; it is the production of something.  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.

  • We provide an analysis of requirements and risks.
  • We help establish program controls.
  • We evaluate alternatives in terms of project options.
  • We help determine sustainment capabilities and cost estimates.
  • We help establish measures of effectiveness, we help answer the question of when do we know we are done, and what does success look like.

Our Customers Include

  • The US Navy SPAWAR (Space and Naval Warfare Command) Pacific, and DHS (Department of Homeland Security). In working with our customers we provided system engineering services in the development of a wireless network of SCADA sensors that allowed the customer to view the status and last known location of shipping containers in near real time. This technology provides intermodal transportation carriers and the DHS a high degree of confidence that their containers are on track and had not been tampered with or opened.
  • Caltrans (California Department of Transportation) systems engineering. We have worked with Caltrans engineers to automate their traffic data collection systems. We have provided wireless addressable IP networks that allow traffic data to be collected, and to automatically update and to populate traffic management systems. We have provided project management support for the projects, tracking progress in terms of installations and cost, as well as tracking deliveries installations and the commissioning of data collection sites. as well as risk assessments for their ICS process.
  • Department of Defense customers CommTech has conducted requirements analysis that address DOTMLPF (Doctrine, Organization, Training, Material, Leadership and Education, Personnel, Facilities and Policy) requirements. These institutional requirements go a long way to ensure that projects and programs are constructed so that they address the breath of institutional needs that will ensure project success. As an example this approach ensures that the training of personnel is addressed, as well as answering the question where will these people come from, what equipment will they need, and where will the equipment and personnel be housed.
  • The Marine Corps, Joint Expeditionary Energy Office, focused on the Combat Readiness Optimized Networks program, the goal of this program is to evaluate the means to reduce the energy and water use of military forces. CommTech was directly involved in developing the Mission Essential Task List (METL) requirements and Use Cases focused on vehicle fuel use and monitoring. In addition, CommTech conducted engineering studies and analysis in the evaluation of commercial products and technology used for Machine to Machine (M2M) communication for internal vehicle diagnostics and external vehicle communications, that enabled vehicle data storage, and collection.