NASA utilizes cutting-edge design tools and techniques to create the advanced analyses, designs, and concepts required to develop unique aerospace products, spacecraft, and science
experiments. The diverse nature of the design work generated and overseen by NASA requires use of a broad spectrum of robust electronic tools such as computer-aided design tools and computer-aided systems engineering tools. Based on the distributed and varied nature of NASA projects, selection of a single suite of tools from only one vendor to accomplish all design tasks is not practical. However, opportunities to improve standardization of design policy, processes, and tools remain a focus for continuous improvement activities at all levels within the Agency. These guidelines serve as an aid to help in the selection of appropriate tools in the design and development of aerospace products and space systems and when selecting tools that affect multiple Centers. If no tools exist or can be adapted, the option of developing a new tool should be within the options considered, ranging from internal NASA development, partnerships with industry and academia, or a dedicated procurement.
7.3.1 Program and Project Considerations
When selecting a tool to support a program or project, all of the upper-level constraints and requirements should be identified early in the process. Pertinent information from the project that affects the selection of the tools will include the urgency, schedule, resource restrictions,
extenuating circumstances, and constraints. A tool that does not support meeting the program master schedule or is too costly to be bought in sufficient numbers will not satisfy the project manager’s requirements. For example, a tool that requires extensive modification and training that is inconsistent with the master schedule should not be selected by the technical team. If the activity to be undertaken is an upgrade to an existing project, legacy tools and availability of trained personnel are factors to be considered.
7.3.2 Policy and Processes
When selecting a tool, it is important to consider the applicable policies and processes at all levels, including those at the Center level, within programs and projects, and at other Centers when a program or project is a collaborative effort. In the following discussion, the term “organization” will be used to represent any controlling entity that establishes policy and/or processes for the use of tools in the design or development of NASA products. In other words, “organization” can mean the user’s Center, another collaborating Center, a program, a project, inline engineering groups, or any combination of these entities.
Policies and processes affect many aspects of a tool’s functionality. First and foremost, there are policies that dictate how designs are to be formally or informally controlled within the
organization. These policies address configuration management processes that should be followed as well as the type of data object that will be formally controlled (e.g., drawings or models). Clearly this will affect the types of tools that will be used and how their designs will be annotated and controlled.
The Information Technology (IT) policy of the organization also needs to be considered. Data security and export control (e.g., International Traffic in Arms Regulations (ITAR)) policies are
two important IT policy considerations that will influence the selection of a particular design tool.
The policy of the organization may also dictate requirements on the format of the design data that is produced by a tool. A specific format may be required for sharing information with collaborating parties. Other considerations are the organizations’ quality processes, which control the versions of the software tools as well as their verification and validation. There are also policies on training and certifying users of tools supporting critical flight programs and projects. This is particularly important when the selection of a new tool results in the transition from a legacy tool to a new tool. Therefore, the quality of the training support provided by the tool vendor is an important consideration in the selection of any tool.
Also, if a tool is being procured to support a multi-Center program or project, then program policy may dictate which tool should be used by all participating Centers. If Centers are free to select their own tool in support of a multi-Center program or project, then consideration of the policies of all the other Centers should be taken into account to ensure compatibility among Centers.
7.3.3 Collaboration
The design process is highly collaborative due to the complex specialties that should interact to achieve a successful integrated design. Tools are an important part of a successful collaboration. To successfully select and integrate tools in this environment requires a clear understanding of the intended user community size, functionality required, nature of the data to be shared, and knowledge of tools to be used. These factors will dictate the number of licenses, hosting capacity, tool capabilities, IT security requirements, and training required. The sharing of common models across a broad group requires mechanisms for advancing the design in a
controlled way. Effective use of data management tools can help control the collaborative design by requiring common naming conventions, markings, and design techniques to ensure
compatibility among distributed design tools.
7.3.4 Design Standards
Depending on the specific domain or discipline, there may be industry and Center-specific standards that should be followed, particularly when designing hardware. This can be evident in the design of a mechanical part, where a mechanical computer-aided design package selected to model the parts should have the capability to meet specific standards, such as model accuracy, dimensioning, and tolerancing, the ability to create different geometries, and the capability to produce annotations describing how to build and inspect the part. However, these same issues should be considered regardless of the product.
7.3.5 Existing IT Architecture
As with any new tool decision, an evaluation of defined Agency and Center IT architectures should be made that focuses on compatibility with and duplication of existing tools. Typical architecture considerations would include data management tools, middleware or integration infrastructure, network transmission capacity, design analysis tools, manufacturing equipment, approved hosting, and client environments.
While initial focus is typically placed on current needs, the scalability of the tools and the supporting IT infrastructure should be addressed too. Scalability applies to both the number of users and capacity of each user to successfully use the system over time.
7.3.6 Tool Interfaces
Information interfaces are ubiquitous, occurring whenever information is exchanged.
This is particularly characteristic of any collaborative environment. It is here that inefficiencies arise, information is lost, and mistakes are made. There may be an organizational need to interface with other capabilities and/or analysis tools, and understanding the tools used by the design teams with which your team interfaces and how the outputs of your team drive other downstream design functions is critical to ensuring compatibility of data.
For computer-aided systems engineering tools, users are encouraged to select tools that are compatible with the Object Management Group (OMG) System Modeling Language (SysML) standard. SysML is a version of the Unified Modeling Language (UML) that has been
specifically developed for systems engineering.2
7.3.7 Interoperability and Data Formats
Interoperability is an important consideration when selecting tools. The tools should represent the designs in formats that are acceptable to the end user of the data. It is important that any selected tool include associative data exchange and industry-standard data formats. As the
Agency increasingly engages in multi-Center programs and projects, the need for interoperability among different tools, and different versions of the same tool, becomes even more critical. True interoperability reduces human error and the complexity of the integration task, resulting in reduced cost, increased productivity, and a quality product.
When considering all end users’ needs, it is clear that interoperability becomes a difficult challenge. Three broad approaches, each with their own strengths and weaknesses, are: 1. Have all employees become proficient in a variety of different tool systems and the associated end use applications. While this provides a broad capability, it may not be practical or affordable.
2. Require interoperability among whatever tools are used, i.e., requiring that each tool be capable of transferring model data in a manner that can be easily and correctly interpreted by all the other tools. Considerable progress has been made in recent years in the standards for the exchange of model data. While this would be the ideal solution for many, standard data formats that contain the required information for all end users do not yet exist.
3. Dictate that all participating organizations use the same version of the same tool. When the use of same version of the tool is not possible, version and model controls will be necessary to validate models and simulations in differing tools.
2 OMG, UML, and SysML are either registered trademarks or trademarks of Object Management Group, Inc. in the
7.3.8 Backward Compatibility
On major programs and projects that span several years, it is often necessary to access design data that are more than 3 to 5 years old. However, access to old design data can be extremely difficult and expensive, either because tool vendors end their support or later versions of the tool can no longer read the data. Strategies for maintaining access include special contracts with vendors for longer support, archiving design data in neutral formats, continuous migration of archives into current formats, and recreating data on demand. Organizations should select the strategy that works best for them, after a careful consideration of the cost and risk.
7.3.9 Platform
While many tools will run on multiple hardware platforms, some perform better in specific environments or are only supported by specified versions of operating systems. In the case of open-source operating systems, many different varieties are available that may not fully support the intended tools. If the tool being considered requires a new platform, the additional
procurement cost and administration support costs should be factored in.
7.3.10 Tool Configuration Control
Tool configuration control is a tradeoff between responsive adoption of the new capabilities in new versions and smooth operation across tool chain components. This is more difficult with heterogeneous (multiple vendor) tool components. An annual or biannual block upgrade strategy requires significant administrative effort. On the other hand, the desktop diversity resulting from user-managed upgrade timing also increases support requirements.
7.3.11 Security/Access Control
Special consideration should be given to the sensitivity and required access of all design data. Federal Government and Agency policy requires the assessment of all tools to ensure appropriate security controls are addressed to maintain the integrity of the data. The systems engineer should work with the Organizational Computer Security Officer (OCSO) to integrate IT Security into the system. Important activities include development of the security plan and the emergency response plan per NPR 7120.7 For more details on IT security, see NPR 2810.1,Security of Information Technology.
7.3.12 Training
Most of the major design tools have similar capabilities that will not be new concepts to a seasoned designer. However, each design tool utilizes different techniques to perform design functions, and each contains some unique tool sets that will require training. The more
responsive vendors will provide follow-up access to instructors and onsite training with liberal distribution of training materials and worked examples. The cost and time to perform the training and time for the designer to become proficient can be significant and should be carefully factored in when making decisions on new design tools.
The disruptive aspect of training is an important consideration in adapting to a different tool. Before transitioning to a new tool, an organization should consider the schedule of deliverables
to major programs and projects. Can commitments still be met in a timely fashion? It is
suggested that organizations implement a phase-in approach to a new tool, where the old tool is retained for some time to allow people to learn the new tool and become proficient in its use. The transition of a fully functional and expert team using any one system to the same team fully functional using another system is a significant undertaking. Some overlap between the old tool and the new tool will ensure flexibility in the transition and ensure that the program and project work proceeds uninterrupted.
7.3.13 Licenses
Licenses provide and control access to the various modules or components of a product or product family. Consideration of the license scheme should be taken into account while selecting a tool package. Licenses are sometimes physical, like a hardware key that plugs into a serial or parallel port, or software that may or may not require a whole infrastructure to administer. Software licenses may be floating (able to be shared on many computers on a first-come, first- served basis) or locked (dedicated to a particular computer). A well-thought-out strategy for licenses should be developed in the beginning of the tool selection process. This strategy should take into consideration program and project requirements and constraints as well as other factors such as training and use. The strategy development should involve the applicable IT
organization.
7.3.14 Stability of Vendor and Customer Support
As in the selection of any support device or tool, vendor stability is of great importance. Given the significant investment in the tools (directly) and infrastructure (indirectly), it is important to look at the overall company stability to ensure the vendor will be around to support the tools. Maturity of company products, installed user base, training, and financial strength can all provide clues to the company’s ability to remain in the marketplace with a viable product. In addition, a responsive vendor provides customer support in several forms. A useful venue is a Web-based user-accessible knowledge base that includes resolved issues, product documentation, manuals, white papers, and tutorials. Live telephone support can be valuable for customers who don’t provide support internally. An issue resolution and escalation process involves customers directly in prioritizing and following closure of critical issues. Onsite presence by the sales team and application engineers, augmented by post-sales support engineers, can significantly shorten the time to discovery and resolution of issues and evolving needs.