No description available.

No description available.

The primary purpose of this Integrative project is to determine whether the mission objectives for NASA's Orbiting Carbon Observatory (OCO) could effectively be met on a persistent global basis via a commercially hosted payload concept. NASA's OCO satellite mission was designed to ""make the first space-based measurements of atmospheric carbon dioxide ""(Corporation, 2007). The OCO satellite, was destroyed during a failed launch attempt February 2009. The satellite was intended to be a science demonstration satellite with spot coverage and a delayed revist rate. In order for this important mission to be performed in an operational utility (e.g. Kyoto Treaty monitoring) it will be necessary that carbon emissions be measured with persistent global coverage. One potential cost-effective and medium risk solution to meeting the original OCO scientific mission may be achieved by hosting atmospheric carbon dioxide sensors on commercial satellites. An OCO replacement based upon multiple hosted payloads could potentially developed and launched for less than the cost of the first OCO standalone system and is tolerant to single case launch or on-orbit failures. This proposed Integrative Project will document the mission analysis, requirements derivation, trade studies, technology readiness, risk assessment, and ethical considerations necessary to determine whether the proposed hosted payload concept is technically feasible and potentially cost effective. A significant secondary objective of this project is to document lessons learned from the recently initiated US Air Force Commercially Hosted Infrared Payload (CHIRP) project and apply them to the Orbiting Carbon Observatory program. The two programs primary payloads have significant similarities including mass, volume, thermal requirements, power requirements, sensor type, and focal plane technology. The OCO sensor design and the CHIRP sensor are both refractive-optic based infrared sensors with very similar cryocooler requirements and detectors. This association allows lessons learned from the CHIRP proposal technical evaluation to be applied in a non-military sensitive context. Ultimately the design similarity paired with the scientific openness of the NASA science community should adequately document the application of lessons learned from the CHIRP technical evaluation to an important scientific mission for the global community.

Unmanned Aerial Vehicles (UAVs) are common place in the 21st century, whether they are small to medium sized remotely piloted vehicles (aka drones) or large advanced Unmanned Aerial Systems with a preprogrammed flight path. There is anticipation that these Unmanned Systems will, in the future assume the roles of their traditional manned aircraft counterparts. There is also the perception that these Unmanned Systems should be developed partly because they would be less expensive when compared to their manned aircraft. This integrative paper asserts that this perception is not reality with regards to developing a newly designed UAV to replace its manned counterpart, for the same mission. Through the examination of systems engineering principles between the unmanned RQ-4 Global Hawk and the manned U-2 Dragon Lady one will understand why this perception is not correct. Both aircraft perform the same mission of providing High Altitude Intelligence, Surveillance, and Reconnaissance (ISR). Through evaluation of requirements analysis both aircraft flowed down the requirements to all the various subsystems in a similar manner, creating similar subsystems for Imagery Intelligence (!MINT) and Signals Intelligence (SIGINT). However, the additional requirement for long endurance required that the Global Hawk systems engineers had additional requirements to flow down to the software, communications, data processing, and ground support subsystems in order to control an unmanned aircraft for greater than 24 hours. This one additional requirement had various derived requirements that needed to be verified, and validated during analysis, manufacturing, subsystem build and test, and final system integration. By using both System Integration Laboratories (SIL) and Flight Tests both systems requirements were verified and validated by the systems engineers. The Global Hawk since it was unmanned was required to perform more verification of subsystems and software as it was the first UAV to achieve flight airworthiness. The future of ISR missions requires that the aircraft become more adaptable to future technologies and situations. The U-2 has a modular configuration to change out to and from different subsystems depending on the mission. However, these subsystems were designed 20 to 30 years ago, and were not designed for lower level modularity or interoperability. The Global Hawk systems engineering team understood the future needs and the high level demand and data to be gathered and processed. The SE's developed modularity and interoperability requirements and flowed them down to the various subsystems. The Global Hawk system is more useful in highly contested areas of interest as there is no pilot; however resilient communications of the data and data link must be robust with anti-jamming capabilities to ensure the data is secure from cyber-attack. However,the U-2 is more survivable since it has a defense system, and can provide greater situational awareness. Taking all the general ISR requirements into consideration a trade study using a matrix was performed indicating that the Global Hawk is the most optimal solution to meeting both the current and future requirements for ISR missions. Even though the overall acquisition cost of the Global Hawk is equivalent to the U-2, systems engineering for Global Hawk had the responsibility to flow down requirements to all subsystems with consideration of the entire systems lifecycle. This is exemplified in that the Global Hawk is cost effective to fly in terms of cost per flight hour. Therefore, the Global Hawk can fulfill all the requirements of the given stakeholders with the lowest operational cost.

FRACAS (Failure Reporting, Analysis and Corrective Action System) is an essential element in achieving product reliability. In simplified terms, FRACAS is a formal process conducted in a closed-loop system environment in which a failure is reported, tracked, analyzed, and resolved with the intent to prevent future reoccurrences. This process has recently been emphasized by the Secretary of Defense through a Directive-Type Memorandum (DTM) 11-003 - Reliability Analysis, Planning, Tracking, and Reporting - on March 21, 2011. Companies compete in an environment where cost weighs heavily in business decisions and in some cases becomes the determining factor in closing a business deal. With that in mind, company leaders and managers push to further scrutinize all processes and functions emphasizing on ROI (return on investment) of their activities. By discovering and eliminating non-value-added activities (waste), a company better positions itself towards gaining a competitive edge in winning or sustaining their business; this strategy is not to be implemented without caution. How should a company address its management behaviors of focusing only on the short-term goals during the proposal phases of each program? This type of management behavior ignores any activity that consists of a low ROI now, but has a long-term gain for the organization. A well-implemented FRACAS increases product reliability and consequently contributes to higher availability of the product. This is achieved through adequate resources (both labor and tools) as well as collaborative functions and its management within the organization. However, through its involvement from a product's inception to sustainment, FRACAS can quickly become very costly if it is not implemented properly. For this reason, ROI on its activities can easily be misinterpreted; thus resulting in managers who are reluctant to invest in FRACAS for the next project. Therefore, managers often allocate minimal or no funding for FRACAS activities. This project takes the approach of first understanding what FRACAS is and what it means to the customer, then identifying the reasons behind management's reservations about fully funding FRACAS, and lastly evaluating the challenges faced by the FRACAS engineers in performing FRACAS activities. The project outcomes are to accomplish the following objectives: 1) to define the role of FRACAS within the total systems engineering process; 2) to reveal the key contributors to an ineffective FRACAS, and 3) to provide the important factors to a successful implementation of FRACAS. The goal of this project is to suggest possible resolutions to shortcomings preventing FRACAS from fulfilling its intended role in improving product reliability.

No description available.

No description available.

Tooling is defined as the work performed by a tool. In the context of industrial production tooling takes many forms from a simple drill bar to highly complex assembly jigs. In all cases the tooling exists to assist in the accurate and precise performance of work on engineering products. The engineering product therefore defines and constrains the form and function of the associated tooling. The process of defining, fabricating, and verifying tooling is often subject to individual, business, or government perspectives and processes. Relying on individual experience and inadequate processes often results in frequent rework, product design interface issues, and a lack of historical perspective and traceability on the tooling design. The Systems Engineering process, which is already valued as a necessary component of complex system definition, will be beneficial when adapted and applied to the process of defining, fabricating, and verifying tooling. The methodical processes and tools associated with Systems Engineering will embed the tooling process in the product requirement and design process and encourage increased interaction and concurrent engineering practices. A tooling process, based on System Engineering principles combined with best industry practices, that is ingrained in the product life cycle and which thoroughly documents associated technical and producibility requirements will reduce the issues currently prevalent in complex tooling realization.

No description available.

In the challenging environment of satellite design and development, it is commonly understood that there is only one opportunity to launch a satellite that meets all of its technical requirements. That is to say, once a satellite is launched, deficiencies cannot be corrected (Figure 1). The rigorous application of Systems Engineering (SE) has demonstrated the capability for space programs to deliver functional satellites to the government. Nevertheless, space programs have continued to consistently overrun budget and schedule. "Lean" is a proven methodology for eliminating inefficiencies, called waste, and enabling companies to achieve profitability. A full implementation of lean into the companies designing and developing complex products, such as satellites, could dramatically lower program cost and schedule, restoring corporate profitability and government confidence in acquisition programs. The Lean Enablers for Systems Engineering (LEfSE) is a product for implementing lean to efficiently and effectively operate programs that employ systems engineering. The release of LEfSE as a formal product of the International Council on Systems Engineering (IN COSE) is pending. A distinguished team of academic and industry experts has developed the 194 enablers. This document evaluates the LEfSE for possible implementation into a company already in the process of implementing lean. The enablers have been categorized in the following groups: 1) Those that have already been implemented in the company and needed no further evaluation; 2) Those that have been assessed as being outside the scope of the project (due to the need for senior executive knowledge required for either the implementation or assessment of cost or benefit); and 3) those evaluated for implementation. The enablers evaluated for implementation were analyzed for the cost to implement, the expected benefit from implementation, and calculated simple payback period. The analysis showed that implementing those enablers provides average payback in approximately three months. The recommendation herein is that the Company implements the selected LEfSE to improve cost and schedule performance while improving quality and customer satisfaction. Furthermore, since the Company analyzed is a typical aerospace firm, one can reasonably infer that similar benefits may be gained from the implementation of the LEfSE throughout the industry.